UTF-8 轉換器可將每個最多 10 MB 的本機文字檔轉換為經過驗證、可下載的 UTF-8 位元組，而且不必上傳來源檔案。當你搜尋「convert to UTF-8 bulk」時，重要差別在於此工具一次只會明確轉換一個檔案；你可以對資料夾中的檔案重複執行此工作流程，但它並非以同時處理多個檔案的批次上傳工具來呈現。選擇實際產生該檔案的編碼，讓瀏覽器進行解碼，在預覽中檢查非 ASCII 字元，然後下載不含 BOM 的結果。支援的來源編碼包括 UTF-8、UTF-16 little-endian、UTF-16 big-endian 和 Windows-1252。它不會猜測來源編碼，因為看似合理的舊式位元組仍可能對應到錯誤的名稱、標點符號或符號。對於資料庫傾印檔或數 GB 的日誌，請改用可信賴的串流轉換工具，並明確指定來源與目標編碼。這種方式可讓每次轉換都保有稽核性：所選的解碼器、預覽、驗證結果及下載的成品，都與你選定的來源編碼相符。
「大量」的意涵是可重複的檔案工作流程
「bulk」搜尋可能指兩種不同工作：對多個檔案套用相同的編碼變更，或處理一個非常大的檔案。UTF-8 轉換器透過可逐檔重複的工作流程來處理前者；它並未提供多選的批次佇列。請列出打算處理的檔案清單，使用各自的正確來源模式轉換每個檔案，並為每個輸入檔案分別下載結果。比起將同一組猜測的設定套用到整個資料夾，這種做法更安全，因為舊式位元組序列可能在一種以上的編碼下都是有效的，卻代表不同的字元。
對於一整批業務文字、日誌或匯出檔，本機處理模式同樣重要。瀏覽器會讀取所選檔案、建立預覽，並透過本機可下載的 URL 提供轉換結果；來源位元組不會上傳。變更所選檔案或來源編碼時，會取消顯示中的結果，並使先前的下載 URL 失效，因此請先完成一個轉換結果的檢查與下載，再開始下一個。
識別產生檔案的編碼
請從來源出處著手，而非外觀。確認是哪個應用程式寫入該檔案、使用了哪種匯出設定，或檔案是否附有可靠的 metadata。對於 UTF-16，請分別判斷位元組順序以及是否含有 BOM。相符的 BOM 會被辨識並移除，但僅憑 BOM 的存在，並不能將未知的舊式編碼變成安全的自動選擇。轉換器刻意要求明確選擇，讓轉換過程維持可稽核性。
轉換器會套用瀏覽器依據 WHATWG Encoding Standard 所述的標準化解碼行為。如需有效 UTF-8 位元組序列的正式定義，請參考 RFC 3629。
| 來源模式 | 識別的內容 | 相關轉換行為 |
|---|---|---|
| UTF-8 | 以 UTF-8 位元組編碼的標準 Unicode 文字 | 來源會在遇到致命錯誤時停止並進行驗證。開頭的 UTF-8 BOM 會被消耗，且下載的輸出不會加上 BOM。 |
| UTF-16LE | 低位元組先儲存的 UTF-16 | 位元組會依 little-endian 順序解碼。相符的 BOM 會被辨識並移除，而有效的代理項目配對會轉變成完整字元。 |
| UTF-16BE | 高位元組先儲存的 UTF-16 | 位元組會依 big-endian 順序解碼。相符的 BOM 會被辨識並移除，而有效的代理項目配對會轉變成完整字元。 |
| Windows-1252 | 常遭誤標為 ISO-8859-1 的常用西方舊式 code page | 瀏覽器依標準定義的解碼器會先對應舊式標點符號與符號位元組，再將解碼後的字元編碼為 UTF-8。 |
轉換一個檔案並下載 UTF-8 輸出
- 判定真正的來源編碼。 請使用產生該檔案的應用程式、匯出設定或可靠的檔案 metadata。如果檔案是以 UTF-16 寫入，必須先確認它是 little-endian 還是 big-endian，才能選擇模式。
- 開啟 UTF-8 轉換器並選擇檔案。 選擇適當的來源編碼，再選擇一個本機文字檔。支援的檔案大小上限為 10 MB，而且會在瀏覽器讀取檔案前檢查大小。
- 執行轉換。 所選位元組會在遇到致命錯誤時停止並解碼，接著編碼為 UTF-8。在 UTF-8 模式下，無效的後續位元組、遭截斷的序列及禁止的編碼都會造成明確的失敗，而不會以替代字元取代。格式錯誤的 UTF-16 代理項目序列也會遭到拒絕。如果轉換失敗，請重新檢查來源選擇，不要接受失敗的結果。
- 檢查解碼後的預覽。 請檢視具代表性的名稱、標點符號、貨幣符號及非 ASCII 行。確認文字可讀，且字元確實屬於預期的紀錄或文件。來源與輸出的位元組數也會顯示出來，讓你看出表示方式是否擴大或縮小。
- 下載 UTF-8 檔案。 輸出不會包含 UTF-8 BOM，而且檔名會加上 -utf8。如果變更來源編碼或所選檔案，先前的結果與下載 URL 都會失效，因此任何變更後都應重新產生並下載成品。
- 在目的地測試下載結果。 請在將會使用該檔案的應用程式中開啟轉換後的檔案，並檢查具代表性的紀錄。在完整工作流程通過驗證前，請保留原始檔案。
閱讀預覽與位元組數
預覽是一項實用的正確性檢查，而不是完整的位元組層級證明。它可能不會顯示每個控制字元或正規化差異，因此應聚焦於最可能暴露解碼器選擇錯誤的內容：人名、撇號、引號、貨幣符號、行分隔符，以及完整的非 ASCII 段落。轉換器不會正規化 Unicode、翻譯語言，也不會在解碼與 UTF-8 編碼自然造成的變化之外修改行尾符號。
來源檔案與其 UTF-8 輸出可能具有不同的位元組數，因為不同編碼對相同字元會使用不同的位元組長度。因此，擴大或縮小本身並不是資料遺失的證據。重要的檢查是解碼後的字元是否仍然正確。在舊式 code page 中，同一個來源字元在轉換後可能占用不同數量的位元組，而 UTF-8 可能使用較長的位元組序列來表示supplementary characters。請使用預覽驗證意義，位元組數則僅作為額外的一致性訊號。
謹慎處理 UTF-16 與 Windows-1252
UTF-16LE 與 UTF-16BE 的差異在於位元組順序，而非預期文字。UTF-16LE 先儲存低位元組，UTF-16BE 則先儲存高位元組。選擇錯誤的順序可能將字母變成無意義的內容，即使檔案仍由可讀的位元組配對構成。包含 emoji 在內的 supplementary characters 會使用 UTF-16 代理項目配對。解碼器會先將有效的 high surrogate 與 low surrogate 結合成一個 Unicode scalar value，再產生 UTF-8 輸出；未配對或格式錯誤的序列會在致命解碼模式下導致失敗，而不會默默產生替代菱形符號。
Windows-1252 需要自己的明確模式，因為它經常被誤認為 ISO-8859-1。80 到 9F 的位元組包含可列印的標點符號與符號，例如歐元符號及彎引號。瀏覽器依標準定義的 Windows-1252 解碼器會先套用這些對應關係，再將字元重新編碼為 UTF-8。Windows-1252 歐元符號占用 1 個來源位元組及 3 個 UTF-8 位元組。輸出代表的是解碼後的字元，而不是逐位元組複製，這也是正確的舊式編碼轉換可能產生較大檔案的原因。
規劃多檔案與大型檔案工作
對於資料夾中的檔案，請逐檔重複相同的來源選擇、轉換、預覽、下載及驗證工作流程。瀏覽器端的上限為 10 MB，因為此實作使用記憶體中的檔案緩衝區。此上限並非建議值：較大的檔案會在載入前遭到拒絕，因此不要企圖藉由嘗試上傳數 GB 的檔案來規避限制。
對於資料庫傾印檔或數 GB 的日誌，請改用可信賴的串流轉換工具，並明確指定來源與目標編碼。串流更適合無法放入瀏覽器記憶體的檔案，也能納入受控的批次流程。含有混合編碼的檔案同樣無法可靠地由單一解碼器修復。請先修正或拆分混合的來源，再使用適當的模式轉換產生的各個區段。
替換原始檔案前先驗證結果
替換任何來源成品前，請先將下載的檔案放進目的地應用程式中執行。確認具代表性的名稱仍保有預期的重音符號或字元、標點符號維持自然、貨幣符號正確顯示，且匯入的紀錄包含預期文字。乾淨的預覽不能取代在可能具有自身匯入假設的軟體中進行測試。
轉換器不會以啟發式方法修復 mojibake，也不會重建在轉換前就已損毀的文字。它會依據你的明確選擇解碼位元組，再將產生的字元重新編碼。若要建立可稽核的大量工作流程，請記錄每個檔案使用的來源模式，註明下載的檔名會加上 -utf8，並保留每個原始檔案，直到其目的地測試成功為止。如此可讓流程維持可重複性，而不會將不確定的編碼猜測變成永久資料。