자막 문자 인코딩 변환
또는 자막 텍스트를 붙여넣으세요
옵션
바뀌는 것은 바이트이지 자막이 아닙니다. 파일의 모든 글자가 고른 인코딩으로 쓰이므로, 특정 인코딩을 고집하는 플레이어나 스크립트도 읽을 수 있는 파일을 받습니다. UTF-8은 요즘 모든 것이 기대하는 인코딩이고 이 사이트가 다른 곳에서 쓰는 인코딩입니다. BOM이 붙은 UTF-8은 같은 바이트 앞에 세 바이트 표시가 붙은 것입니다. UTF-16 LE는 Windows 프로그램이 유니코드라고 부르는 것이며 크기가 대략 두 배입니다. Windows-1252는 서유럽의 옛 인코딩으로 글자당 1바이트이고, 이것만은 조심해야 합니다. 중국어, 일본어, 한국어, 키릴 문자, 그리스 문자, 이모지를 담을 자리가 없어서 쓸 수 없는 글자마다 물음표로 나오고 위 보고서에 집계됩니다. 그 밖에 파일에서 달라지는 것은 없습니다.
타이밍을 어떤 프레임 레이트 기준으로 세는지 정합니다. 형식 안내 페이지에서는 MicroDVD가 이 값을 필요로 합니다. 시간을 프레임 번호로 저장하기 때문입니다. 프레임 레이트 페이지에서는 이 파일이 어느 프레임 레이트를 기준으로 만들어졌는지, 즉 자막을 만든 판본의 값을 뜻하며, 페이지의 두 번째 상자에는 이 자막을 사용할 영상의 프레임 레이트를 넣습니다. 흔히 쓰는 값은 23.976, 24, 25, 29.97, 30, 50, 59.94, 60입니다. 잘못 넣으면 시간축 전체가 어긋나고, 프레임 레이트 페이지에서는 고정된 양이 아니라 비율로 어긋납니다.
이 페이지는 자막 파일을 다른 문자 인코딩으로 다시 씁니다. 고를 수 있는 대상은 네 가지입니다. 표시 없는 UTF-8, BOM이 붙은 UTF-8, UTF-16LE, Windows-1252입니다. 기본값은 UTF-8이고 이 사이트의 다른 페이지들이 쓰는 인코딩이기도 합니다. 글자 자체는 그대로이고, 그 글자를 바이트로 바꾸는 규칙만 달라집니다.
인코딩과 형식은 다릅니다. 형식은 큐 번호와 타임코드와 텍스트를 어떻게 배치하는지를 정하는 것으로 눈에 보입니다. 인코딩은 그 글자를 어떤 바이트로 저장하는지를 정하는 것으로 보이지 않습니다. 같은 SRT 파일이 UTF-8, UTF-16, Windows-1252로 저장될 수 있고 편집기에서는 똑같이 보입니다. 이 페이지는 둘째를 바꾸고 첫째는 그대로 두며, 형식 변환은 변환 페이지의 일입니다.
대상 인코딩이 표현할 수 없는 글자는 물음표가 되고, 페이지가 내려받기 전에 몇 글자인지 알려 줍니다. Windows-1252는 서유럽 문자만 담고 일본어·중국어·한국어·키릴 문자·그리스 문자·이모지를 위한 바이트가 없어서 어떤 형태로도 살릴 수 없습니다. 오류가 나지도 않고 뜻을 유지하는 대체도 없습니다. 손실 보고서의 숫자는 작성기가 쓰는 것과 같은 표에서 계산한 물음표의 개수입니다.
두 창이 똑같아 보이는 것은 정상입니다. 창은 글자를 담고 있고 선택은 바이트에 관한 것이기 때문입니다. 각 글자가 1바이트인지 2바이트인지는 파일을 쓰는 내려받기 시점에 정해집니다. 대기열의 줄은 각 파일을 어떤 인코딩으로 읽었는지 적고, 쓸 인코딩이 다르면 두 번째 표시를 더합니다. 업로드는 없습니다.
예시
UTF-8로 쓰인 영어 자막
입력
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-16LE로
입력
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 자막 프로그램이 유니코드라고 부르는 인코딩이고, 파일에 가장 큰 눈에 보이는 차이를 내는 인코딩입니다. 모든 글자가 2바이트가 되고 앞에 표시가 붙으며 결과 크기가 대략 두 배가 됩니다. 창에는 그 어느 것도 보이지 않습니다. 창은 글자를 담고 있기 때문입니다. 파일 관리자의 크기와 편집기의 인코딩 표시가 차이를 보여 주는 자리입니다.
일본어 자막을 Windows-1252로
입력
1
00:00:01,000 --> 00:00:02,000
こんにちは
결과물
1
00:00:01,000 --> 00:00:02,000
こんにちは
가나 다섯 글자와 그중 어느 것도 담을 자리가 없는 인코딩이라서, 이 실행의 손실 보고서는 물음표가 되는 글자 다섯 개를 셉니다. 창에는 여전히 가나가 보입니다. 대체가 파일을 읽을 때가 아니라 쓸 때 일어나기 때문입니다. 이 분리는 의도된 것입니다. 파일이 무엇을 말하는지와, 이렇게 쓰면 무엇을 포기하는지를 보고서에서 함께 보게 됩니다.
자주 묻는 질문
자막 파일의 인코딩과 형식은 어떻게 다른가요?
형식은 큐 번호와 타임코드와 텍스트를 파일이 어떻게 배치하는지를 정하는 것으로 SRT, WebVTT, ASS 같은 것이며 읽어서 알 수 있습니다. 인코딩은 그 글자를 어떤 바이트로 바꾸는지를 정하는 것으로 보이지 않습니다. 같은 SRT 파일이 UTF-8, UTF-16, Windows-1252로 저장되어도 모든 편집기에서 똑같이 보입니다. 이 페이지는 둘째를 바꾸고 첫째는 그대로 두며, 변환 페이지가 첫째를 바꿉니다.
대상 인코딩이 표현할 수 없는 글자는 어떻게 되나요?
물음표로 쓰이고, 페이지가 내려받기 전에 몇 글자인지 알려 줍니다. Windows-1252는 서유럽 문자를 담고 일본어·중국어·한국어·키릴 문자·그리스 문자·이모지를 위한 바이트가 없어서 그 글자들은 어떤 형태로도 살아남지 못합니다. 오류도 없고 뜻을 유지하는 대체도 없습니다. 손실 보고서의 숫자는 작성기가 쓰는 것과 같은 표에서 계산한 물음표 개수입니다.
인코딩을 바꿨는데 두 창이 왜 똑같이 보이나요?
창은 글자를 담고 있고 선택은 바이트에 관한 것이기 때문입니다. 텍스트는 텍스트이고, 각 글자가 1바이트인지 2바이트인지는 내려받기 시점에 파일을 쓰면서 정해집니다. 대기열의 줄은 각 파일을 어떤 인코딩으로 읽었는지 적고 쓸 인코딩이 다르면 두 번째 표시를 더하며, 저장한 파일의 인코딩은 편집기가 알려 줍니다.
납품할 자막 파일에는 어떤 인코딩을 골라야 하나요?
사양서가 따로 말하지 않는 한 UTF-8입니다. 보통은 사양서가 말해 줍니다. Windows-1252는 유럽 방송 납품에서 흔하고 서유럽 텍스트에만 안전하며, UTF-16LE는 Windows 전용 저작 도구가 요구할 수 있습니다. 파일이 이미 알맞은 인코딩이었다면 기본값이 그것을 유지하는데, 아무 문제도 없을 때 가장 안전한 답입니다.
UTF-16을 고르면 자막 파일이 두 배가 되나요?
네, 거의 그렇습니다. 모든 글자가 2바이트로 저장되므로 20 KB짜리 영어 자막 파일이 약 40 KB가 되고, 이후 범용 압축 단계가 그 차이의 상당 부분을 없앱니다. 앞의 표시가 2바이트를 더합니다. 크기는 UTF-16이 Windows에서 흔해진 성질, 곧 모든 글자의 폭이 같다는 것과 맞바꾸는 값입니다. 옛 소프트웨어가 다루기 쉽다고 여긴 성질입니다.
인코딩 목록에 왜 UTF-16 빅 엔디언이 없나요?
아무도 고르지 않고, 이미 그런 파일은 어차피 처리되기 때문입니다. UTF-16 빅 엔디언으로 들어온 파일은 기본 설정에서 UTF-16 빅 엔디언으로 다시 쓰입니다. 인코딩을 지정하지 않으면 입력 인코딩을 유지하는 것이 이 페이지의 동작이기 때문입니다. 목록은 사람들이 실제로 요청하는 네 대상만 담고, 바탕의 작성기는 빅 엔디언도 다루어서 파일을 그대로 두는 일이 조용히 파일을 바꾸지 않게 합니다.