깨진 문자(모지바케) 변환・자동 복구 도구

깨진 문자열을 붙여넣기만 하면 원인이 된 인코딩 조합을 즉시 자동 판별하여 복구 후보를 표시합니다. UTF-8・Shift_JIS・EUC-JP・JIS(ISO-2022-JP) 간의 명시적 변환도 지원하며, 무료로 가입 없이 바로 사용할 수 있습니다.

깨진 문자(모지바케) 변환 도구란

깨진 문자는 텍스트를 저장할 때 사용한 인코딩과 이를 읽는 쪽이 가정한 인코딩이 서로 다를 때 발생합니다. 이 도구는 깨진 문자열을 붙여넣기만 하면 예상되는 조합을 모두 시도하여, 자연스럽게 읽히는 후보를 위에서부터 나열합니다. 어떤 인코딩에서 깨졌는지 모르는 상태에서도 복구를 시도할 수 있는 것이 특징입니다.

다만 모든 깨진 문자를 되돌릴 수 있는 것은 아닙니다. 문자열로 읽히는 시점에 원본 바이트열이 이미 손실되었다면, 문자열만으로는 복원이 원리적으로 불가능합니다. 「?」나 「�」가 이어져 있는 부분이 여기에 해당합니다. 인코딩 조합을 이미 알고 있다면 「수동 변환」 탭에서 한 번에 변환할 수 있습니다.

깨진 문자를 복구하는 방법

  1. 깨진 문자열을 붙여넣기 「자동 복구」 탭의 입력란에 깨진 텍스트를 그대로 붙여넣습니다. 입력한 내용은 외부로 전송되지 않습니다.
  2. 복구 후보 확인하기 예상되는 조합을 모두 시도한 결과가 나열됩니다. 「가장 유력한 후보」 배지가 붙은 것부터 확인해 보세요.
  3. 후보가 없으면 직접 지정하기 「수동 변환」 탭에서 깨져 보이는 인코딩과 원래 인코딩을 선택하면 해당 조합만으로 변환합니다.
  4. 복구되지 않으면 원본 파일로 돌아가기 문자열에서 복원되지 않는 경우, 원본 파일을 텍스트 편집기에서 인코딩을 지정해 다시 여는 편이 확실합니다.

더 잘 활용하기 위한 팁

  • 복구 후보가 여러 개 표시되는 경우, 「가장 유력한 후보」 배지가 붙은 가장 자연스러운 일본어・ASCII 문자열이 정답인 경우가 많습니다.
  • 이메일이나 CSV 파일에서 흔히 보이는 「縺薙繧薙?...」와 같은 문자열은 대부분 UTF-8→Shift_JIS 조합으로 해결됩니다.
  • 「?」나 「�」의 연속으로 깨진 경우, 원본 바이트열의 일부가 손실되었을 가능성이 높아 문자열만으로는 완전한 복원이 어렵습니다.
  • 복구할 인코딩 조합을 이미 알고 있다면 「수동 변환」 탭에서 한 번에 변환 결과를 확인할 수 있습니다.

깨진 문자 변환의 활용 사례

전달받은 CSV가 읽히지 않을 때

거래처에서 받은 CSV를 스프레드시트에서 열었을 때 깨진다면, 셀의 내용을 붙여넣어 원래 문자를 확인할 수 있습니다. 파일을 다시 요청하기 전 원인 파악에 유용합니다.

메일 제목이나 본문이 깨졌을 때

오래된 메일 프로그램에서 발송된 문서가 읽히지 않을 때 복구할 수 있습니다. 발신자에게 문의하지 않고도 내용을 파악할 수 있는 경우가 있습니다.

로그나 데이터베이스 내용 확인

인코딩 설정이 어긋난 채 쌓인 로그나 레코드를 확인할 때, 해당 부분만 옮겨서 복구할 수 있습니다.

인코딩의 차이를 직접 확인하기

「수동 변환」 탭에서 같은 문자열을 여러 조합으로 변환해 보면, 어떤 불일치가 어떤 형태의 깨짐으로 이어지는지 확인할 수 있습니다.

문자 인코딩 관련 용어

