자막 한글 깨짐(인코딩) 해결법: UTF-8로 저장해야 하는 이유

자막 파일을 열었더니 한글 자리에 알 수 없는 기호가 줄줄이 나온 적이 있을 겁니다. 파일이 망가진 경우는 드뭅니다. 대부분은 파일을 저장한 방식과 읽는 방식이 서로 달라서 생기는 문제, 즉 문자 인코딩 불일치입니다.

인코딩이 뭐길래 글자가 깨질까?

컴퓨터는 글자를 숫자(바이트)로 바꿔 저장합니다. 어떤 글자를 어떤 바이트로 바꿀지 정한 약속이 인코딩입니다. 문제는 약속이 하나가 아니라는 점입니다. 같은 "가"라도 UTF-8로 저장하면 3바이트, 한국어 전용 옛 방식으로 저장하면 2바이트가 됩니다.

그래서 한 방식으로 저장한 파일을 다른 방식으로 읽으면, 바이트는 그대로인데 글자로 풀어내는 규칙이 달라져 엉뚱한 문자가 나옵니다. 영어와 숫자는 두 방식에서 같은 바이트를 쓰기 때문에 멀쩡하고, 한글만 깨지는 경우가 많은 이유입니다.

한국어 옛 인코딩의 여러 이름

웹 브라우저가 따르는 WHATWG 인코딩 표준은 한국어 옛 인코딩을 EUC-KR 하나로 묶고, euc-kr, windows-949, ks_c_5601-1987, korean 같은 이름을 모두 이 인코딩을 가리키는 라벨로 정해 두었습니다. 프로그램마다 ANSI, CP949, 완성형 등으로 다르게 부르기도 하지만 같은 계열이라고 보면 됩니다.

왜 UTF-8로 맞춰야 할까?

근거는 세 가지입니다.

• 표준: WHATWG 인코딩 표준은 UTF-8이 유니코드를 주고받기에 가장 알맞은 인코딩이라고 밝히고, 새 프로토콜과 포맷에는 UTF-8을 요구합니다.
• 유튜브: 유튜브 고객센터는 .srt와 .sbv 자막 파일이 일반 UTF-8이어야 한다고 안내합니다.
• 영상 컨테이너: Matroska(MKV)는 SRT 자막을 넣을 때 텍스트를 UTF-8로 변환해 담습니다.

UTF-8은 한글, 일본어, 중국어를 한 파일 안에 함께 담을 수 있습니다. 원문과 번역문을 같이 쓰는 이중 자막이라면 더욱 UTF-8이어야 합니다.

LyricFlow에 올리기 전 확인할 점

LyricFlow는 업로드한 자막 파일을 UTF-8로 읽습니다. EUC-KR로 저장된 파일을 그대로 올리면 한글이 깨진 상태로 읽혀 번역 결과도 망가집니다. WHATWG 표준의 UTF-8 해석 과정에서는 규칙에 맞지 않는 바이트가 대체 문자(�)로 바뀔 수 있는데, 미리보기에 이 기호가 보인다면 인코딩부터 의심하세요.

EUC-KR 파일을 UTF-8로 바꾸는 순서

1. 인코딩을 지정해서 다시 열 수 있는 텍스트 편집기로 파일을 엽니다.
2. 한글이 깨져 보이면 편집기의 인코딩 설정을 EUC-KR(또는 CP949, 한국어)로 바꿔 다시 엽니다. 한글이 바르게 보여야 다음 단계로 갑니다.
3. 「다른 이름으로 저장」에서 인코딩을 UTF-8로 골라 저장합니다.
4. 저장한 파일을 다시 열어 한글이 그대로인지 확인합니다.

2번에서 한글이 바르게 보이지 않은 채 저장하면 깨진 글자가 그대로 굳어 버립니다. 원본 파일은 꼭 따로 남겨 두세요.

BOM은 신경 써야 할까?

UTF-8 파일 맨 앞에 BOM이라는 표시 바이트가 붙는 경우가 있습니다. WHATWG 표준의 디코딩 과정은 맨 앞의 UTF-8 BOM을 인식해 건너뛰기 때문에, 이 표준을 따르는 환경에서는 BOM 유무가 텍스트 내용에 영향을 주지 않습니다. 다른 프로그램에서 첫 줄이 이상하게 읽힌다면 그때 BOM 없는 UTF-8로 저장해 보세요.

참고

• WHATWG, Encoding Standard: https://encoding.spec.whatwg.org/
• YouTube 고객센터, 지원되는 자막 파일: https://support.google.com/youtube/answer/2734698?hl=ko
• Matroska, Subtitle Codecs (SRT Subtitles): https://www.matroska.org/technical/subtitles.html