자막에 BOM 추가
또는 자막 텍스트를 붙여넣으세요
옵션
BOM은 파일 맨 앞의 세 바이트로, 어떤 문자 인코딩인지 알려 줍니다. 어떤 편집기에서도 플레이어에서도 보이지 않고 화면 자리도 차지하지 않으며, 붙거나 빠져도 자막 내용은 달라지지 않습니다. 이걸 신경 쓰는 도구는 두 종류입니다. 자막을 쓰는 Windows 프로그램은 기본으로 붙이고, 빌드 파이프라인의 엄격한 파서는 BOM으로 시작하는 파일을 거부합니다. 이 페이지는 제목이 말하는 상태로 상자를 열어 주므로, 파일이 반대 상태였다면 바로 뒤집을 수 있습니다. UTF-16 파일은 항상 BOM을 가집니다. 리더가 두 바이트 순서 중 어느 쪽인지 아는 방법이 그것이기 때문입니다. 그래서 UTF-16에서 BOM 제거를 요청해도 그대로 남습니다.
타이밍을 어떤 프레임 레이트 기준으로 세는지 정합니다. 형식 안내 페이지에서는 MicroDVD가 이 값을 필요로 합니다. 시간을 프레임 번호로 저장하기 때문입니다. 프레임 레이트 페이지에서는 이 파일이 어느 프레임 레이트를 기준으로 만들어졌는지, 즉 자막을 만든 판본의 값을 뜻하며, 페이지의 두 번째 상자에는 이 자막을 사용할 영상의 프레임 레이트를 넣습니다. 흔히 쓰는 값은 23.976, 24, 25, 29.97, 30, 50, 59.94, 60입니다. 잘못 넣으면 시간축 전체가 어긋나고, 프레임 레이트 페이지에서는 고정된 양이 아니라 비율로 어긋납니다.
이 페이지는 자막 파일 맨 앞에 바이트 순서 표시(BOM)를 붙입니다. UTF-8에서 U+FEFF를 EF BB BF 세 바이트로 쓰는 것이고, 눈에 보이지 않는 한 글자입니다. 큐도 번호도 타임코드도 줄 바꿈도 그대로이고, 파일의 첫 세 바이트만 달라집니다. 오래된 Windows 재생기나 편집기가 UTF-8 파일을 다른 인코딩으로 잘못 읽을 때 쓰는 표시입니다.
BOM과 CRLF는 자주 뒤섞이지만 별개입니다. Windows용 자막 도구가 둘 다 쓰는 경우가 많아서 한 덩어리로 보이기 때문입니다. 이 페이지는 BOM만 씁니다. CRLF가 가득한 파일은 CRLF로 남고, LF 파일은 LF로 남으며, 섞인 파일은 섞인 채로 돌아옵니다. 줄 바꿈을 바꾸는 것은 별도 페이지이고, 한 페이지가 둘을 조용히 함께 하면 도구가 알아차리지 못하는 재포맷이 됩니다.
이미 BOM이 있는 파일은 바이트 단위로 그대로 돌아옵니다. 페이지가 자기 표시를 쓰기 전에 있던 표시를 먼저 지우기 때문입니다. 그래서 같은 파일에 두 번 실행해도 결과가 같고, 표시가 둘 붙은 파일도 한 번 통과시키면 하나만 남습니다. 표시 하나와 둘은 편집기에서는 똑같이 보이지만 파일을 여는 바이트를 읽는 프로그램에게는 서로 다른 파일입니다.
업로드는 없고, 이 페이지는 형식에 관계없이 모든 자막 파일에서 동작합니다. 표시는 자막 내용이 아니라 완성된 파일의 성질이므로, 납품 직전의 마지막 단계에서 붙이는 것이 순서상으로도 맞습니다.
예시
ASCII 자막 파일 앞에 표시 하나
입력
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
결과물
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
결과 텍스트는 첫 큐 번호의 1 앞에 보이지 않는 U+FEFF, 곧 EF BB BF 세 바이트로 시작합니다. 두 창은 똑같아 보이고 그것은 렌더링 오류가 아닙니다. 두 파일의 차이는 3바이트이고 그중 어느 것도 모양이 없습니다. 결과를 내려받아 인코딩을 보여 주는 편집기로 열거나 헥스 뷰어로 첫 바이트를 보면 가장 먼저 보입니다.
Windows 파일, 표시만 더하고 캐리지 리턴은 유지
입력
1
00:00:01,000 --> 00:00:02,000
The room is dark.
결과물
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Windows용 자막 도구가 쓰는 두 가지가 표시와 CRLF 줄 바꿈이라서 뒤섞이지만, 둘은 별개이고 이 페이지는 첫째만 씁니다. 결과 파일의 캐리지 리턴은 전부 입력의 것이고 표시는 그 앞에 더해집니다. 줄 바꿈까지 다시 쓰는 페이지는 건네받은 모든 파일을 조용히 재포맷하는데, 하위 도구가 신경 쓰기 전까지 아무도 알아차리지 못하는 종류의 변화입니다.
이미 표시가 있는 파일
입력
1
00:00:01,000 --> 00:00:02,000
Already marked.
결과물
1
00:00:01,000 --> 00:00:02,000
Already marked.
입력에 이미 표시가 있으므로 출력은 입력 바이트 그대로이고, 파일은 표시를 정확히 하나 유지합니다. 있던 표시를 지우지 않고 새로 붙이는 순진한 구현은 표시가 둘인 파일을 만들고, 두 개가 된 표시는 어느 편집기에서도 보이지 않으면서 파일을 여는 바이트를 읽는 것에게는 다른 파일이 됩니다. 이미 표시가 있는 파일에 이 페이지를 돌리는 일은 생각 없이 할 수 있어야 합니다.
자주 묻는 질문
자막 파일에 BOM을 더하면 실제로 무엇이 달라지나요?
파일 맨 앞의 한 글자, UTF-8에서 EF BB BF 세 바이트로 쓰이는 U+FEFF입니다. 큐가 더해지거나 지워지거나 편집되지 않고, 타임코드도 움직이지 않으며, 큐 번호와 줄 바꿈은 들어온 그대로 나옵니다. 모든 줄의 텍스트도 그대로입니다. 두 파일을 비교하면 다른 줄은 첫 줄 하나뿐이고, 그 줄은 시작 부분의 3바이트에서 다릅니다.
BOM 추가 페이지의 두 창이 똑같아 보이는 이유는 무엇인가요?
더해지는 글자에 모양이 없기 때문입니다. U+FEFF는 폭이 없는 줄 바꿈 없는 공백이라서 플레이어처럼 텍스트를 그리는 창은 전후가 같아 보입니다. 변화는 실제이고 내려받는 파일 안에 있습니다. 차이는 첫 3바이트입니다. 편집기의 인코딩 표시나 시작 부분에 EF BB BF를 보여 주는 헥스 뷰어가 텍스트 대신 볼 자리입니다.
같은 파일에 BOM 추가를 두 번 실행해도 안전한가요?
네. 페이지가 자기 표시를 쓰기 전에 이미 있는 표시를 지우므로, 이미 하나를 가진 파일은 그대로 돌아오고 없는 파일은 정확히 하나를 얻습니다. 두 번 실행한 결과가 한 번 실행한 결과와 같습니다. 이 페이지를 거친 파일에 다른 도구가 두 번째 표시를 더한 경우에도 한 번 더 통과시키면 정리됩니다. 하나만 살아남기 때문입니다.
나중에 자막을 다른 형식으로 변환해도 표시가 유지되나요?
이 사이트의 변환 페이지는 표시 없는 일반 UTF-8을 쓰므로 형식이 바뀌면 표시가 따라가지 않습니다. 작업 순서를 그에 맞추세요. 먼저 변환하고, 납품 직전 마지막 단계에서 표시를 붙이는 것입니다. 표시는 자막 내용이 아니라 완성된 파일의 성질이라서 일반적으로도 그 순서가 더 합리적입니다.
BOM을 더하면 자막 파일의 줄 바꿈이 달라지나요?
아니요. 표시는 파일의 첫 바이트 앞에 놓이는 한 글자이고 뒤따르는 것에 영향을 주지 않습니다. CRLF로 가득한 Windows 파일은 CRLF로 남고, Unix 파일은 LF로 남으며, 섞인 파일은 들어온 그 혼합 그대로 나옵니다. 줄 바꿈 변경은 별도 페이지이고, 한 페이지가 둘을 조용히 함께 하는 것은 좋지 않은 생각입니다.
어떤 자막 형식에 바이트 순서 표시를 붙일 수 있나요?
이 사이트가 다루는 열두 형식 전부입니다. SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON, CSV입니다. 표시는 자막 형식이 아니라 파일의 시작 바이트에 관한 것이라서 형식별로 맞출 것이 없습니다. 시간축이 아예 없는 일반 텍스트 전사문도 표시를 가질 수 있습니다.