ビデオと字幕 · 字幕ツールキット
字幕で é が é になる理由: テキスト エンコーディングとブラウザがそれをデコードする方法
· 仕組み
字幕 文字エンコーディング ブラウザ処理
字幕の文字化けは、ほとんどの場合、エンコードの不一致です。この投稿では、バイトがどのように文字になるのか、UTF-8 と従来の Windows コード ページが一致しない理由、およびファイルをどこにも送信せずにブラウザベースのツールがどのようにデコードするのかについて説明します。
アクセントはゴミですが、タイミングは完璧です - エンコードの問題がどのように現れるか
つまり、文字以外はすべて問題ないということです。タイミングは正確で、キューの順序は正しく、ファイルはロードされますが、間違っているのはアクセント付きの文字だけです。ファイルを読み取れないパーサーは正しいタイミングを生成しないため、この組み合わせでは構造上の欠陥が排除されます。問題は解析前に発生し、バイト列が文字列に変換されました。
これは、障害がソースではなくワークフローの途中で発生することが多い理由も説明しています。あるエディタでは正しく見えたファイルが、間に何も変更されていない次のエディタでは間違っているように見えることがあります。何も変更しませんでした。 2 番目のプログラムは、バイトの意味について異なる仮定を立てました。
バイトと文字 — デコーダーによって同じバイトが「é」または「é」として読み取られる理由
ディスク上のファイルはバイトです。文字は、バイト シーケンスを文字にマッピングするテーブルであるエンコーディングを適用した場合にのみ存在します。 UTF-8 は、e-acute などのアクセント付きラテン文字を 2 バイトで表します。 Windows-1252 は、同じ文字を 1 バイトとして表し、2 つの UTF-8 バイトにまったく異なる意味を与えます。1 つ目はチルダ付きの大文字 A、2 つ目は著作権記号です。
つまり、よく知られている文字化けペアは破損ではありません。これは、間違ったテーブルの下にある正しいバイトを忠実かつロスなく読み取ることです。すべてのバイトが生き残りました。解釈が変わっただけです。これが、損傷が通常は回復可能である理由であり、表示されている文字を手動で編集するのではなく、不一致がどの方向に進んだのかを特定する価値がある理由です。
UTF-8、Windows-1252 とその仲間 — エンコーディングの字幕ファイルは実際に表示されます。
字幕ファイルは少数のエンコーディングで表示されます。 UTF-8 は最新のデフォルトであり、WebVTT で許可される唯一のものです。 Windows-1252 は、古い西ヨーロッパのツールで作成されたファイルで一般的であり、それに近い ISO-8859-1 もほぼ同じ内容をカバーします。中央ヨーロッパ、キリル文字、またはギリシャ語のソースからのファイルは、対応する Windows コード ページに表示され、東アジアの素材によってさらにいくつかのファイルが追加されます。
これらのエンコーディングはいずれも、ファイル内に独自の ID を記録しません。 SRT ファイルには、その書き込みに使用されるエンコーディングの宣言が含まれていません。これが問題全体の根本です。読み取り者が決定する必要があり、読み取る権限のあるものは何もありません。
バイトオーダーマーク — 一部のプレーヤーにとっては役立つヒントであり、他のプレーヤーにとっては目に見える不具合です
バイト オーダー マークは 1 つの部分的な例外です。これは、ファイルの先頭にある特定の文字で、存在するとエンコーディングを示します。これは一部のプレイヤーに役立ちますが、他のプレイヤーでは最初の字幕インデックスの前に野良文字として表示されます。そのため、これを含むファイルは 1 つのプログラムでのみ失敗し、他の場所では機能する可能性があります。
パーサーは、他の作業を行う前にそれを削除します。これは、所定の位置に残されたマークが最初のインデックス番号に付加され、最初のキューが消費されるためです。フォーマット検出もこれを許容するように記述されているため、ヘッダーの前にマークで始まる WebVTT ファイルは、SRT として扱われるのではなく、依然として WebVTT として認識されます。
ブラウザーがローカルでファイルをデコードする方法 — TextDecoder API、およびエンコードが宣言されていない場合に検出が推測になる理由
ツールはファイルをロードするときに File API テキスト メソッドを呼び出し、そのメソッドは UTF-8 としてデコードされるように指定されます。エンコードパラメータやネゴシエーションはありません。実際には UTF-8 であるファイルは正しく読み取られます。シングルバイトのアクセント付き文字を含む Windows-1252 ファイルには、有効な UTF-8 シーケンスを開始できないバイトが存在し、デコーダーは推測ではなく置換文字を置き換えます。
これは症状を変えるため、知っておく価値があります。従来のテーブルを使用して UTF-8 ファイルを読み取ると、よく知られた 2 文字の文字化けが発生します。従来のファイルを UTF-8 として読み取ると、代わりに黒いひし形または空のボックスなどの置換文字が生成されます。 UTF-8 以外のものとしてデコードするには、ブラウザ デコーダ API を介して明示的にエンコードに名前を付ける必要がありますが、名前を付けるのは難しい部分です。ファイル内に宣言がない場合、自動選択はバイト パターンからの推論になります。これは、通常は正しく、場合によっては確実に間違っている推測です。
有効な例: Windows-1252 ファイルをレスキューする — ソース エンコーディングを特定し、変換前に UTF-8 として再保存する
レガシー ファイルを救出するには、字幕作業の後ではなく、前に変換を実行します。エディターでファイルを開き、両側のエンコーディングを指定し、ファイルを Windows-1252 として再度開くように指示し、アクセント付き文字が正しく表示されることを確認します。もしそうであれば、その推測は正しかったということになります。次に、ファイルを明示的に UTF-8 として保存します。
ファイル全体ではなく、予測できる行で検証してください。そこにあるはずのアクセントを含むキューを選択し、変換された出力でそれを確認します。これを最初に行うということは、字幕ツールが想定するエンコーディングとバイトがすでに一致しているファイルを受信し、変換ステップで何も間違うことがないことを意味します。
これでカバーされないもの — 2 回の間違った変換によって破損し、元のバイトがすでに失われているファイル
2 回間違った変換が行われたファイルは別の問題です。ファイルが誤って読み取られ、その誤った状態で保存された場合、誤った文字は実際の文字として書き出され、元のバイトはファイルのどこにも存在しなくなります。この時点では、ファイルには文字化けしたテキストが実際に含まれているため、再解釈する必要はありません。
これらのケースは、間違ったエンコードの正確な順序を逆にすることで回復できる場合がありますが、これはすべてのステップがわかっていて、情報が失われたステップがない場合に限られます。置換文字となったバイトは永久に失われます。置換文字は、デコーダが使用できなかったバイトの代わりとなる単一の文字であり、そのバイトが何であったかは記録されません。確実な修正方法は、元のファイルに戻すことです。
要点: 変換する前に UTF-8 を標準化する — ブラウザー内のファイルに対して字幕ツールキットがどのように機能するか、および WebVTT 出力が定義上 UTF-8 である理由
何かを変換する前に、UTF-8 に基づいて標準化してください。ファイル自体にはそのエンコーディングに関するステートメントが含まれていないため、ファイルを開くすべてのプログラムは仮定を立てていることになります。仮定の不一致を止める方法は、それらをすべて正しくすることです。 WebVTT では、この形式では UTF-8 が必要であるため、定義により曖昧さが解消されます。これが、Web 配信用に SRT を WebVTT に変換する実際的な理由の 1 つです。
変換はブラウザー タブのファイルに対して実行されます。 900 個のキューにアクセント付きの単語がいくつか含まれているファイルは、失敗する部分を調べなくても承認するのが簡単であるため、間違っていると思われるものをスキャンするのではなく、アクセントが予測できる行の結果をチェックしてください。