인코딩 변환과 한글 깨짐 복구

빠른 답변

문자 깨짐이란?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

이 도구가 하는 일

예제 풀이

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(부분 복원만 가능)

사용 방법

1. 1

   깨진 문자를 붙여넣습니다

   인코딩을 먼저 알아낼 필요 없이 그대로 넣으십시오. 짧은 조각으로 충분하며, 열 몇 글자면 대개 경로가 특정됩니다.

2. 2

   첫 번째 후보와 배지를 읽습니다

   무손실은 같은 경로로 되돌리면 입력이 글자 하나까지 재현된다는 뜻입니다. 부분은 그렇지 않다는 뜻이므로 결과를 단서로만 다루십시오.

3. 3

   인코딩 경로를 확인합니다

   각 후보에는 원문이 실제로 쓰인 인코딩과 그것을 잘못 읽은 인코딩이 함께 표시됩니다. 문장이 무엇이었는지뿐 아니라 상류에서 무엇을 고쳐야 하는지도 알려 줍니다.

4. 4

   필요하면 바이트를 들여다봅니다

   두 번째 구획은 아무 텍스트나 흔한 인코딩 전부의 바이트로 보여 주고, 16진수를 반대 방향으로 디코딩합니다. 칼럼 길이를 정하거나 프로토콜 프레임을 확인할 때 쓰십시오.

상황을 악화시키는 실수

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# 현재 인코딩부터 확인
file -I correct.txt   # charset=utf-8 → 변환할 것이 없음

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- 바이트가 재해석되지 않고 보존되도록 이진 타입을 한 번 거친다
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// 배지가 무엇이라고 하든 첫 번째 후보를 취한다
db.update(row.id, candidates[0].text);

// 왕복이 성립하는 것만 써넣는다
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# 파일이 실제로 쓰는 인코딩으로 경계에서 한 번만 디코딩
with open(path, encoding='gbk') as f:
    text = f.read()

이럴 때 필요합니다

데이터베이스 마이그레이션이 쓰레기 값을 남겼을 때

실제로는 UTF-8 바이트를 담고 있으면서 latin1로 선언된 레거시 MySQL 테이블이 단연 흔한 출처입니다. ALTER TABLE을 쓰기 전에 깨진 행 하나를 여기에 붙여넣어 실제 경로를 확인하십시오. 방향을 거꾸로 걸어 변환하면 복구 가능한 문제가 영구적인 문제로 바뀝니다.

Excel에서 연 CSV가 알아볼 수 없을 때

Windows의 Excel은 BOM 없는 CSV를 여전히 시스템 코드 페이지로 가정하므로 UTF-8로 내보낸 파일이 깨져 보입니다. 여기서 경로를 확인한 뒤 BOM을 붙여 다시 내보내거나, 텍스트 마법사에서 인코딩을 명시해 가져오십시오.

레거시 서비스가 남긴 로그 파일

EUC-KR이나 GBK, Shift_JIS를 기준으로 만들어진 애플리케이션은 로그도 그 인코딩으로 씁니다. 반면 요즘 로그 수집기는 무엇이든 UTF-8로 읽습니다. 한 줄을 붙여넣어 복원하십시오. 아무것도 업로드되지 않으므로 운영 로그로도 그렇게 할 수 있습니다.

ZIP 압축 파일이 망가뜨린 파일명

ZIP 형식에는 인코딩 필드가 없습니다. 그래서 한국어나 중국어, 일본어 Windows에서 만들어진 압축 파일은 파일명을 CP949나 GBK, Shift_JIS로 담고 있고 유닉스 도구는 그것을 UTF-8로 읽습니다. 이름을 변경하기 전에 여기서 원래 이름부터 확인하십시오.

데이터베이스 칼럼 길이 산정

바이트 보기는 같은 텍스트를 모든 인코딩에서 한 번에 보여 줍니다. 한글 한 글자는 UTF-8에서 3바이트, EUC-KR에서 2바이트이며, 바로 이런 차이가 VARCHAR(50)을 잘림 결함으로 바꿔 놓습니다.

문자 깨짐은 왜 생기는가

바이트는 살아남고 의미만 사라진다

