批次 UTF-8 解碼可將一整段 UTF-8 位元組表示法(十六進位、十進位或 8 位元二進位)單次轉換成可讀的 Unicode 文字，並在輸入格式錯誤時提供致命錯誤處理。整個轉換程序完全在當前的瀏覽器分頁中執行，因此位元組資料流與解碼後的文字都不會上傳到任何遠端伺服器。嚴格的 UTF-8 解碼器會以明確的錯誤訊息拒絕格式錯誤的輸入，而不是靜默地替換成替代字元，這在驗證來自記錄檔、傾印資料，或您無法完全掌控的外部 API 所產生的位元組資料流時特別重要。批次操作會放大微小的錯誤，這就是為何批次中每一個格式錯誤的位元組都會被視為嚴重失敗，而不是輕微警告。本工具每次執行最多可接受 200,000 個位元組，支援以空格或逗號分隔的位元組記號、連續的偶數長度十六進位字串、可選的 0x 前綴、整數型十進位記號，或是精確的八字元二進位群組。結果面板會同時顯示解碼後的 Unicode 文字以及還原出的碼位。由於每一種表示法都只是同一個位元組陣列的不同顯示方式，在十六進位、十進位與二進位之間切換並不會改變底層的 UTF-8 序列。
在本情境中「批次 UTF-8 解碼」的真正含義
對大多數搜尋 utf8 decode bulk 的讀者來說，任務相當單純:將一整段位元組表示法送入單一工具，在同一個結果面板中取得對應的 Unicode 文字，而不是一次解碼一個字元。實務上這代表貼上一段多行的十六進位傾印、以空格分隔的一整列十進位記號，或一長串 8 位元的二進位群組，然後在一次操作中取得完整解碼後的文字。UTF-8 編碼器 / 解碼器可在瀏覽器中端對端地處理這項工作，單次處理即可涵蓋最多達其硬性上限 200,000 位元組的全部輸入。
此處的「批次」也是與串流(Streaming)的對比。本工具不會串流處理即時檔案的分塊、不接受上傳，也不會將大型資料分散在多個請求中。它會將輸入視為單一區塊，依您選擇的表示法進行剖析，並產生單一解碼輸出。這種模式適用於記錄檔摘錄、錯誤訊息的複製貼上、除錯工具的十六進位傾印，以及簡短的 API 酬載;至於多 MB 等級的檔案遷移，則留給專用的二進位工具處理。
轉換器支援的位元組表示法
當您從記錄檔、除錯器或說明文件中複製資料時，以下三種表示法涵蓋了絕大多數的位元組格式。三種表示法編碼的是同一個底層位元組陣列;唯一的差異在於每個位元組在頁面上的顯示方式。下表摘要說明在貼上大批資料時最需要注意的記號規則。
| 表示法 | 記號格式 | 單一位元組範例 (U+0024 $) | 三位元組範例 (U+20AC €) |
|---|---|---|---|
| 十六進位 | 大寫兩位數位元組，以空格或逗號分隔;分隔的記號可選擇性加上 0x 前綴;或為單一連續的偶數長度十六進位字串 | 24 | E2 82 AC |
| 十進位 | 以空格分隔、值在 0–255 之間的整數記號 | 36 | 226 130 172 |
| 8 位元二進位 | 每個位元組精確為八個 0 或 1 字元，以空格分隔 | 00100100 | 11100010 10000010 10101100 |
十六進位最為精簡，是記錄檔傾印與大多數除錯器輸出的預設格式。十進位則是您在數值欄位輸出和程式碼範例中常見的形式。二進位最常用於教學，或用於驗證每個位元組邊界是否與預期的 UTF-8 首位元模式對齊。如需這些格式並列的完整說明，請參閱以十六進位、十進位與二進位解碼 UTF-8指南。由於本工具只改變同一個位元組陣列的呈現方式，而不是位元組本身，因此解碼後切換表示法非常簡單。
如何逐步批次解碼 UTF-8 位元組
當您有多行或多位元組輸入，並希望以單一操作進行解碼時，請依下列步驟進行。第一次執行建議使用已知簡短的範例，以便在套用真實資料前先確認表示法是否相符。
- 選擇方向。在 UTF-8 編碼器 / 解碼器上選擇UTF-8 位元組轉文字，然後依您要貼上的位元組格式選擇十六進位、十進位或二進位。
- 將您的位元組表示法貼入輸入欄位。十六進位可使用以空格分隔或以逗號分隔的記號、分隔記號可選擇性加上 0x 前綴，或單一連續的偶數長度十六進位字串。十進位輸入僅能使用整數記號。二進位輸入的每個位元組必須精確為八個 0 或 1 字元。
- 執行轉換。解碼器會剖析表示法，呼叫瀏覽器的致命錯誤 UTF-8 解碼器，接著產生解碼後的 Unicode 文字，或顯示具體的剖析錯誤。
- 查看結果面板中的位元組數與還原出的碼位，然後進行驗證回溯(round trip)。將解碼後的文字複製回文字轉位元組的方向，選擇相同的表示法，確認重新產生的位元組與來源逐位元組相符。
實作範例。ASCII 美元符號 U+0024 在十六進位中為單一位元組 24、在十進位中為 36、在二進位中為 00100100。在十六進位模式中貼上 24 41 24 會解碼為三個字元的字串 $A$。在十六進位模式中將 $A$ 重新編碼會得到 24 41 24。回溯結果一致，這是在替換任何原始資料前最基本的驗證步驟。相同的邏輯可等比放大:貼上 200,000 個十六進位位元組、執行一次、將結果重新編碼，然後確認相等。
為何解碼器拒絕猜測
批次操作會放大微小的錯誤。在十六進位傾印中遺漏一個位元組，或出現一個額外的非十六進位字元，如果解碼器在沒有警告的情況下替換成替代字形，可能會悄悄損壞數千個解碼後的字元。本轉換器使用致命的 TextDecoder，這代表下列輸入會以明確錯誤失敗，而不是產生一連串 U+FFFD 替代字元:
- 超長編碼(Overlong encodings)，例如 C0 AF，代表本應使用較短序列的值。
- 截斷序列(Truncated sequences)，例如 E2 82，其中前置位元組宣告為三位元組字元，但尾隨位元組缺失。
- 孤立的接續位元組(Isolated continuation bytes)，落在 80–BF 範圍內，但前方沒有有效的引導位元組。
- 代理編碼(Surrogate encodings)，嘗試將 UTF-16 代理半段編碼為 UTF-8，即使 Unicode 明文禁止。
- 超過 U+10FFFF 的值，超出 RFC 3629 所標準化的最大 Unicode 純量值。
編碼方向也套用同樣的紀律。JavaScript 字串可能包含未配對的 UTF-16 代理碼元，而平台編碼器通常會將其替換為 U+FFFD;本工具會拒絕這類輸入，以避免所謂的無損轉換靜默地變更輸入內容。代表輔助字元的有效代理對仍會被接受，這就是為何像笑臉 F0 9F 98 80 這種四位元組序列能正常解碼。Unicode 協會在Unicode 標準核心規格中記錄了純量值範圍與代理碼元的禁用規定。
在替換來源前驗證回溯
回溯驗證是確認批次解碼沒有悄悄位移您資料的最簡單檢查方式。解碼完成後，將還原出的文字重新編碼為相同的表示法，然後逐字元比對產生的位元組與您的來源。對於十六進位輸入，重新產生的大寫位元組序列應完全相符。對於十進位輸入，整數序列應完全相符。對於二進位輸入，每個八字元群組應完全相符。本工具保證有效輸入在回溯過程中不會經過正規化、跳脫或轉譯，這項特性讓您得以將解碼後的文字視為原始位元組的忠實複本。
本轉換器同時強制設定嚴格的 200,000 單位上限:文字輸入為 200,000 個 UTF-16 碼元，解碼表示法則為 200,000 位元組。此上限限制了記憶體使用量、記號剖析時間，以及輸出面板大小。若您的來源更大，請以位元組邊界切分為多個區塊，逐一透過轉換器處理，然後將解碼後的輸出重新合併。在每個區塊都成功完成回溯之前，請保留原始資料不動。
批次 UTF-8 解碼不適用的情境
本轉換器僅假設 UTF-8 編碼，不會自動偵測諸如 Windows-1252、Shift JIS、GBK 或 ISO-8859 系列等舊式編碼。若您的位元組源自其中一種編碼，強行以 UTF-8 處理不是會直接失敗，就是在成功解碼後仍產生錯誤的字元。正確的工作流程應先識別原始編碼，使用能識別該編碼的工具轉換檔案，然後才將輸出視為 UTF-8 處理。
UTF-8 位元組也和教學中經常被混淆的若干相關表示法不同:Unicode U+ 表示法的碼點、UTF-16 碼元、HTML 實體、URL 百分比編碼、Base64、十六進位數字、加密，以及壓縮。一個四位元組的表情符號是一個 Unicode 碼點，但佔四個 UTF-8 位元組，通常也佔兩個 JavaScript UTF-16 碼元。若您的目標是將位元組轉換為上述其他任一表示法，請使用專用工具:Base64 使用 Base64 編碼 / 解碼 工具，百分比編碼則使用 URL 解碼器，以此類推。對於多 MB 等級的檔案遷移，請使用串流式二進位工具，因為本機轉換器有其容量上限且不接受上傳。
如需更深入的探討，請參閱線上 AES 加密適用於大量文字:批次輸入指南。