먼저 알아둘 기준

‘占쏙옙’이나 물음표가 반복되는 현상은 보통 문자 바이트를 잘못 해석한 결과입니다. CP949 바이트를 UTF-8로 읽거나, UTF-8을 오래된 시스템 코드 페이지로 읽는 경우가 대표적입니다.

스프레드시트 프로그램은 CSV에 인코딩 정보가 명시되지 않으면 운영체제 설정으로 추측하기도 합니다. 그래서 편집기에서는 정상인 UTF-8 CSV가 특정 버전의 프로그램에서만 깨질 수 있습니다.

이미 잘못 디코딩된 문자를 다시 저장하면 정보 손실이 고정될 수 있습니다. U+FFFD 대체문자나 물음표로 바뀐 원래 바이트는 보통 텍스트만으로 복원할 수 없으므로 최초 파일 복사본이 중요합니다.

실제 작업에서 보는 사례

01

CP949 CSV를 UTF-8로 강제 열어 한글 위치마다 대체문자가 나타납니다.

02

UTF-8 CSV가 스프레드시트에서만 깨질 때 UTF-8 BOM 사본으로 열어 봅니다.

03

UTF-16 LE 파일을 8비트 인코딩으로 읽으면 글자 사이에 NUL처럼 보이는 문자가 섞입니다.

단계별로 확인하는 방법

  1. 1

    깨진 파일을 덮어쓰지 말고 원본 복사본을 보관합니다.

  2. 2

    파일 출처와 만든 프로그램을 확인해 인코딩 후보를 좁힙니다.

  3. 3

    후보별 미리보기에서 드문 한글과 특수기호까지 점검합니다.

  4. 4

    올바른 결과를 UTF-8 새 이름으로 저장하고 대상 프로그램에서 다시 엽니다.

주의할 점

  • 문자가 이미 ? 또는 대체문자로 저장됐다면 단순 재인코딩으로 원래 글자를 복구할 수 없습니다.
  • CSV의 구분자 문제와 인코딩 문제는 별개이므로 열이 밀린 현상을 한글 깨짐으로 오해하지 않아야 합니다.

기술적 제한

  • 잘못된 디코딩 뒤 정보가 소실된 문자열에서는 원래 바이트를 일반적으로 역추정할 수 없습니다.
  • 통계적 인코딩 감지는 서로 겹치는 바이트 범위 때문에 오탐 가능성이 있습니다.