MySQL 쿼리 내에서 인코딩 변경

  1   쿼리 내에서 인코딩 수정

---

 

MySql은 잘 사용하지 않았기 때문에 겪을일이 없었지만, 최근 업무로 인한 MySql을 접하게 되었다. 그런데 쿼리를 날리면 한글만 깨져서 나오는 현상이 발생..

 뭘까? DB 클라이언트 툴을 이용할 수 없는 상황에서 단순 JSP에 JDBC 코드를 넣고 돌려봤는데 한글만 깨져나오는 현상이 있었다. 처음엔 JSP와 DB MySQL 결과셋의 인코딩 설정이 다른걸까? euc-kr부터 시작해서 iso8859, utf-8 모두 한글이 깨져나왔다. 

 그러다가 DB 클라이언트 툴을 이용할 수있는 상황이 되었고 DB에 직접 쿼리를 날려 결과를 날려보았는데 애초에 DB 내에 한글이 깨진상태로 들어가있었다. 그냥 DB 데이터가 잘못된거네~ 하고 넘어갈 수 있었지만 조금만 생각해보면 현재 운영중인 서버이고, 사용중인 서버이다.

사용중이라는 것은 이놈의 데이터가 현재 한글로 잘~ 돌아가고있다는 말인데..

처참한 데이터..

 결국 구글링을 통하여 답을 얻을 수 있었다. 실제로 운영되고 있는 서버이고 마음대로 설정을 바꿀 수 없는 노릇이기에 쿼리 내에서 이 문제를 해결해야 하는 상황이었다.

Character encoding, like time zones, is a constant source of problems.

What you can do is look for any "high-ASCII" characters as these are either LATIN1 accented characters or symbols, or the first of a UTF-8 multi-byte character. Telling the difference isn't going to be easy unless you cheat a bit.

To figure out what encoding is correct, you just SELECT two different versions and compare visually. Here's an example:

SELECT CONVERT(CONVERT(name USING BINARY) USING latin1) AS latin1, 
       CONVERT(CONVERT(name USING BINARY) USING utf8) AS utf8 
FROM users 
WHERE CONVERT(name USING BINARY) RLIKE CONCAT('[', UNHEX('80'), '-', UNHEX('FF'), ']')

This is made unusually complicated because the MySQL regexp engine seems to ignore things like \x80 and makes it necessary to use the UNHEX() method instead.

This produces results like this:

latin1                utf8
----------------------------------------
Björn                Björn

 

 일단 한글이 깨진 컬럼을 바이너리코드로 Convert 하고 이것을 다시 UTF-8로 Convert!

검색한 내용대로 쿼리내에서도 성능은 좀 떨어지겠지만 충분히 해결할 수 있는문제였다. 으.. MySql에서는 이런문제도 발생하고 있구만.. 음.