비디오 및 자막 · 자막 툴킷
자막에서 é가 é가 되는 이유: 텍스트 인코딩 및 브라우저가 이를 디코딩하는 방법
· 작동 방식
자막 문자 인코딩 브라우저 처리 중
자막의 Mojibake는 거의 항상 인코딩 불일치입니다. 이 게시물에서는 바이트가 문자가 되는 방법, UTF-8 및 레거시 Windows 코드 페이지가 일치하지 않는 이유, 브라우저 기반 도구가 파일을 어디로도 보내지 않고 디코딩하는 방법에 대해 설명합니다.
악센트는 쓰레기지만 타이밍은 완벽합니다. 인코딩 문제가 어떻게 나타나는지
문자를 제외한 모든 것이 괜찮다는 것입니다. 타이밍은 정확하고 큐 순서는 올바르며 파일은 로드되고 악센트가 있는 문자만 잘못되었습니다. 이 조합은 파일을 읽을 수 없는 파서가 정확한 타이밍을 생성하지 못했기 때문에 구조적 결함을 배제합니다. 바이트 시퀀스가 문자 시퀀스로 변환될 때 구문 분석 전에 문제가 발생했습니다.
이는 오류가 소스가 아닌 워크플로 중간에 나타나는 경우가 많은 이유이기도 합니다. 한 편집기에서는 올바르게 보였던 파일이 다음 편집기에서는 수정되지 않은 채 잘못된 것처럼 보일 수 있습니다. 아무것도 수정하지 않았습니다. 두 번째 프로그램은 바이트의 의미에 대해 다른 가정을 했습니다.
바이트 대 문자 — 디코더에 따라 동일한 바이트를 'é' 또는 'é'로 읽을 수 있는 이유
디스크의 파일은 바이트입니다. 문자는 바이트 시퀀스를 문자에 매핑하는 테이블인 인코딩을 적용한 후에만 존재합니다. UTF-8는 e-acute와 같은 악센트가 있는 라틴 문자를 2바이트로 나타냅니다. Windows-1252은 단일 바이트와 동일한 문자를 나타내며 두 개의 UTF-8 바이트에 완전히 다른 의미를 부여합니다. 첫 번째는 물결표가 포함된 대문자 A이고 두 번째는 저작권 기호입니다.
따라서 친숙한 왜곡된 쌍은 손상되지 않습니다. 이는 잘못된 테이블 아래의 올바른 바이트를 충실하고 손실 없이 읽는 것입니다. 모든 바이트는 살아 남았습니다. 해석만 바뀌었을 뿐입니다. 이것이 손상이 일반적으로 되돌릴 수 있는 이유이며, 눈에 보이는 문자를 직접 편집하는 것보다 불일치가 어느 방향으로 진행되었는지 식별하는 것이 가치 있는 이유입니다.
UTF-8, Windows-1252 및 친구들 — 인코딩 자막 파일은 실제로
자막 파일은 소수의 인코딩으로 나타납니다. UTF-8는 최신 기본값이며 WebVTT가 허용하는 유일한 것입니다. Windows-1252은 이전 서유럽 도구로 생성된 파일에서 일반적이며 가까운 친척 ISO-8859-1은 동일한 기반을 많이 다룹니다. 중앙 유럽어, 키릴 문자 또는 그리스어 소스의 파일이 해당 Windows 코드 페이지에 나타나고 동아시아 자료가 몇 가지 더 추가됩니다.
이러한 인코딩 중 어느 것도 파일 내에 자체 ID를 기록하지 않습니다. SRT 파일에는 파일을 작성하는 데 사용된 인코딩 선언이 포함되어 있지 않습니다. 이것이 전체 문제의 근본 원인입니다. 독자가 결정해야 하며 읽을 권한이 없습니다.
바이트 순서 표시 — 일부 플레이어에게는 유용한 힌트이고 다른 플레이어에서는 눈에 띄는 결함입니다.
바이트 순서 표시는 부분적인 예외 중 하나입니다. 파일의 시작 부분에 있는 특정 문자로, 존재하는 경우 인코딩을 나타냅니다. 이는 일부 플레이어에게 도움이 되고 다른 플레이어에서는 첫 번째 자막 색인 이전에 길 잃은 문자로 표시됩니다. 이것이 바로 이 자막을 포함하는 파일이 정확히 하나의 프로그램에서 실패하고 다른 모든 곳에서 작동할 수 있는 이유입니다.
파서는 다른 작업을 수행하기 전에 이를 제거합니다. 왜냐하면 제자리에 남겨진 표시는 첫 번째 색인 번호에 부착되고 첫 번째 큐 비용이 들기 때문입니다. 형식 감지도 이를 허용하도록 작성되었으므로 헤더 앞의 표시로 시작하는 WebVTT 파일은 SRT로 처리되지 않고 여전히 WebVTT로 인식됩니다.
브라우저가 로컬에서 파일을 디코딩하는 방법 — TextDecoder API 및 인코딩이 선언되지 않은 경우 감지가 추측인 이유
도구는 파일을 로드할 때 File API 텍스트 메서드를 호출하고 해당 메서드는 UTF-8로 디코딩되도록 지정됩니다. 인코딩 매개변수와 협상이 없습니다. 실제로 UTF-8인 파일은 올바르게 읽혀집니다. 단일 바이트 악센트 문자가 포함된 Windows-1252 파일은 유효한 UTF-8 시퀀스를 시작할 수 없는 바이트를 제공하며 디코더는 추측하는 대신 대체 문자를 대체합니다.
증상이 바뀌기 때문에 알아두면 좋습니다. 레거시 테이블이 포함된 UTF-8 파일을 읽으면 익숙한 두 글자로 된 잘못된 문자가 생성됩니다. UTF-8로 레거시 파일을 읽으면 대신 검은색 다이아몬드 또는 빈 상자와 같은 대체 문자가 생성됩니다. UTF-8 이외의 다른 것으로 디코딩하려면 브라우저 디코더 API를 통해 명시적으로 인코딩 이름을 지정해야 하며 이름을 지정하는 것은 어려운 부분입니다. 파일에 선언이 없으면 자동 선택은 바이트 패턴에서 추론되며, 이는 일반적으로 옳고 때로는 확실하게 틀린 추측입니다.
작업 예: Windows-1252 파일 복구 — 소스 인코딩을 식별하고 변환 전에 이를 UTF-8로 다시 저장
레거시 파일을 복구하려면 자막 작업 이후보다는 자막 작업 이전에 변환을 수행하세요. 양쪽의 인코딩을 명시할 수 있는 편집기에서 파일을 열고 Windows-1252로 파일을 다시 열도록 지시한 다음 악센트 문자가 올바르게 표시되는지 확인하세요. 그렇다면 추측이 맞았습니다. 그런 다음 파일을 명시적으로 UTF-8로 저장합니다.
파일 전체보다는 예측할 수 있는 줄에서 검증하세요. 거기에 있어야 할 악센트가 포함된 큐를 선택하고 변환된 출력에서 확인하세요. 이 작업을 먼저 수행한다는 것은 자막 도구가 가정할 인코딩과 이미 일치하는 바이트가 있는 파일을 수신하고 변환 단계에서 더 이상 잘못될 것이 없음을 의미합니다.
여기에 포함되지 않는 내용 — 두 번의 잘못된 변환으로 인해 파일이 손상되어 원래 바이트가 이미 손실되었습니다.
두 번의 잘못된 변환을 거친 파일은 다른 문제입니다. 파일을 잘못 읽은 다음 잘못 읽은 상태로 저장하면 잘못된 문자가 실제 문자로 기록되고 원래 바이트는 더 이상 존재하지 않습니다. 그 시점에서는 이제 파일에 왜곡된 텍스트가 실제로 포함되어 있으므로 재해석할 것이 없습니다.
이러한 경우는 잘못된 인코딩의 정확한 순서를 반대로 하여 복구할 수 있는 경우도 있지만 모든 단계가 알려져 있고 정보 손실 단계가 없는 경우에만 가능합니다. 대체 문자가 된 바이트는 영구적으로 사라집니다. 대체 문자는 디코더가 사용할 수 없는 바이트를 대신하는 단일 문자이며 바이트가 무엇인지 기록하지 않습니다. 안정적인 해결 방법은 원본 파일로 돌아가는 것입니다.
요약: 변환하기 전에 UTF-8로 표준화하세요. 자막 도구 키트가 브라우저의 파일에서 작동하는 방식과 정의상 WebVTT 출력이 UTF-8인 이유
무엇이든 변환하기 전에 UTF-8를 표준화하세요. 파일 자체에는 인코딩에 대한 설명이 없으므로 파일을 여는 모든 프로그램은 가정을 하고 있으며, 가정이 불일치하는 것을 막는 방법은 모두 올바르게 만드는 것입니다. WebVTT는 형식에 UTF-8이 필요하기 때문에 정의에 따라 모호성을 제거합니다. 이는 웹 전달을 위해 SRT를 WebVTT로 변환하는 실질적인 이유 중 하나입니다.
변환은 브라우저 탭의 파일에서 실행됩니다. 잘못된 부분을 스캔하는 대신 예측할 수 있는 악센트가 있는 줄에서 결과를 확인하세요. 900개의 단서에 악센트가 있는 단어가 몇 개 포함된 파일은 실패할 부분을 검사하지 않고도 쉽게 승인할 수 있기 때문입니다.