비디오 및 자막 · 자막 툴킷
브라우저가 SRT 파일을 구문 분석하는 방법: 블록, 인덱스, 타임코드 및 텍스트
· 작동 방식
자막 srt 파일 형식
SRT은 실제 파일을 만나기 전까지는 사소해 보입니다. 이 게시물에서는 파서가 블록을 분할하고, 인덱스와 타임코드를 읽고, 여러 줄의 텍스트를 처리하고, 실제 파일에 포함된 잘못된 형식의 블록을 복구하는 방법을 안내합니다.
파일은 '괜찮아 보이지만' 단서의 절반이 누락되었습니다. 관대해 보이는 형식이 엄격한 기대를 숨기는 방법
SRT에는 사양 본문, MIME 등록 및 플레이어와 함께 제공되는 유효성 검사기가 없습니다. 대신에 존재하는 것은 대부분의 소프트웨어가 동의하는 모양(숫자, 타임코드 줄, 하나 이상의 텍스트 줄, 빈 줄)입니다. 모양이 지정되지 않고 기존 방식이기 때문에 두 파일 중 하나만 로드되는 동안 두 파일이 모두 텍스트 편집기에서 올바르게 보일 수 있으며 오류는 일반적으로 조용합니다. 큐를 읽을 수 없는 플레이어는 신고하기보다는 건너뛰는 경향이 있기 때문에 블록이 깨진 파일은 오류가 아닌 공백으로 재생됩니다.
따라서 파서에는 반대 방향으로 당기는 두 가지 작업이 있습니다. 파일은 각각 서로 다른 가정을 하는 전사 서비스, 수동 편집 및 형식 변환기에 의해 생성되므로 실제 파일에 포함된 변형을 수용해야 합니다. 또한 조용히 잘못된 타임스탬프가 보고된 실패보다 더 나쁘기 때문에 잘못된 시간에 신호를 보내는 판독을 거부해야 합니다.
블록으로 분할 — 구분 기호로서의 빈 줄과 흩어진 공백 및 CRLF 문제
분할은 색인 번호가 아닌 빈 줄에서 발생합니다. 파서는 줄 끝을 먼저 정규화하여 CRLF 쌍과 단독 CR을 모두 단일 줄 바꿈으로 바꿉니다. Windows에서 작성되고 Unix에서 편집된 파일에는 두 가지가 모두 포함될 수 있기 때문입니다. 그런 다음 두 개 이상의 줄 바꿈 실행으로 분할하고 각 결과 블록을 자르고 빈 블록을 삭제합니다. 순서가 중요합니다. 정규화하기 전에 분할하면 타임코드 줄 끝에 잘못된 캐리지 리턴이 남게 되고 그러면 타임코드가 일치하지 않게 됩니다.
이 항목 이전에 바이트 순서 표시가 제거됩니다. 파일 시작 부분의 UTF-8 BOM은 순진한 파서가 첫 번째 인덱스 번호의 일부로 보는 3바이트입니다. 이는 이후의 모든 큐를 파싱하는 동안 첫 번째 큐를 읽을 수 없게 만드는 데 충분합니다. 비어 있는 구분선의 후행 공백은 다듬기에 의해 처리되므로 빈 줄에 공백이 포함된 파일은 여전히 올바르게 분할됩니다.
인덱스 라인 — 숫자가 자주 틀리거나 중복되거나 누락되는 이유와 파서가 숫자를 신뢰해서는 안되는 이유
색인 번호를 읽은 다음 무시합니다. 실제 파일 번호는 0부터 시작하고, 병합 후 번호 매기기를 다시 시작하고, 수동 편집 후 번호를 복제하거나, 변환기가 파일을 작성할 때 줄을 완전히 생략합니다. 해당 숫자를 신뢰한다는 것은 해당 결함을 모두 상속한다는 의미이므로 파서는 대신 자체 순차 번호를 할당하여 지금까지 성공적으로 구축한 단서를 계산합니다.
이 선택은 또한 파서가 인덱스 행이 존재할 것을 요구하지 않는 이유를 설명합니다. 타임코드가 두 번째 라인이라고 가정하는 대신 블록에서 화살표가 포함된 첫 번째 라인을 검색하여 타임코드 라인을 찾습니다. 인덱스 라인이 없는 블록은 정상적으로 구문 분석되고, 타임코드 앞에 두 개의 잘못된 라인이 있는 블록은 여전히 구문 분석됩니다. 왜냐하면 위치가 타임코드를 식별하는 것이 아니기 때문입니다.
타임코드 줄 — HH:MM:SS,mmm --> HH:MM:SS,mmm, 허용되는 변형과 플레이어를 방해하는 변형
타임코드 라인은 단일 정규 표현식과 일치하며, 그 허용 오차는 의도적인 것입니다. WebVTT는 2필드 읽기를 허용하고 변환기는 이를 내보내므로 시간은 선택 사항입니다. 쉼표나 마침표는 파일이 주장하는 형식에 관계없이 밀리초 구분 기호로 허용됩니다. 혼합 구분 기호는 이를 거부하는 것이 잘못된 파일보다 좋은 파일에 더 많이 실패할 만큼 충분히 일반적이기 때문입니다. 분수 숫자는 오른쪽에 채워져 있으므로 한 숫자로 끝나는 큐는 단위가 아닌 수백 밀리초로 읽혀집니다.
두 번의 판독이 거부됩니다. 59초를 초과하는 분 또는 초 필드는 전달되기보다는 거부됩니다. 90초는 시계 판독값이 아니며 일반적으로 파일이 손상되었거나 잘못 변환되었음을 나타내기 때문입니다. 그것을 자동으로 정규화하면 큐가 움직일 것입니다. 시작 또는 끝이 구문 분석에 실패한 줄은 문제가 되는 텍스트와 예상 모양의 이름을 지정하는 기록된 문제를 생성하며 블록은 추측되는 대신 건너뜁니다.
텍스트 줄 — 여러 줄의 단서, 서식 지정 태그 및 블록이 실제로 끝나는 위치
타임코드 줄 뒤의 모든 내용은 줄 바꿈으로 다시 결합된 큐 텍스트입니다. 라인 제한도 없고 리플로우 시도도 없으므로 3라인 큐는 3라인으로 유지됩니다. 이것이 빈 줄이 로드 베어링인 이유입니다: 파서에게 텍스트가 끝났음을 알려주는 유일한 것입니다. 이것이 바로 자신의 텍스트에 빈 줄이 포함된 큐가 두 개의 블록으로 읽혀지고 두 번째 절반은 타임코드가 없는 것으로 보고되는 이유입니다.
큐 설정은 두 개 이상의 공백으로 인해 종료 타임스탬프와 구분됩니다. WebVTT를 사용하면 정렬 및 줄 배치와 같은 위치 지정 지시문이 동일한 줄의 종료 시간을 따르도록 허용하므로 파서는 타임스탬프가 구문 분석되기 전에 이를 분리하여 큐와 함께 유지합니다. 단일 공백은 단순히 어수선한 타임코드 줄이 종료 시간을 잃지 않도록 하는 구분 기호가 아닙니다.
실행된 예: 두 개의 의도적인 오류가 있는 5개의 큐 파일을 구문 분석합니다. — 강력한 파서가 복구하는 항목과 플래그를 지정하는 항목
00:01:75,000 --> 00:01:78,000를 읽으려면 블록 3의 타임코드 라인이 손상된 5블록 파일을 가져오세요. 블록 4는 복사 및 붙여넣기 중에 타임코드 라인이 완전히 손실되었습니다. 파서는 블록 1과 2를 정상적으로 읽고 1과 2의 번호를 매깁니다. 블록 3은 타임코드의 모양과 일치하지만 75라는 초 필드를 전달하므로 거부되고 읽을 수 없는 라인의 이름을 지정하는 잘못된 타임스탬프로 기록됩니다.
블록 4에는 화살표가 전혀 포함되어 있지 않으므로 타임스탬프가 없는 것으로 기록되며 원본 파일에서 해당 줄을 찾을 수 있도록 블록의 처음 40자를 인용합니다. 블록 5는 구문 분석되어 큐 5가 아닌 큐 3이 됩니다. 번호 매기기는 성공적인 큐를 계산하기 때문입니다. 그 결과 첫 번째 결함에 대한 예외가 발생하고 두 번째 결함에 대한 정보가 없는 것이 아니라 세 가지 사용 가능한 단서와 두 개의 특정 위치에 있는 불만 사항이 생성됩니다.
여기서 다루지 않는 내용 — ASS/SSA 스타일, 위치 코드 및 SRT에 덤프된 비자막 텍스트
이는 SRT 및 큐 모양을 공유하는 WebVTT 부분을 설명합니다. 스크립트 헤더, 스타일 정의 및 이벤트별 스타일 참조를 전달하고 빈 줄로 분할하여 읽을 수 없는 ASS 및 SSA는 다루지 않습니다. 가라오케 타이밍, 그리기 명령 및 이러한 형식이 사용하는 인라인 오버라이드 태그는 큐 및 타임코드 파서가 모델링하는 것 외부에 있습니다.
또한 텍스트를 복구하지 않습니다. 타임코드 없이 파일에 붙여넣은 기록은 타임스탬프가 없는 블록 목록을 생성하며, 이는 정확하게 보고되지만 존재하지 않는 타이밍 정보 없이 자막으로 전환될 수 없습니다. 인코딩 오류는 별도의 문제입니다. 잘못된 문자 세트로 디코딩된 파일은 텍스트가 잘못된 완벽하게 유효한 단서로 구문 분석되며 구조적 검사를 아무리 많이 해도 이를 감지할 수 없습니다.
요점: 관대하게 구문 분석하고 엄격하게 작성합니다. 자막 도구 키트가 지저분한 SRT을 읽고 깨끗한 것을 다시 작성하는 방법
작업 규칙은 관대하게 구문 분석하고 엄격하게 작성하는 것입니다. 도중에 선택적 시간, 구분 기호, 누락된 인덱스 줄, 혼합 줄 끝 및 선행 바이트 순서 표시를 허용하고 첫 번째 오류를 발생시키는 대신 모든 오류를 발견된 문제로 기록하여 파일을 단일 패스로 수정할 수 있습니다. 나가는 길에 하나의 표준 형태를 방출합니다.
이것이 바로 자막 툴킷이 변환할 때 수행하는 작업입니다. 큐는 1부터 번호가 다시 매겨져 연속적으로 유지되고, 타임스탬프는 SRT의 경우 쉼표, WebVTT의 경우 마침표와 함께 다시 내보내지며, 돌아오는 파일은 입력이 얼마나 불규칙했는지에 관계없이 플레이어가 기대하는 모양입니다. 플레이어가 거부한 파일을 변환기에 붙여넣고 보고된 문제를 먼저 읽어보세요. 그들은 단서에 이름을 붙이고 대사를 인용하는데, 이는 일반적으로 원본에서 결함을 찾는 데 충분합니다.