자막에서 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 파일이라면 첫 세 바이트 EF BB BF가 사라지고, 그 밖의 것은 그대로 남습니다. 큐도 타임코드도 줄 바꿈도 번호도 바뀌지 않습니다. 파일 앞의 보이지 않는 글자 하나 때문에 빌드 단계나 엄격한 파서가 실패할 때 쓰는 페이지입니다.
BOM은 CRLF와 자주 뒤섞이지만 별개입니다. Windows 도구가 둘 다 쓰는 경우가 많아서 한 덩어리로 보이기 때문입니다. 이 페이지는 표시만 없애고 줄 바꿈에는 관여하지 않습니다. CRLF가 가득한 파일은 CRLF로 남고, 섞인 파일은 섞인 채로 남습니다. 둘 다 바꾸고 싶다면 줄 바꿈 페이지를 따로 쓰세요. 둘을 분리해 두는 것이 열어 보지 않은 파일에도 각각을 안전하게 돌릴 수 있게 하는 이유입니다.
표시가 없는 파일은 바이트 단위로 그대로 돌아옵니다. 지울 것이 없었기 때문입니다. 이 경우가 먼저 표시를 쓰고 나중에 벗겨 내는 구현이나 지나가는 길에 파일을 정규화하는 구현을 잡아냅니다. 할 일이 없었다는 정직한 해석은 입력 그 자체이지 정돈된 판본이 아닙니다. 같은 이유로 표시가 둘 붙은 파일도 한 번에 정리됩니다. 페이지가 하나만이 아니라 모두 지우기 때문입니다.
한 가지 예외가 있습니다. UTF-16 파일의 표시는 남습니다. UTF-16은 모든 글자를 2바이트로 저장하고 두 바이트 순서가 밖에서 보면 비슷하므로, 표시가 어느 순서인지 알려 주는 역할을 합니다. 표시가 없는 UTF-16 파일은 이 사이트에서도 다른 어디에서도 다시 읽을 수 없습니다. 표시가 전혀 없는 파일이 필요하면 인코딩을 UTF-8이나 Windows-1252로 바꾸세요. 업로드는 없습니다.
예시
표시가 있던 파일에서 표시를 뗀 결과
입력
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.
입력은 U+FEFF로 시작하고 출력은 그렇지 않습니다. 두 파일은 정확히 그 한 글자만큼 다르고 그것이 작업의 전부입니다. 이 상태의 파일은 보통 Windows 자막 프로그램에서 나오고, 표시를 없애려는 이유는 큐가 아니라 시작 바이트를 보는 빌드 단계나 엄격한 파서입니다.
Windows 파일, 표시만 지우고 캐리지 리턴은 유지
입력
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
결과물
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
표시만 갑니다. 모든 캐리지 리턴은 파일의 것이고 이 페이지는 그것에 관여하지 않습니다. 둘 다 바꾸고 싶은 사람은 줄 바꿈 페이지를 원하는 것이고, 둘을 분리해 두는 것이 열어 보지 않은 파일에 각각을 안전하게 돌릴 수 있게 합니다. 결과 텍스트는 입력과 똑같이 CRLF를 유지합니다.
표시가 없어 바이트 그대로 돌아오는 파일
입력
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.
지울 것이 없어서 파일이 표시가 없다는 사실까지 그대로 돌아옵니다. 이 경우가 먼저 표시를 쓰고 나중에 벗겨 내는 구현이나 지나가는 길에 파일을 정규화하는 구현을 잡아냅니다. 할 일이 없었다는 정직한 해석은 입력 바이트 그 자체이지 그것을 정돈한 판본이 아닙니다.
자주 묻는 질문
자막 파일에 바이트 순서 표시가 있는지 어떻게 알 수 있나요?
파일 인코딩을 보여 주는 편집기로 열면 표시가 있는 UTF-8 파일은 보통 그냥 UTF-8이 아니라 UTF-8 with BOM이나 UTF-8 BOM으로 표시됩니다. 아니면 헥스 뷰어로 첫 바이트를 보세요. EF BB BF로 시작하면 있고, 첫 큐 글자로 시작하면 없습니다. 첫 줄 앞의 기호 덩어리는 표시를 평범한 세 글자로 읽은 프로그램이 보는 같은 것입니다.
표시를 없앤 뒤에도 UTF-16 자막 파일에 표시가 남는 이유는 무엇인가요?
UTF-16 파일에는 표시가 필요하기 때문입니다. UTF-16은 모든 글자를 2바이트로 저장하고 두 바이트 순서가 밖에서 보면 비슷하므로, 표시가 어느 순서인지 알려 줍니다. 표시가 없는 UTF-16 파일은 이 사이트에서도 다른 어디에서도 다시 읽을 수 없습니다. 그래서 이 페이지는 그것을 남깁니다. 표시가 전혀 없는 파일이 필요하면 인코딩을 UTF-8이나 Windows-1252로 바꾸세요. 그쪽에서는 표시가 선택 사항입니다.
표시가 없던 자막 파일을 이 페이지가 망가뜨리나요?
아니요. 그 경우의 출력은 입력 바이트 그대로이고 아무것도 보고되지 않습니다. 상태가 확실하지 않은 파일에 페이지를 돌려도 안전한 이유도 같습니다. 지울 표시가 없으면 쓸 것이 없고, 있으면 가능한 가장 작은 변화만 합니다. 할 일을 찾지 못한 실행은 일을 한 실행이 아닙니다.
자막 파일에 표시가 두 개 이상 있을 수 있나요?
네. 표시가 있는지 확인하지 않고 새로 붙이는 도구를 거치면 생깁니다. 두 번째 표시는 편집기에서는 완전히 정상으로 보이면서 파일의 시작 바이트에서는 정상 파일과 다른 파일을 만듭니다. 이 페이지는 하나가 아니라 모두 지우므로 표시가 둘인 파일도 한 번에 정리되고, 다시 실행해도 더 달라지지 않습니다.
표시를 없애면 자막 파일의 인코딩이 바뀌나요?
사람들이 보통 뜻하는 의미에서는 아니요. 파일의 텍스트는 같은 글자이고 나머지도 같은 방식으로 인코딩되어 있습니다. 달라지는 것은 읽는 쪽이 더 이상 파일의 시작 바이트에서 인코딩을 알 수 없다는 것입니다. 표시 없는 UTF-8 파일은 평범한 UTF-8이고 대부분의 도구가 어차피 그것을 가정합니다. 인코딩 자체를 바꾸는 것은 별도 페이지의 일입니다.
자막 파일을 내려받으면 표시가 다시 생기나요?
아니요. 내려받기가 파일을 쓰는 시점이고 이 페이지의 실행은 표시 없이 씁니다. 그래서 받는 것이 두 창이 설명하는 그대로입니다. 파일을 쓰는 인코딩은 읽은 방식에서 유지되고 예외가 하나 있습니다. UTF-16으로 들어온 파일은 UTF-16으로 다시 쓰이며 표시를 유지합니다. 그 표시가 장식이 아니라 구조이기 때문입니다.