視訊與字幕·字幕工具包
為什麼字幕檔中的雜散標籤會破壞平台字幕上傳
· 為什麼它很重要
字幕 文字處理 webvtt
平台會嚴格解析上傳的字幕，而且通常會默默地進行解析。這篇文章解釋了字幕檔案被拒絕或顯示奇怪的常見原因，為什麼格式化標籤和程式碼是常見的罪魁禍首，以及乾淨、標準的檔案如何避免該問題。
上傳已被接受，標題顯示文字標籤 — 不乾淨檔案的安靜失敗
最糟糕的結果不是拒绝。當您仍在查看表單時，上傳被拒絕表示出現了問題。常見的結果是接受，然後是向觀眾顯示自己的標記的字幕，因為上傳檢查和渲染路徑是不同的軟體，會提出不同的問題。
上傳檢查通常會詢問檔案是否解析為提示。渲染詢問如何處理每個提示的內容，解析器會忽略不熟悉的標籤，並將其繪製為文字。這兩個步驟都完成了它們的設計目的。
實際接受的平台 - 普通 SRT 和具有可預測結構的 WebVTT，對額外內容的容忍度很小
平台接受的範圍比工具發出的範圍窄。實際上，這意味著具有可預測形狀的普通 SRT 或 WebVTT：由空白行、時間碼行、文字行和其他內容分隔的區塊。對額外功能的容忍度很低，更重要的是，沒有記錄，因此安全的假設是，任何超出該形狀的東西都是風險而不是功能。
這本身並不是保守主義。接受任意標記的平台必須決定如何在網路、行動和電視用戶端一致地呈現它，這比接受字幕檔案的承諾要大得多。
通常的罪魁禍首－類似 HTML 的標籤、ASS 樣式的程式碼、BOM、混合行結尾和空白提示
重複出現的罪魁禍首很少。斜體、說話者聲音和提示類別的尖括號標籤可以在支援它們的格式轉換後保留下來。大括號分隔的覆蓋代碼來自 SubStation 格式，除了它們之外沒有任何意義。檔案開頭的位元組順序標記將其附加到第一個索引號。跨平台編輯中的混合行結尾會破壞區塊分割。刪除標記後文字變空的提示仍保留為帶有時間戳記的空白。
這些都不是異國情調。它們是轉換鏈的正常輸出，其中每個步驟都是單獨合理的，這就是為什麼它們出現在編輯器中看起來不錯的檔案中。
為什麼一個平台可以容忍另一個平台所拒絕的內容 - 類似上傳表單背後的不同解析器
不同的平台容忍不同的子集，這就是導致故障難以診斷的原因。同一個檔案可以在一個服務上乾淨地上傳並正確呈現，在第二個服務上傳並呈現標記，並被第三個服務拒絕，並沒有指出實際原因的錯誤訊息。檔案在兩次嘗試之間沒有改變；三個解析器不同意。
因此，將一個平台視為參考是錯誤的本能。在最寬鬆的服務上工作的檔案不會告訴您任何有關其他服務的信息，而最嚴格的解析器是定義檔案是否可移植的解析器。
工作範例：一個檔案，三個上傳 - 相同的雜亂如何以不同的方式顯示並在清理後消失
採取一個匯出，在 60 個提示上攜帶幀頂部覆蓋代碼，在 40 個提示上攜帶強調標記，以及字節順序標記。上傳到三個服務後，它可能會被所有地方接受。第一個標籤受到尊重，並覆蓋代碼按字面意思繪製。在第二個上，兩者都顯示為文字。在第三個標記上，第一個提示會消失，而第一個提示根本不會出現，也沒有人注意到，因為開場白通常是標題。
清理一次即可從來源刪除所有三個類別。尖括號標籤和大括號代碼被替換，留下的空白被折疊，刪除所清空的線索被丟棄而不是作為帶時間戳的空白發出，並檔案被重寫，線索從一開始連續重新編號。然後相同的輸出發送到所有三個服務。
這不包括什麼 - 特定於平台的樣式指南、每行字元限制和內建字幕
這涵蓋結構可移植性，而不是編輯一致性。關於行長度、最大字元數、揚聲器標籤的定位和聲音效果處理的平台風格指南是獨立的要求，乾淨的檔案無法自動滿足。結構完美的字幕檔案仍然可能違反風格指南。
內建字幕是完全不同的機制。渲染到視訊畫面中的文字不是字幕檔案，無法關閉，並不受此處描述的任何內容的影響。
重點：一次清理，隨處上傳 — Subtitle Toolkit 的清理和轉換功能如何產生平台友好的檔案
清理一次並在各處上傳相同的檔案。另一種方法是為每個平台維護單獨的匯出，這會增加可能與主伺服器不同步的檔案數量，並不會消除其中任何一個的潛在混亂。
一起執行清理和轉換，然後在上傳之前而不是之後閱讀報告的問題。問題名稱透過數字提示，這是知道檔案有問題和知道要查看哪一行之間的區別。