視訊與字幕·字幕工具包
為什麼字幕中的 é 變成 é：文字編碼以及瀏覽器如何解碼它們
· 工作原理
字幕 字元編碼 瀏覽器處理
字幕中的 Mojibake 幾乎總是編碼不符。這篇文章解釋了位元組如何變成字符，為什麼 UTF-8 和舊版 Windows 代碼頁不一致，以及基於瀏覽器的工具如何解碼檔案而不將其發送到任何地方。
口音很垃圾，但時機很完美──編碼問題是如何出現的
告訴我們，除了角色之外，一切都很好。計時準確，提示順序正確，檔案加載，只有重音字母是錯誤的。這種組合排除了結構錯誤，因為無法讀取檔案的解析器將無法產生正確的計時。錯誤發生在解析之前，當時將位元組序列轉換為字元序列。
這也解釋了為什麼故障經常出現在工作流程的中途而不是源頭。在一個編輯器中看起來正確的檔案在下一個編輯器中可能看起來是錯誤的，中間沒有任何修改。沒有任何東西改變它；第二個程式對位元組的含義做出了不同的假設。
位元組與字元 — 為什麼相同的位元組可以讀為 'é' 或 'é'，這取決於解碼器
磁碟上的檔案以位元組為單位。字元僅在應用編碼後才存在，編碼是將位元組序列對應到字元的表。 UTF-8 表示帶有重音的拉丁字母，例如兩個位元組的 e-acute。 Windows-1252 將相同的字母表示為單一位元組，並賦予兩個 UTF-8 位元組完全不同的意思：第一個是帶有波形符號的大寫 A，第二個是版權符號。
所以我們熟悉的亂碼對並不是腐敗。這是對錯誤表下正確位元組的忠實、無損讀取。每個位元組都倖存下來；只是解釋改變了。這就是為什麼損壞通常是可逆的，以及為什麼值得確定不匹配的方向而不是手動編輯可見字元。
UTF-8，Windows-1252 和朋友 - 編碼字幕檔案實際上出現在
字幕檔以少量編碼出現。 UTF-8 是現代預設值，也是 WebVTT 允許的唯一一個。 Windows-1252 在較舊的西歐工具產生的檔案中很常見，其密切相關的 ISO-8859-1 涵蓋了大部分相同的內容。來自中歐、西里爾或希臘來源的檔案出現在相應的 Windows 代碼頁中，東亞資料也添加了更多。
這些編碼都沒有在檔案中記錄自己的身分。 SRT 檔案不包含用於寫入它的編碼的宣告，這是整個問題的根源：讀者必須決定，並沒有任何權威可以閱讀。
位元組順序標記－對於某些玩家來說是一個有用的提示，而對於其他玩家來說則是一個明顯的故障
位元組順序標記是一個部分異常。它是檔案開頭的一個特定字符，如果存在，則表示編碼。它對某些玩家有幫助，而在其他玩家中則在第一個字幕索引之前顯示為流浪角色，這就是為什麼帶有一個字幕的檔案可能在一個程式中失敗而在其他任何地方都可以工作。
解析器在執行其他操作之前將其剝離，因為留在原處的標記會將其自身附加到第一個索引號並花費第一個提示。格式檢測的編寫也是為了容忍這種情況，因此在標頭之前以標記開頭的 WebVTT 檔案仍會被識別為 WebVTT，而不是被視為 SRT。
瀏覽器如何在本地解碼檔案 - TextDecoder API，以及為什麼在未宣告編碼時檢測是猜測
當工具載入檔案時，它會呼叫檔案 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 以進行 Web 交付的實際原因之一。
轉換在瀏覽器標籤中的檔案上執行。檢查您可以預測重音的行的結果，而不是掃描任何看起來錯誤的內容，因為在九百個提示中包含少量重音單字的檔案很容易簽署，而無需檢查可能失敗的部分。