一個嚴格的 UTF-8 解碼 API 替代方案完全在您的瀏覽器中執行，接受十六進位、十進位和 8 位元二進位位元組標記法，並在遇到格式錯誤的位元組序列時以致命錯誤拒絕，而不是以 U+FFFD 替換字元取代。UTF-8 編碼器 / 解碼器將瀏覽器的標準 TextEncoder 與設定為致命模式的 TextDecoder 配對，因此過長編碼、截斷序列、孤立的接續位元組、代理編碼以及 U+10FFFF 以上的值都會產生明確的失敗，而不是問號。每個 Unicode 文字輸入在編碼前也會被篩檢未配對的 UTF-16 代理碼元，防止 JavaScript 字串中包含格式錯誤片段時在轉換過程中被悄悄改寫的常見平台行為。十六進位輸出為大寫兩位元位元組，以空格分隔；十進位輸出範圍從 0 到 255；二進位輸出則為每個位元組正好 8 個位元。輸入停留在當前分頁中，頁面不會上傳或記錄任何內容，作業上限為 200,000 個 UTF-16 碼元的文字或 200,000 個位元組的標記法，以保持記憶體、權杖解析和介面的可預測性。
為何開發人員要取代舊式解碼 API
許多語言層級的解碼輔助程式仍然將其失敗隱藏在單一替換字元後方，一旦那些問號被寫回檔案、透過網路傳送或與校驗和進行比對，就會成為真正的問題。PHP 的 utf8_decode 函式之所以被棄用，正是因為它會捨棄不符合目標編碼的位元組，並產生呼叫端無法可靠驗證的資料。Python 的編解碼器層提供 //ignore 和 //replace 錯誤處理器來移除或取代，但兩者都不會在位元組序列結構不合法時停止管線。JavaScript TextDecoder 確實提供了致命選項，但大多數參考程式碼片段將其關閉，接受呼叫端貼上的任何位元組。因此，更嚴格的替代方案需要同時做兩件事：嚴格解析位元組標記法，以及當位元組未編碼任何字元時拒絕自行產生字元。
致命解碼與靜默替換字元
此轉換器在瀏覽器 TextDecoder 上啟用致命旗標，因此任何偏離格式正確 UTF-8 序列的情況都會在結果面板中引發錯誤，而不是發出替換字元。此區別在以下三種情況下很重要：當您從其他服務接收負載並需要確認其確實為 UTF-8 時；當您在除錯偶爾會發出過長形式的編碼器時；以及當您在遷移前稽核舊檔案的代理編碼損壞時。相同的致命政策在編碼時反向適用：JavaScript 字串可能因不良貼上或部分串流而包含未配對的 UTF-16 代理半字，平台 TextEncoder 會悄悄將每個取代為 U+FFFD。轉換器會先檢查這些片段，若發現任何片段則拒絕轉換，因此往返聲明是可驗證的，而非名義上的。如需更深入的說明，在不使用靜默替換字元的情況下解碼 UTF-8 位元組指南更詳細地說明了相同的致命旗標推理。
位元組序列的接受輸入標記法
三種標記法描述相同的底層位元組陣列，每種都由其專屬的權杖化器解析。此工具的十六進位輸出使用大寫兩位元位元組，以空格分隔，但解碼器也接受以逗號分隔的權杖、每個分隔權杖上的可選 0x 前綴，或一個連續的偶數長度十六進位字串。十進位輸入僅接受整數權杖，值從 0 到 255。二進位輸入要求每個權杖正好為 8 個零或一字元，除空白字元外不允許任何分隔符。
| 標記法 | 權杖形狀 | 可選前綴 | 連續形式 | 位元組 0xC2 的範例 |
|---|---|---|---|---|
| 十六進位 | 一個或兩個十六進位數字 | 每個權杖上的 0x | 是，偶數長度 | C2 或 0xC2 |
| 十進位 | 整數 0–255 | 無 | 否，分隔權杖 | 194 |
| 二進位 | 正好 8 個位元 | 無 | 否，分隔權杖 | 11000010 |
空輸入解碼為空文字，使往返檢查自我一致。任何不符合上述規則的內容——三個字元的十六進位權杖、超過 255 的十進位值、短於或長於 8 個字元的二進位權杖——會在解碼器執行前被拒絕，因此使用者會看到格式問題，而不是損毀的文字輸出。
將 UTF-8 十六進位、十進位和二進位解碼為文字
- 開啟 UTF-8 編碼器 / 解碼器，並將作業選擇器設為「UTF-8 位元組轉文字」。
- 選擇與來源相符的標記法——十六進位、十進位或二進位——以便解析器使用正確的權杖化器和邊界規則。
- 將位元組權杖貼到輸入欄位中。十六進位接受以空格或逗號分隔的一位或兩位數權杖、可選的 0x 前綴，或一個連續的偶數長度字串。十進位僅接受整數權杖。二進位要求每個權杖正好為 8 個零或一字元。
- 執行轉換。解碼器以致命模式執行，因此任何格式錯誤的位元組——包括過長編碼、截斷序列、孤立的接續位元組、代理編碼以及 U+10FFFF 以上的值——都會引發明確錯誤，而不是傳回替換字元。
- 將產生的 Unicode 文字與來源格式進行比對，然後透過相同的工具重新編碼，以確認往返作業，再取代任何原始資料。
值得測試的錨定 UTF-8 序列
當純量值跨越 RFC 3629 所定義的界限時，位元組邊界會改變，少數錨定值會立即暴露出編碼錯誤。ASCII 字元保持其單位元組形式，U+007F 以下的值維持一個位元組，U+0080 過渡開始雙位元組範圍，U+0800 開始三位元組範圍，U+10000 開始大多數表情符號使用的四位元組範圍。下表列出轉換器本身用於其內建測試的值。
| 純量值 | 意義 | UTF-8 位元組（十六進位） | 位元組數 |
|---|---|---|---|
| U+0024 | 美元符號 $ | 24 | 1 |
| U+0041 | 字母 A | 41 | 1 |
| U+007F | ASCII 邊界 | 7F | 1 |
| U+00A2 | 分符號 ¢ | C2 A2 | 2 |
| U+0800 | 3 位元組邊界 | E0 A0 80 | 3 |
| U+20AC | 歐元符號 € | E2 82 AC | 3 |
| U+1F600 | 笑臉 😀 | F0 9F 98 80 | 4 |
| U+10FFFF | 最大純量 | F4 8F BF BF | 4 |
如果您的位元組恰好是不同的編碼，例如 Windows-1252、Shift JIS、GBK 或任何 ISO-8859 系列，強制將其通過 UTF-8 將永遠會失敗——而該失敗就是診斷結果。將致命錯誤視為識別原始編碼的訊號，而非需要消除的問題。
限制、隱私與往返驗證
此轉換器將文字輸入上限設為 200,000 個 UTF-16 碼元，將解碼位元組標記法上限設為 200,000 個位元組，使最壞情況的配置保持可預測，並防止頁面在過大的貼上時卡住。它不會串流檔案、接受上傳或呼叫遠端服務；整個轉換作業完全透過頁面本身的 JavaScript 執行，沒有記錄、正規化、翻譯、跳脫或自動複製結果。若要在替換原始成品前驗證轉換，請將可疑文字以您選擇的標記法編碼為位元組，然後將位元組輸出再貼回解碼器端。如果往返作業逐字元傳回您的原始文字，則標記法和位元組邊界正確；如果解碼器在特定位移回報致命錯誤，則來源並非您所認為的 UTF-8。為可靠使用，請從短的已知樣本開始，選擇正確的表示法，檢查位元組邊界，並在轉換未知來源前保留原始資料。
如果您正在權衡選項，XOR 加密線上批次處理：處理長 UTF-8 訊息對此有詳細說明。