PRELAPS 깨진 글자 복구기

메모장에서 UTF-8 로 저장했는데도 깨질 때

저장할 때 인코딩을 UTF-8 로 분명히 골랐는데, 그 파일을 엑셀이나 다른 프로그램에서 열면 ë³´ê³ ì„œ 나 º¸°í¼­ 처럼 나오는 경우입니다. 골랐는데 왜 안 되냐는 게 이 글의 주제입니다.

메모장의 저장 선택지가 헷갈린다

「다른 이름으로 저장」 창 아래쪽에 인코딩 드롭다운이 있습니다. 윈도우 버전에 따라 항목이 조금씩 다른데, 대체로 이렇습니다.

여기서 「유니코드」를 고르고 UTF-8 을 골랐다고 기억하는 것이 가장 흔한 착각입니다. UTF-16 으로 저장된 파일은 UTF-8 을 기대하는 프로그램에서 통째로 이상하게 나오거나 아예 안 열립니다.

ANSI 는 표준이 아니다

ANSI 는 미국표준협회 이름이라 규격처럼 들리는데, 윈도우에서 이 단어는 「이 컴퓨터의 지역 코드페이지」라는 뜻입니다. 한국어 윈도우에서는 CP949(EUC-KR 확장), 일본어 윈도우에서는 Shift_JIS, 서유럽에서는 Windows-1252 입니다.

즉 ANSI 로 저장한 파일은 컴퓨터마다 다른 뜻이 됩니다. 한국에서 만든 ANSI 파일을 일본 윈도우에서 열면 깨지고, 반대도 마찬가지입니다. 같은 회사 안에서도 윈도우 언어가 다르면 이 일이 납니다.

오래된 문서가 지금 와서 깨지는 이유가 대개 이것입니다. 그때는 모두가 같은 코드페이지를 썼으니 문제가 없었을 뿐입니다.

기본값이 중간에 바뀌었다

Windows 10 의 2019년 업데이트(1903) 부터 메모장의 기본 인코딩이 ANSI 에서 UTF-8 로 바뀌었습니다. 그 전에 만든 파일과 그 후에 만든 파일이 한 폴더에 섞여 있을 수 있다는 뜻입니다.

그래서 이런 상황이 생깁니다 — 같은 폴더의 메모 파일 중 어떤 것은 멀쩡히 열리고 어떤 것은 깨집니다. 파일마다 인코딩이 다른 것이고, 파일 이름이나 아이콘으로는 전혀 구분되지 않습니다.

BOM 은 있어야 할 때와 없어야 할 때가 다르다

BOM 은 파일 맨 앞에 붙는 세 바이트짜리 표시입니다. 「이 파일은 UTF-8 이다」라고 알려주는 역할이고, 눈에는 안 보입니다. 문제는 이걸 원하는 쪽과 싫어하는 쪽이 갈린다는 것입니다.

그래서 「UTF-8 이면 다 되는 것」이 아닙니다. 어디에 줄 파일이냐에 따라 BOM 을 붙일지 말지가 갈립니다. 메모장에 두 항목이 따로 있는 버전이라면 받는 쪽에 맞춰 고르세요.

파일은 UTF-8 인데 받는 쪽이 못 읽는 경우

저장은 제대로 됐는데 여는 프로그램이 추측에 실패하는 경우도 있습니다. 텍스트 파일에는 인코딩을 적는 자리가 없어서, BOM 이 없으면 프로그램이 내용을 보고 짐작해야 합니다.

짧은 파일일수록 짐작이 틀립니다. 한글 몇 글자만 든 메모는 판단할 근거 자체가 부족합니다. 같은 내용이 긴 파일에서는 제대로 열리는데 짧은 파일에서만 깨진다면 이쪽입니다.

지금 무슨 인코딩인지 확인하는 법

메모장으로 파일을 열면 창 아래쪽 상태 표시줄 오른쪽에 현재 인코딩이 표시됩니다. 안 보이면 「보기 → 상태 표시줄」을 켜세요. 여기서 UTF-8 이 아니라 ANSI 로 떠 있으면 원인을 찾은 것입니다.

다만 이 표시도 추측에 기댑니다. 깨져 보이는 파일을 메모장으로 열었을 때 이미 깨져 있다면, 표시된 인코딩이 맞는지도 의심해야 합니다.

이 도구로 고치는 법

깨진 글자 복구기의 파일 탭에 그대로 올리세요. 어떤 인코딩으로 저장됐는지 판별해 후보를 보여주고, 한글이 제대로 보이는 것을 골라 UTF-8 로 다시 받으면 됩니다.

받을 때 「엑셀에서 열 파일이면 BOM 붙이기」 체크박스를 상황에 맞게 맞추세요. .csv·.tsv·.txt 는 기본으로 켜져 있습니다. 셸 스크립트나 설정 파일이라면 꺼야 합니다.

파일은 서버로 올라가지 않습니다. 브라우저 안에서만 처리되므로 사내 자료도 그대로 쓰셔도 됩니다.

다음부터 안 깨지게 하려면