한글 깨짐 복구 (UTF-8 · EUC-KR)

한글은 왜 깨지나요?

저장할 때 쓴 규칙과 읽을 때 쓴 규칙이 다르기 때문입니다.

컴퓨터는 글자를 숫자(바이트)로 저장합니다. "안"을 어떤 숫자로 적을지는 인코딩이 정하는데, 한국에서는 오랫동안 EUC-KR/CP949를 썼고 지금은 UTF-8이 표준입니다.

EUC-KR로 저장한 파일을 UTF-8인 줄 알고 열면, 같은 바이트를 다른 표로 찾게 되니 엉뚱한 글자가 나옵니다. 파일이 손상된 게 아니라 해석이 틀린 것입니다.

어떤 깨짐은 복구되고 어떤 건 안 되나요?

깨진 글자에 � 나 ? 가 보이면 복구할 수 없습니다. 이게 판단 기준입니다.

ìëíì¸ì 나 안녕하세요 처럼 알아볼 수 없어도 글자는 멀쩡히 있는 경우는 복구됩니다. 원래 바이트가 그대로 남아 있어서, 올바른 표로 다시 읽기만 하면 됩니다.

반대로 �ȳ��ϼ��� 나 ?????? 는 안 됩니다. �는 "여기 있던 바이트를 어떻게 읽을지 몰라서 버렸다"는 표시입니다. 버린 것은 되살릴 수 없습니다. 이때는 원본 파일을 다시 받는 것 말고 방법이 없습니다.

복구해준다고 주장하는 도구가 있다면, 그건 추측으로 지어내는 것이라 믿으면 안 됩니다.

EUC-KR, CP949, 완성형은 뭐가 다른가요?

거의 같은 것이고, CP949가 EUC-KR을 넓힌 것입니다.

EUC-KR은 한국 표준(KS X 1001)에 있는 2,350자만 담습니다. 일상 한글은 대부분 되지만 "똠", "뷁" 같은 글자가 빠져 있어서 못 씁니다.

CP949(=확장 완성형, Windows-949)는 여기에 나머지 한글을 채워 11,172자 전부를 담습니다. 윈도우가 쓰는 게 이쪽입니다.

실무에서는 둘을 잘 구분하지 않고 "EUC-KR"이라고 부릅니다. 브라우저도 euc-kr을 CP949로 처리합니다. 지금 새로 만드는 것이라면 둘 다 쓰지 말고 UTF-8을 쓰면 됩니다.

애초에 안 깨지게 하려면?

UTF-8로 통일하는 게 유일한 답입니다. 파일 저장, 데이터베이스, HTTP 헤더, HTML의 <meta charset> 까지 전부요.

특히 자주 걸리는 곳이 엑셀의 CSV입니다. 엑셀은 CSV를 열 때 UTF-8을 자동으로 알아채지 못하는 경우가 많습니다. 파일 맨 앞에 BOM이라는 표식 3바이트를 붙여 저장하면 대부분 해결됩니다.

데이터베이스에서는 MySQL의 utf8을 조심해야 합니다. 이름과 달리 진짜 UTF-8이 아니라 3바이트까지만 담는 반쪽짜리여서, 이모지가 들어오면 깨집니다. utf8mb4가 진짜입니다.