인코딩은 문자를 바이트로 옮기고 디코딩은 바이트를 다시 문자로 옮깁니다. 문자 깨짐은 잘못된 대응표로 디코딩한 결과입니다. 바이트 자체는 한 번도 손상되지 않았고, 그래서 잘못된 디코딩을 거꾸로 돌리면 원문이 정확히 돌아옵니다. 단, 그 잘못된 디코딩이 아무것도 버리지 않았다는 조건에서만 그렇습니다.

왜 CJK 텍스트가 가장 심한가

ASCII는 0x00–0x7F를 차지하고 흔한 인코딩은 모두 이 구간을 같게 해석하므로 영문 텍스트는 아무 손상 없이 통과합니다. 한국어와 중국어, 일본어는 멀티바이트 열이 필요하고 인코딩마다 그것을 묶는 방식이 다릅니다. 한글 한 글자는 UTF-8에서 3바이트, EUC-KR에서 2바이트입니다. UTF-8 바이트를 EUC-KR 디코더에 먹이면 묶음의 경계가 어긋나면서 글자 수도 내용도 다른 문자열이 나옵니다.

왕복 검증

각 후보 경로에 대해 도구는 복원된 텍스트를 첫 번째 인코딩으로 다시 인코딩하고 두 번째 인코딩으로 다시 디코딩합니다. 그 결과가 입력을 그대로 재현하면 그 경로는 모든 글자를 설명하는 것이고 후보에 무손실 표시가 붙습니다. 검증을 통과하지 못한 후보도 함께 보여 줍니다. 부분적인 복원만으로도 원문을 알아보기에 충분한 경우가 많기 때문입니다.

인코딩 표는 어디서 오는가

디코딩 표는 브라우저의 TextDecoder가 제공합니다. 반대 방향은 더 까다롭습니다. TextEncoder는 UTF-8만 지원하기 때문에, 도구는 바이트 공간을 훑으며 각 열이 무엇을 뜻하는지 디코더에 되물어 역방향 대응표를 구성합니다. 그래서 이 대응은 언제나 브라우저 자신의 동작과 일치하며, 어떤 표도 사용자 기기로 내려보내지 않습니다.

순위 휴리스틱과 그 한계

왕복 검증 외에, 후보는 텍스트에서 상용 한자(GBK 선두 바이트가 0xB0–0xF7 구간에 드는 글자)가 차지하는 비율로 점수를 얻고 대체 문자와 반각 가타카나, 제어 문자로 감점을 받습니다. 반각 가타카나는 Shift_JIS 오독의 강한 신호입니다. 정상적인 일본어 문장은 그것을 거의 쓰지 않기 때문입니다. 이것은 휴리스틱이며 동점을 가를 뿐 진실을 세우지는 않습니다.

다시 겪지 않으려면

문자열이 아니라 원인을 고칠 것

각 후보 아래의 인코딩 경로가 어느 구성 요소가 잘못 설정되었는지 알려 줍니다. 연결 문자셋이나 파일 리더, 내보내기 설정을 그대로 둔 채 텍스트만 고치면 내일 새 데이터로 같은 일을 반복하게 됩니다.

파일 전체를 변환하기 전에 방향부터 확인할 것

대표적인 한 줄을 먼저 이 페이지에 통과시키십시오. 방향을 거꾸로 걸면 대체 문자가 생기는데, 처음의 오독과 달리 그 단계는 되돌릴 수 없습니다.

모든 자리에 인코딩을 명시할 것

데이터베이스 연결 문자셋, HTTP Content-Type, 파일 열기 호출, CSV 내보내기. 「시스템 인코딩」에 기대는 자리는 코드가 다른 장비로 옮겨 갈 때 같은 결함이 되살아나는 자리입니다.

MySQL에서는 utf8 대신 utf8mb4를 쓸 것

MySQL의 utf8은 문자당 최대 3바이트만 저장하므로 이모지와 일부 희귀 한자가 조용히 잘려 나갑니다. utf8mb4가 진짜 UTF-8입니다. 이것은 문자 깨짐과 다른 종류의 고장이고 바이트가 실제로 없어진 것이므로 이 복구 도구로는 손쓸 수 없습니다.

수정이 검증될 때까지 원본 바이트를 남겨 둘 것

무엇을 변환하든 먼저 사본을 두십시오. 원본 바이트가 남아 있는 한 잘못된 디코딩은 모두 되돌릴 수 있습니다. 일단 대체 문자로 덮어써지고 나면 이 페이지도, 다른 어떤 도구도 되살릴 수 없습니다.

자주 묻는 질문