字幕加上 BOM
或者貼上字幕文字
選項
BOM 是檔案最開頭的三個位元組，用來說明檔案是哪一種編碼。它在任何編輯器和播放器裡都看不見，不佔畫面空間，加不加它字幕內容都不會變。有兩類工具在意它：寫字幕的 Windows 程式，預設就會寫一個；以及建置流程裡嚴格的解析器，會拒絕帶有 BOM 的檔案。這一頁會按標題點名的狀態開啟這個欄位，所以發現檔案其實是另一種情況時，切換過來即可。UTF-16 檔案總是帶 BOM，因為讀取器靠它判斷自己看到的是兩種位元組順序中的哪一種 —— 在這種檔案上要求移除，它會保持原樣。
時間以哪個影格率計算。在格式頁面上，這是 MicroDVD 需要的值，因為它把時間存成影格編號。在影格率頁面上，它是檔案當初對應的速率 —— 字幕是照這個版本製作的 —— 而頁面的第二個欄位填你要搭配的影片速率。常見的有 23.976、24、25、29.97、30、50、59.94 和 60。填錯會讓整條時間軸位移；在影格率頁面上，位移是按比例發生，而不是固定的量。
BOM 是一個字元——U+FEFF，站在檔案最前面。在 UTF-8 裡它是三個位元組 EF BB BF，也是讀取程式最先看到的東西。這一頁的產物看起來什麼都沒變：同樣的字幕、同樣的時間碼、同樣的換行，只是最前面多了一個標記。
為什麼要加：這個標記是檔案在不說話的情況下宣告「我是 UTF-8」的方式。打開字幕檔的程式得猜它是什麼編碼，而相當多的程式——舊版 Windows 播放器、光碟製作工具、只讀第一行的腳本——靠看開頭幾個位元組判斷，而不是解析整份檔案。給它們標記，帶重音的名字、彎引號、希臘字母才能原樣顯示；不給，同一份檔案可能被按系統的本地代碼頁讀，那些字元就變成別的東西。
反方向才是多數人先遇到的：檔案有標記，而工具不預期它，於是把三個位元組讀成三個字元，印在第一行行首——別人字幕檔頂端那一小串符號就是這樣來的。如果你面對的是這種情形，你需要的是移除 BOM，而不是添加；做那件事的頁面在下面有連結。
這一頁不會順手重排檔案。CRLF 換行、字幕編號、時間、任何一行的文字都不動，也不替你決定檔案編碼——不是 UTF-8 的檔案是另一個問題，也另有其頁。它做的事只有一件：在最前面加一個字元；如果標記已經存在，它會讓檔案維持原樣，而不是再加第二個，所以跑兩遍與跑一遍得到同一份檔案。
標記加在你下載的那份檔案上。因此這一頁的上下兩欄可以用肉眼判斷為完全相同——看不見的字元就是看不見。誠實的確認方式是用十六進位檢視器看開頭三個位元組，或看編輯器狀態列顯示的編碼。本站處理的 12 種字幕格式都能攜帶標記，因為標記是檔案開頭位元組的屬性，跟字幕段落無關。任何時刻都不上傳：檔案在你的瀏覽器裡讀入、修改、寫出。
範例
一份純 ASCII 字幕檔，前面加上標記
輸入
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
輸出
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
預期文字以一個看不見的字元開頭：U+FEFF，三個位元組 EF BB BF，在第一條字幕編號的 1 之前。兩欄對你看起來會一樣，這不是顯示錯誤——兩份檔案只差三個位元組，而它們都沒有形狀。下載結果，用會顯示編碼的編輯器打開，或用十六進位檢視器看開頭，你第一眼就會看到它。
Windows 檔案，加上標記但保留回車
輸入
1
00:00:01,000 --> 00:00:02,000
The room is dark.
輸出
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Windows 字幕工具會寫的兩樣東西是標記與 CRLF 換行，所以常被混為一談——但它們是兩件事，這一頁只寫第一件。預期檔案裡每個回車都是輸入自己的，標記加在它們前面。若一頁連換行也改寫，就會悄悄重排每一份交給它的檔案，那正是下游在乎之前沒人會注意到的改動。
本來就帶標記的檔案
輸入
1
00:00:01,000 --> 00:00:02,000
Already marked.
輸出
1
00:00:01,000 --> 00:00:02,000
Already marked.
輸入已經有標記，所以產物逐位元組等於輸入——檔案剛好保留一個。天真版本會直接貼上標記、不先清掉原有的，結果是兩個；重複的標記在每個編輯器裡都看不見，對任何讀開頭位元組的東西卻是一份不同的檔案。對已帶標記的檔案再跑一次，應該是連想都不用想就能做的事。
常見問題
給字幕檔加 BOM 到底改變了什麼？
檔案最前面的一個字元：U+FEFF，在 UTF-8 裡寫成三個位元組 EF BB BF。沒有字幕被新增、刪除或編輯，時間碼沒有移動，字幕編號與換行原樣出來，每一行的文字都沒被碰。若你比對兩份檔案，唯一不同的是第一行，而且只差開頭三個位元組。
為什麼加了 BOM 的字幕，上下兩欄看起來一模一樣？
因為被加上的字元沒有形狀。U+FEFF 是零寬不斷行空格，所以按播放器方式算繪文字的欄位，前後看起來相同。改變是真的，而且就在你下載的檔案裡：差別是開頭三個位元組。該看的是編輯器的編碼指示，或十六進位檢視器開頭的 EF BB BF，而不是文字本身。
字幕加 BOM 工具對同一份檔案跑兩次安全嗎？
安全。這一頁會先移除已存在的標記再寫自己的，所以本來就帶標記的檔案原樣返回，沒有的檔案剛好得到一個。跑兩次與跑一次相同。這也代表一份經過這一頁、又被別的工具加了第二個標記的檔案，只要再送進來一次就會清乾淨，因為只有一個會留下。
加完 BOM 再轉成別的字幕格式，標記還在嗎？
在本站的轉換頁上不會——它們寫出不帶標記的純 UTF-8，所以在這裡加的標記不會跟著格式轉換過去。工作順序要照這個排：先轉檔，再把加標記當成交付前的最後一步。這通常也是更合理的順序，因為標記是完成檔案的屬性，不是字幕內容的屬性。
字幕加 BOM 會改變檔案原本的換行嗎？
不會。Latin-1 或 UTF-8 的標記是放在檔案第一個位元組前的一個字元，對後面的內容沒有影響。滿是 CRLF 的 Windows 檔案仍然是 CRLF，Unix 檔案仍然是 LF，混合換行的檔案出來還是同樣的混合。改換行是另一頁的事，讓一頁悄悄做兩件事是個壞主意。
哪些字幕格式可以加上 BOM？
本站處理的 12 種都可以：SRT、WebVTT、ASS、SSA、SBV、SAMI、LRC、MicroDVD、TTML、JSON 與 CSV。標記管的是檔案開頭位元組，不是字幕格式，所以沒有格式專屬的細節要弄對——連完全沒有時間軸的純文字轉錄稿也能攜帶。