UTF-8
전 세계의 문자를 다룰 수 있는 현재의 표준 인코딩입니다. 일본어 한 글자를 3바이트로 표현하는 경우가 많으며, 웹 페이지 대부분이 이 방식을 사용합니다.
Shift_JIS
일본어를 위해 만들어진 인코딩으로, 일본어 한 글자를 2바이트로 표현합니다. 일본 내 오래된 시스템과 Windows 애플리케이션에서 지금도 쓰입니다.
EUC-JP
주로 UNIX 계열 환경에서 사용되어 온 일본어 인코딩입니다. Shift_JIS와 바이트 할당이 달라 서로 혼동하면 문자가 깨집니다.
JIS (ISO-2022-JP)
전자우편에서 오랫동안 사용되어 온 일본어 인코딩입니다. 특정 기호열로 문자 집합을 전환하면서 문자를 표현합니다.
인코딩
문자를 바이트열로 변환하는 규칙을 말합니다. 저장하는 쪽과 읽는 쪽에서 이 규칙이 일치하지 않으면 문자가 깨집니다.
복원 불가능한 깨짐
읽어 들이는 시점에 원본 바이트열이 손실되어 문자열로는 되돌릴 수 없게 된 상태를 가리킵니다. 「?」나 「�」로 바뀐 부분이 여기에 해당합니다.

자주 묻는 질문

텍스트를 저장할 때 사용한 인코딩과 이를 읽는 쪽이 가정하는 인코딩이 다를 때 발생합니다. 일본어는 특히 UTF-8・Shift_JIS・EUC-JP 세 가지가 혼재하기 쉬워, 이러한 가정 불일치가 깨진 문자의 주요 원인입니다.

아닙니다. 불일치의 종류에 따라 최초의 (잘못된) 디코딩 과정에서 원본 바이트열의 정보가 이미 손실되어, 문자열만으로는 완전히 복원할 수 없는 경우가 있습니다. 특히 일본어의 2바이트 문자가 다른 일본어 인코딩으로 잘못 읽힌 경우 복원이 어려우며, 「?」나 「�」로 바뀐 부분은 기본적으로 복원이 불가능합니다.

현재 가장 널리 쓰이는 인코딩은 UTF-8이지만, 일본 내 일부 오래된 시스템과 Windows 애플리케이션은 여전히 Shift_JIS를 전제로 하는 경우가 있습니다. UTF-8의 바이트열이 대부분 Shift_JIS로도 유효하게 해석되는 바이트열에 해당하기 때문에 정보가 손실되지 않고 깨진 것처럼 보이며, 결과적으로 복원도 가능한 경우가 많습니다.

전송되지 않습니다. 변환 처리는 모두 브라우저 내 JavaScript로 실행되므로, 비밀번호나 개인정보가 포함된 문자열이라도 안전하게 사용할 수 있습니다.
툴군

여담이지만 ― 「縺薙繧薙?縺ォ縺。縺ッ」가 일본어 깨진 문자의 대명사가 된 이유

일본어 깨진 문자를 검색하면 반드시 등장하는 「縺薙繧薙?縺ォ縺。縺ッ」(원래는 「こんにちは」, 즉 「안녕하세요」)라는 문자열은 일본 인터넷 이용자들 사이에서 하나의 문화적 아이콘과도 같은 존재가 되었습니다. 이는 UTF-8로 작성된 텍스트를 Shift_JIS를 전제로 하는 애플리케이션(오래된 Windows 메모장이나 일부 레거시 시스템 등)에서 열었을 때 나타나는 매우 전형적인 깨진 문자 패턴입니다.

이 조합이 이토록 빈번한 이유는, UTF-8에서 일본어 한 글자를 나타내는 3바이트 열을 Shift_JIS 디코더가 2바이트 문자로 억지로 해석하기 때문입니다. 우연히도 그 대부분이 유효한 Shift_JIS 문자로 해석 가능한 범위에 들어맞기 때문에 오류 없이, 「겉보기에는 깨졌지만 사실은 원래대로 되돌릴 수 있는」 특수한 상태가 만들어집니다. 이러한 성질 덕분에 본 도구와 같은 자동 복구가 높은 확률로 성공하는 것입니다.

반면 Shift_JIS로 작성된 문서를 EUC-JP를 전제로 열어버리는 조합에서는 유효하지 않은 바이트열이 발생하여 정보 자체가 손실되는 경우가 많아, 이 경우에는 문자열 수준에서의 복원이 원리적으로 불가능해집니다. 일본어 문자 인코딩 문제가 오랫동안 IT 엔지니어들을 괴롭혀 온 배경에는 이러한 「복원 가능한 깨짐」과 「복원 불가능한 깨짐」이 혼재해 있다는 사정이 있습니다.