ANSI·CP949·EUC-KR·UTF-8 차이와 한글 깨짐을 복구하는 순서

ANSI는 왜 정확한 인코딩 이름이 아닌가요?

Windows 프로그램에서 ANSI라고 표시한 값은 흔히 시스템의 현재 비유니코드 코드 페이지를 뜻합니다. 한국어 환경에서는 코드 페이지 949일 가능성이 있지만 다른 언어 환경에서는 전혀 다른 문자표일 수 있습니다. 파일 전달 문서에는 ANSI 대신 windows-949, UTF-8처럼 실제 인코딩을 기록해야 재현할 수 있습니다.

CP949와 EUC-KR은 완전히 같은가요?

CP949는 Microsoft의 한국어 코드 페이지이며 통상적인 EUC-KR 범위보다 더 많은 한글 조합을 다루는 구현으로 사용돼 왔습니다. 웹의 WHATWG Encoding 표준은 여러 레거시 라벨을 euc-kr 디코더로 모아 호환되게 처리합니다. 파일 변환 도구가 어떤 라벨과 매핑을 쓰는지 확인하고, 이름만 보고 바이트 호환성을 단정하지 마세요.

UTF-8로 잘못 읽은 레거시 파일은 어떻게 복구하나요?

원본 바이트가 남아 있다면 UTF-8 디코딩 결과와 euc-kr 계열 디코딩 결과를 각각 미리 봅니다. 조사와 받침뿐 아니라 원화 기호, 괄호, 특수문자와 드문 이름도 자연스러운지 비교하세요. 맞는 디코딩을 찾은 뒤에만 유니코드 문자열을 UTF-8 바이트로 새 파일에 저장합니다.

어떤 깨짐은 왜 되돌릴 수 없나요?

디코더가 해석하지 못한 바이트를 대체 문자 �로 바꾸거나 프로그램이 표현할 수 없는 글자를 ?로 저장하면 서로 다른 원문이 같은 문자로 소실됩니다. 이 결과를 덮어쓴 파일에는 원래 바이트를 추론할 정보가 없습니다. 백업, 메일 첨부 원본이나 생성 시스템에서 다시 받아야 합니다.

단계별로 확인하는 방법

1. 원본 바이트 복사하기

   깨진 파일을 그대로 복제하고 편집기에서 저장하지 않은 원본을 별도로 보관합니다.

2. 생성 환경 단서 모으기

   파일을 만든 운영체제·프로그램·지역 설정과 전달받은 인코딩 안내를 확인합니다.

3. 후보 인코딩으로 미리 보기

   UTF-8과 euc-kr 계열을 각각 적용해 한글, 특수문자와 행 구분이 가장 자연스러운 결과를 고릅니다.

4. 새 UTF-8 파일로 저장하기

   선택한 결과를 새 이름으로 저장하고 �, ?, 누락된 문자와 전체 행 수를 원본과 대조합니다.

함께 보면 좋은 글

• EUC-KR 한글 깨짐을 복구하는 기본 원리
• GIF에서 대표 프레임을 썸네일로 추출하기

메모장의 ANSI는 항상 CP949인가요?

항상 그렇지 않습니다. 시스템 언어와 비유니코드 프로그램용 코드 페이지에 따라 값이 달라질 수 있습니다. 파일을 만든 환경의 코드 페이지 번호를 확인하세요.

CP949 파일을 euc-kr로 읽으면 모든 한글이 나오나요?

공통 범위는 읽힐 수 있지만 CP949 확장 영역의 문자는 실패하거나 다른 문자로 보일 수 있습니다. 도구가 WHATWG 호환 디코더인지, 엄격한 EUC-KR 구현인지 확인해야 합니다.

깨진 문자열을 복사해서 다시 변환해도 되나요?

복사 과정에서 이미 유니코드 문자로 확정되므로 원본 바이트가 사라질 수 있습니다. 가능하면 깨진 화면의 문자열이 아니라 원본 파일 바이트를 입력으로 사용하세요.

물음표로 바뀐 한글을 자동으로 되살릴 수 있나요?

여러 원문 문자가 같은 물음표로 치환됐다면 정보가 소실되어 정확한 역변환은 불가능합니다. 백업이나 발신자가 가진 원본을 다시 확보해야 합니다.