자막이 깨지는 이유?

자막이 특정 플레이어에서 네모, 물음표 또는 의미 없는 기호 나열로 보이면 대부분 "파일이 깨졌다"고 직감합니다. 그러나 대부분의 경우 파일은 멀쩡하고, 인코딩·줄바꿈 문자·파일 머리의 마커 중 하나가 플레이어와 맞지 않을 뿐입니다. 아래 순서로 점검하면 보통 원인을 특정할 수 있고, 각 단계에 명확한 판단 기준이 있어 맞히기식 시행착오가 필요 없습니다.

먼저 분류하기: 깨짐인가, 형식 오류인가

글자가 네모·물음표·뒤틀린 기호로 보이지만 줄 수와 구조는 그대로 — 이것은 인코딩 문제로, 이 글이 다루는 대상입니다. 반대로 일련번호와 타임코드가 어긋나거나 자막이 통째로 날아가는 전체 밀림이라면 형식이나 타임코드 문제로, 자막 규격 검사 도구 나 자막 정리 도구 로 처리합니다. 두 부류를 먼저 가르지 않으면 점검 방향이 빗나갑니다.

1단계: 인코딩 확인 — UTF-8(무 BOM) 우선

요즘 플레이어와 플랫폼 대부분은 기본으로 UTF-8로 읽습니다. 파일이 GBK이거나 BOM이 붙은 UTF-8이면 오래된 플레이어는 글자를 잘못 표시합니다.

에디터에서 "UTF-8(무 BOM)"으로 다시 저장합니다. 메모장이라면 저장 대화상자의 인코딩에서 UTF-8을 고르고 "UTF-8 with BOM"은 고르지 않습니다. 중국어·일본어·한국어 자막은 특히 UTF-8이어야 하며, 그렇지 않으면 깨짐이 확정됩니다. 현재 인코딩을 모르겠다면 인코딩 감지 기능이 있는 에디터(예: VS Code)로 열면 상태 표시줄에 실제 인코딩이 나타납니다. 그걸 기준으로 저장하면 됩니다. 변환 후 플레이어에서 다시 열어 네모가 사라졌는지 확인합니다.

판단 기준: 파일 전체가 한꺼번에 네모나 깨진 글자로 변했다면(개별 문자만이 아니라) 거의 확실히 인코딩 문제입니다. 중국어만 네모로 변하고 영어는 정상이면 중국어 인코딩이 인식되지 않은 것이고, 이 역시 줄바꿈이 아니라 인코딩 문제입니다. SmileSub가 내보내는 자막은 기본 UTF-8이라 플랫폼을 넘나들어도 안전합니다. SRT의 표준 작성법은 이중 언어 SRT 형식 해설 을 참고하세요.

2단계: 줄바꿈 문자 확인

Windows는 CRLF(\r\n), Unix와 macOS는 LF(\n)를 씁니다. 아주 일부 오래된 도구는 한쪽만 받아들이며, 줄바꿈이 맞지 않으면 줄들이 붙어 버립니다.

에디터에서 보이지 않는 문자 표시를 켜고 줄바꿈이 LF인지 CRLF인지 확인한 뒤, 대상 플랫폼이 요구하는 쪽으로 통일합니다 — 보통은 LF가 더 무난합니다. 저장 후 자막을 다시 불러옵니다.

판단 기준: 자막 줄 사이가 갈라지지 않고 덩어리로 붙는다면, 인코딩이 아니라 줄바꿈 문자 문제일 가능성이 높습니다.

3단계: 파일 머리의 BOM

BOM은 파일 맨 앞에 붙는 몇 바이트의 보이지 않는 데이터로, 인코딩의 표식입니다. 대부분의 도구는 무시하지만 일부 플레이어는 BOM을 본문으로 표시해 첫 자막 앞에 깨진 문자열이 붙습니다.

십육진 보기나 "UTF-8(무 BOM)로 저장"으로 제거합니다. 제거 후 첫 자막 앞의 수상한 문자열이 사라지면 BOM이 원인으로 확정입니다. 이후 내보내기는 모두 무 BOM으로 통일하면 다시는 발생하지 않습니다.

판단 기준: 첫 자막 앞에만 수상한 문자 몇 개가 붙고 뒤는 모두 정상 — 거의 확실히 BOM이 범인입니다.

수리와 예방

점검 순서는 고정입니다. 인코딩 → 줄바꿈 → BOM. 바깥쪽부터 해결하고 파일 머리는 마지막에 봅니다. OS 간 복사(Windows와 macOS 사이)는 인코딩과 줄바꿈이 자동 변환되기 가장 쉬운 상황이니, 가능하면 대상 시스템에서 내보냅니다.

일상 워크플로는 한 줄로 정리됩니다. 저장은 UTF-8 무 BOM, 줄바꿈은 LF. 이것만으로 이후 모든 단계가 편해집니다. 내보낸 뒤에는 플레이어와 에디터에서 각각 한 번씩 열어 중국어·일본어·한국어가 모두 정상 표시되는지 확인하고 하류로 넘깁니다. 한 가지 더 조심할 점: 편집 도중에 인코딩을 바꾸지 마세요. UTF-8 파일을 딱 한 번이라도 GBK로 저장해 버리면 깨짐이 내용에 용접되어 버려, 원본에서 다시 내보내는 수밖에 없습니다.

자막 형식 선택은 자막 형식 선택 가이드 를 참고하세요.

자주 묻는 질문

같은 SRT인데 플레이어에 따라 정상·깨짐이 갈리는 이유는?

대개 인코딩이나 BOM의 차이입니다. 플레이어마다 UTF-8과 BOM 처리가 달라서, UTF-8 무 BOM으로 통일하면 보통 양쪽 다 정상이 됩니다.

줄바꿈 문자가 정말 표시에 영향을 주나요?

요즘 소프트웨어 대부분은 두 종류의 줄바꿈을 모두 받아들이지만, 일부 오래된 도구나 임베디드 플레이어는 한쪽만 인정해 줄 붙음이나 타임코드 어긋남을 일으킵니다. 점검할 가치가 있습니다.

발생원에서 깨짐을 막으려면?

저장과 내보내기 모두 UTF-8 무 BOM, 줄바꿈은 LF로 통일하고, 시스템 사이 복사로 인한 자동 변환을 피합니다. 온라인 도구로 내보낸 자막은 이미 이 기준으로 처리돼 있습니다.