자막 줄 바꿈 문자 변환
또는 자막 텍스트를 붙여넣으세요
옵션
파일의 모든 줄은 보이지 않는 글자 하나(LF)나 둘(CRLF)로 끝납니다. 플레이어, 편집기, 자막 도구 모두 둘 다 읽으므로 자막 파일이 말썽을 부리는 이유가 이것인 경우는 거의 없습니다. 예외는 두 가지입니다. 다른 쪽을 거부하는 빌드 파이프라이나 엄격한 파서, 그리고 줄 끝이 달라서 모든 줄이 바뀐 것으로 보이는 diff 도구입니다. 여기서 기본값이 LF인 이유는 Unix, macOS, 웹이 쓰는 방식이고, 이미 LF인 파일은 건드리지 않기 때문입니다. CRLF를 고르면 기존의 두 가지 줄 끝이 모두 변환되므로 섞여 있던 파일도 일관되게 나옵니다.
타이밍을 어떤 프레임 레이트 기준으로 세는지 정합니다. 형식 안내 페이지에서는 MicroDVD가 이 값을 필요로 합니다. 시간을 프레임 번호로 저장하기 때문입니다. 프레임 레이트 페이지에서는 이 파일이 어느 프레임 레이트를 기준으로 만들어졌는지, 즉 자막을 만든 판본의 값을 뜻하며, 페이지의 두 번째 상자에는 이 자막을 사용할 영상의 프레임 레이트를 넣습니다. 흔히 쓰는 값은 23.976, 24, 25, 29.97, 30, 50, 59.94, 60입니다. 잘못 넣으면 시간축 전체가 어긋나고, 프레임 레이트 페이지에서는 고정된 양이 아니라 비율로 어긋납니다.
이 페이지는 자막 파일의 줄 바꿈 문자를 LF와 CRLF 사이에서 바꿉니다. LF는 Unix와 웹이 쓰는 한 바이트 0A이고, CRLF는 Windows가 쓰는 0D 0A 두 바이트입니다. 선택은 기본값이 LF이고, 큐의 텍스트도 타임코드도 건드리지 않습니다. 달라지는 것은 각 줄 끝의 한두 바이트뿐입니다.
섞인 파일은 먼저 LF로 정규화한 뒤 고른 방식으로 변환합니다. 어떤 줄은 CRLF로, 어떤 줄은 LF로 끝나는 파일이 완전히 균일하게 나오는 이유입니다. 두 대의 기계에서 편집하면 파일이 그런 상태가 되고, 그 혼합이 바로 다른 사본과의 비교를 읽을 수 없게 만드는 원인입니다. 단순한 찾기 바꾸기는 이 경우를 양방향으로 틀립니다. 한쪽으로는 LF 줄을 그대로 두고, 다른 쪽으로는 캐리지 리턴을 두 개 만듭니다.
빈 줄도 줄입니다. 큐 사이를 가르는 그 빈 줄의 끝도 줄 바꿈이라서 함께 바뀝니다. SRT에서 큐를 나누는 빈 줄의 끝만 LF로 남으면 균일한 파일 한가운데에 다른 종류의 줄 바꿈 하나가 남는데, 그것이 이 페이지가 없애려는 혼합 그 자체입니다. 파일의 마지막 줄도 마찬가지입니다.
옛 Mac이 쓰던 캐리지 리턴 하나짜리 줄 바꿈도 함께 정규화됩니다. 패널에 CR 선택지가 없는 것은 지금 그렇게 쓰는 사람이 없기 때문이고, 이미 그런 파일은 올바르게 읽혀 고른 방식으로 다시 쓰입니다. 업로드는 없고, 읽기와 쓰기 모두 실제 바이트에서 일어납니다.
예시
Unix 파일을 Windows 줄 바꿈으로
입력
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.
큐 사이의 빈 줄까지 모든 줄 끝이 두 글자가 됩니다. 그 빈 줄도 줄 끝이 있고, 그것을 건너뛰는 변환은 큐 구분자가 아직 LF 하나인 파일을 남깁니다. 결과 텍스트는 줄 끝을 CR LF 짝으로 적어 두어 개수를 그대로 읽을 수 있고, 파일의 다른 것은 아무것도 움직이지 않았습니다.
Windows 파일을 다시 Unix 줄 바꿈으로
입력
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.
결과가 눈에 보이는 방향입니다. 캐리지 리턴이 남은 파일은 일부 편집기에서 모든 줄 뒤에 빈 줄이 있는 것처럼 보이고, 셸 파이프라인에서는 마지막 필드 끝에 캐리지 리턴이 붙은 것으로 보입니다. 영상과 타이밍과 텍스트는 두 파일에서 같습니다. 차이는 각 줄 끝의 한 글자이고, 이 방향이 그것을 없앱니다.
두 기계에서 편집한 파일을 균일하게
입력
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
결과물
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
두 기계에서 만진 같은 파일이라 어떤 줄은 CRLF로, 어떤 줄은 LF로 끝나고 큐 구분자도 양쪽으로 쓰였습니다. 출력은 균일하고 그것이 요점입니다. 파일이 어느 줄을 읽느냐에 따라 다른 뜻이 되지 않습니다. 순진한 찾기 바꾸기는 이 경우를 양방향으로 틀립니다. 한쪽으로는 LF 줄을 남기고, 다른 쪽으로는 캐리지 리턴을 두 개 만듭니다.
자주 묻는 질문
자막 파일이 어떤 줄 바꿈을 쓰는지 어떻게 알 수 있나요?
대부분의 편집기에서는 상태 표시줄에 LF, CRLF 또는 혼합으로 나옵니다. 셸에서는 제어 문자를 보이게 하는 도구로 열었을 때 CRLF 파일의 각 줄 끝에 캐리지 리턴이 보입니다. 직접 확인하려면 줄 끝의 바이트를 보세요. 0A 하나면 LF이고 0D 0A 짝이면 CRLF입니다.
줄 바꿈이 섞인 자막 파일은 어떻게 처리하나요?
전부 같게 만듭니다. 파일을 먼저 LF로 정규화한 뒤 고른 방식으로 변환하므로, 어떤 줄은 한쪽으로 어떤 줄은 다른 쪽으로 끝나던 파일이 부분적으로 변환된 상태가 아니라 완전히 균일하게 나옵니다. 두 대 이상의 기계에서 편집하면 파일이 그런 상태가 되고, 그 혼합이 다른 사본과의 비교를 읽을 수 없게 만드는 바로 그 원인입니다.
줄 바꿈이 자막 타이밍이나 큐 텍스트를 바꾸나요?
아니요. 큐와 번호와 시작·끝 시각과 그 안의 단어가 전후로 모두 같고, 달라지는 것은 각 줄 끝의 한두 글자입니다. 플레이어는 두 파일을 같은 방식으로 읽습니다. 그래서 납품 요구 사항 때문에 이 변환을 하면서 자막 내용은 걱정하지 않아도 됩니다.
자막 줄 바꿈을 LF로 할까요, CRLF로 할까요?
눈앞의 사양서가 CRLF를 말하지 않는 한 LF입니다. Unix 도구와 대부분의 빌드 파이프라인과 WebVTT 사양이 기대하는 쪽이고, 줄마다 1바이트씩 짧아집니다. 납품 사양서나 Windows 전용 도구가 요구하면 CRLF를 고르세요. 선택은 파일별이지 전역이 아니라는 점도 기억하세요. 따로 납품하는 자막 파일 하나가 프로젝트의 나머지와 달라도 됩니다.
CRLF로 바꾸면 자막 사이의 빈 줄도 왜 바뀌나요?
그 빈 줄도 줄이고 그 끝도 다른 줄 끝과 같은 줄 끝이기 때문입니다. SRT는 빈 줄로 큐를 나누므로, CRLF로 변환된 파일에서 큐 구분자만 LF로 남으면 균일한 파일 한가운데에 다른 종류의 줄 바꿈이 하나 생깁니다. 그것이 바로 이 페이지가 없애려는 혼합입니다. 파일의 마지막 줄에도 같은 규칙이 적용됩니다.
옛 Mac의 캐리지 리턴도 변환되나요?
네. 캐리지 리턴 하나로 줄이 끝나는, OS X 이전 Mac이 쓰던 방식의 파일도 나머지와 함께 정규화되어 한 덩어리 긴 큐로 남지 않고 고른 방식으로 나옵니다. 패널에 CR 선택지가 없는 것은 지금 그렇게 쓰는 사람이 없기 때문이고, 이미 그런 파일은 올바르게 읽혀 다시 쓰입니다.