Mojibake 복구 (깨진 UTF-8 수리)
텍스트
Mojibake(문자 깨짐)는 UTF-8 바이트를 단일 바이트 인코딩 — 거의 항상 레거시 Windows 기본값인 Windows-1252 — 으로 잘못 읽을 때 생기는 깨진 텍스트입니다. é는 é가 되고, 둥근 아포스트로피는 ’, 줄바꿈 없는 공백은  , 이모지는 😀 같은 네 개의 이상한 문자가 됩니다. 이 도구는 그것을 되돌립니다: 각 문자를 원래의 Windows-1252 바이트로 다시 인코딩하고 그 바이트를 UTF-8로 디코딩해 원본 텍스트를 복원합니다. 이중으로 깨진 텍스트에는 복구를 반복 적용하며, 설계상 안전합니다 — 올바르게 인코딩된 텍스트(비라틴 문자 포함)는 되돌릴 때 유효한 UTF-8을 이루지 않으므로 손상되지 않고 그대로 둡니다. 깨진 텍스트를 붙여넣고 복구된 버전을 복사하세요. 모든 처리는 로컬에서 실행되며 업로드되지 않습니다.
Windows-1252로 잘못 디코딩된 UTF-8을 되돌립니다. 올바른 텍스트(모든 문자)는 유효한 것으로 감지되어 그대로 둡니다.
사용법
- 깨진 텍스트를 붙여넣기.
- 복구된 출력을 읽으세요 — 몇 번의 패스가 필요했는지, 또는 수정이 필요 없었는지 표시됩니다.
- 수정된 텍스트 복사.
자주 묻는 질문
- Mojibake는 왜 생기나요?
- UTF-8로 저장된 텍스트를 나중에 다른 단일 바이트 인코딩 — 흔히 Windows-1252나 ISO-8859-1 — 으로 읽을 때 발생합니다. 각 비ASCII 문자는 둘 이상의 UTF-8 바이트로 저장됐는데 그 바이트를 하나씩 읽으면 잘못된 문자가 나옵니다: é(2바이트)는 두 문자 é로 보입니다. CSV 가져오기, 데이터베이스 마이그레이션, 인코딩이 다른 시스템 간 복사·붙여넣기가 흔한 원인입니다.
- 이미 올바른 텍스트를 손상시키나요?
- 아니요. 복구는 되돌린 바이트가 유효한 UTF-8을 이룰 때만 성공하는데, 진짜 mojibake는 그렇지만 올바르게 인코딩된 텍스트는 아닙니다. 그래서 이미 올바른 'café', 'Köln', '한국어', '日本語'는 유효한 것으로 감지되어 그대로 둡니다 — 도구가 수정이 필요 없다고 알려 줍니다.
- 왜 가끔 두 번 이상 패스를 적용하나요?
- 텍스트가 두 번 잘못 디코딩됐다면 — 예를 들어 UTF-8을 Windows-1252로 읽고 저장한 뒤 다시 Windows-1252로 읽으면 — 깨짐이 겹쳐집니다. 도구는 텍스트가 더 이상 바뀌지 않거나 유효한 UTF-8로 되돌려지지 않을 때까지 복구를 반복하고 몇 번의 패스를 썼는지 알려 줍니다.
- 텍스트가 안 고쳐졌어요 — 왜죠?
- 텍스트가 이미 올바르거나, 손상이 흔한 UTF-8-을-Windows-1252로-읽은 종류가 아니기 때문입니다(예: Shift_JIS나 EUC-KR로 잘못 디코딩됐거나 바이트가 실제로 손실됨). 이 도구는 가장 빈번한 경우를 다룹니다. 특정 레거시 인코딩으로 파일을 열려면 텍스트 인코딩 변환기를 쓰세요.
관련 도구
Markdown 표 → CSV 변환기
GitHub 방식 Markdown 표를 CSV, TSV 또는 세미콜론 구분 행으로 변환합니다. 브라우저에서 동작합니다.
마크다운 표 생성기
CSV·TSV·파이프 구분 데이터를 정렬된 GitHub 마크다운 표로 변환합니다.
텍스트 Diff 뷰어
두 텍스트를 비교해 줄·단어 단위로 추가·삭제를 강조해서 보여 줍니다.
Lorem Ipsum 생성기
문단·문장·단어 단위로 자리표시자 텍스트를 생성하세요.
대소문자 변환기
대문자·소문자·Title·camelCase·snake_case 등으로 변환하세요.
글자수 단어수 카운터
글자·단어·문장·줄·바이트 수를 실시간으로 셉니다.