UTF-8 解碼範例是 E2 82 AC：3 個十六進位位元組，在位元組序列為有效 UTF-8 時會解碼成歐元符號 (€)。UTF-8 解碼分為兩個階段：先將表示法解析成有順序的位元組陣列，再依 RFC 3629 定義的編碼規則將這些位元組解讀為 UTF-8。十六進位、十進位和 8 位元二進位只是同一個位元組陣列的 3 種檢視方式；變更表示法不會改變底層字元。UTF-8 編碼器／解碼器可處理兩個方向，因此你可以從 Unicode 文字開始、檢查其 UTF-8 位元組，或貼上嚴格的位元組詞元並還原文字。其解碼器採用致命錯誤處理：格式錯誤的位元組序列會產生明確錯誤，而不是可能掩蓋資料損毀情況的替代字元。所有處理都留在目前的瀏覽器分頁中。若要得到可靠的結果，請先從一段已知且簡短的範例開始，確認所選表示法，檢查每個位元組邊界，並在取代任何原始資料前再次解碼編碼結果。
UTF-8 解碼器實際會做什麼
解碼並非將位元組值與字元並排放置那麼簡單。首先，轉換器會將所選表示法解析成有順序的位元組陣列。接著，它會檢查該陣列是否符合 RFC 3629 定義的 UTF-8 結構：起始位元組標示序列長度，後續位元組補完序列，而所得值必須是允許的 Unicode 純量值。Unicode 核心規格定義了用於此項解讀的純量值範圍。有效的純量值佔用 1 至 4 個位元組。ASCII 碼點保留其 1 位元組值，較大的值則使用起始位元組與後續位元組的模式。
請將 3 個單位分開：位元組是 8 位元，Unicode 碼點識別字元，而 UTF-16 碼元是 JavaScript 字串使用的儲存單位。補充字元可以是 1 個 Unicode 碼點、4 個 UTF-8 位元組，通常也是 2 個 JavaScript UTF-16 碼元。在知道位元組序列的編碼方式之前，它並沒有可見的意義。此轉換器只假設 UTF-8，因此不會猜測任意位元組是否屬於其他字元集。
在瀏覽器中解碼範例
使用位元組轉文字模式，在將來源序列視為文字前先驗證它。
- 選擇「UTF-8 位元組轉文字」，然後選取十六進位、十進位或二進位。E2 82 AC 範例請使用十六進位。
- 以該表示法要求的嚴格格式貼上位元組詞元。這個範例請將 E2 82 AC 輸入為 3 個以空格分隔的十六進位位元組詞元。
- 選取轉換按鈕。工具會解析詞元，並嘗試執行致命錯誤式 UTF-8 解碼。
- 將確切輸出與預期文字及所選來源格式比較。對這個範例而言，解碼結果應為歐元符號 (€)。
- 反向轉換：選擇文字轉 UTF-8 位元組，保持相同表示法，並確認重新產生的位元組符合 E2 82 AC。在兩個方向一致前，請保留來源資料。
這項比較很重要，因為成功解析表示法並不保證是有效的 UTF-8。轉換器會檢查這兩個層級，並拒絕將格式錯誤的位元組呈現為經過驗證的原始文字。
各種表示法的輸入規則
請選擇符合來源內容的表示法，而不是你希望它採用的格式。轉換器支援以下輸入與顯示規則：
| 表示法 | 接受的位元組輸入 | 編碼文字時的顯示方式 |
|---|---|---|
| 十六進位 | 以空格或逗號分隔的 1 位數或 2 位數位元組詞元、分隔詞元可選擇使用 0x 前置字串，或是 1 串長度為偶數的連續十六進位字串。 | 以空格分隔的大寫 2 位數位元組。 |
| 十進位 | 僅限整數詞元，每個位元組值介於 0–255 範圍。 | 介於 0 至 255 的位元組值，以空格分隔。 |
| 二進位 | 每個位元組詞元必須恰好包含 8 個零或一字元。 | 每個位元組恰好 8 個位元。 |
0x 前置字串應用於分隔的十六進位詞元，而不是連續形式內部。空白輸入會解碼成空白文字。這些規則僅管 governs 表示法：格式正確的十六進位、十進位或二進位詞元，仍可能描述格式錯誤的 UTF-8 並導致解碼失敗。
用於已知答案檢查的參考值
這些標準 UTF-8 值可用於跨 ASCII、多位元組字元、補充字元和邊界值的已知答案檢查。
| 字元或邊界 | Unicode 純量值 | UTF-8 位元組 |
|---|---|---|
| 美元符號 | U+0024 | 24 |
| A | U+0041 | 41 |
| 分符號 | U+00A2 | C2 A2 |
| 歐元符號 | U+20AC | E2 82 AC |
| 露齒笑臉 | U+1F600 | F0 9F 98 80 |
| ASCII 下邊界 | U+007F | 7F |
| 3 位元組邊界 | U+0800 | E0 A0 80 |
| 最大純量值 | U+10FFFF | F4 8F BF BF |
診斷位元組層級的結果時，邊界值十分重要。U+007F 仍是 1 位元組值，U+0800 開始 3 位元組模式，而 U+10FFFF 是允許的最大純量值。超過此上限的所謂 4 位元組序列無效，並非延伸點。
嚴格解碼會揭露的錯誤
致命錯誤式解碼器能區分可解析的表示法與有效的 UTF-8。十六進位數字可能格式完全正確，卻描述有效 UTF-8 序列無法包含的位元組。轉換器會拒絕：
- 例如 C0 AF 的超長編碼。
- 例如 E2 82 的截斷序列。
- 孤立的後續位元組。
- 代理項碼點的 UTF-8 編碼。
- 高於 U+10FFFF 的值。
這些失敗表示位元組不是有效的 UTF-8，但單憑錯誤無法得知來源是遭截毀、損壞，還是使用不同字元集編碼。解碼器會回報明確錯誤，而不是將替代字元呈現為經過驗證的文字。在編碼端，工具也會在呼叫 TextEncoder 前檢查 JavaScript 字串中有無未配對的 UTF-16 代理項。孤立代理項通常會被替換為 U+FFFD，因此工具會拒絕它們，以免在無聲中改變輸入；代表補充字元的有效代理項配對則會被接受。
以往返轉換驗證結果
往返轉換可檢查解碼後的字元是否能再次產生原始 UTF-8 位元組序列。
- 保留一份未經更動的原始位元組表示法副本。
- 解碼來源，並將確切結果與預期文字比較。
- 使用相同表示法，將該文字重新編碼成 UTF-8 位元組。
- 將重新產生的位元組與原始位元組比較，檢查的是位元組值，而不只是間距或字母大小寫。
結果面板會依操作顯示位元組或碼點。成功的往返轉換表示，在相同假設下，解碼後的文字會重新編碼成相同的 UTF-8 位元組，但無法證明這些位元組原本就 intended 以 UTF-8 表示。當來源不確定時，請繼續保留來源。
當位元組使用其他編碼時
此轉換器只假設 UTF-8，不會自動偵測 Windows-1252、Shift JIS、GBK 或 ISO-8859 系列等舊式編碼。如果舊式位元組解碼失敗，請找出其原始編碼，不要強迫它們通過 UTF-8。UTF-8 位元組也不等同於 Unicode 碼點、UTF-16 碼元、HTML 實體、URL 百分號編碼、Base64、加密或壓縮。Base64 與百分號編碼會將位元組包裝成不同傳輸用途的格式；它們並未定義 UTF-8 所提供的 Unicode 到位元組對應。
當序列解碼結果出乎預期時，請先確認它是否確實源自 UTF-8。成功解碼是位元組構成有效 UTF-8 的證據，但舊式位元組序列偶爾也可能同時在兩種編碼下有效，因而產生看似合理卻非預期的文字。
限制與本機處理
輸入上限為文字 200,000 個 UTF-16 碼元，以及已解碼表示法 200,000 個位元組。轉換器不會串流處理大型檔案，也不接受上傳，因此大型資料請使用專用的二進位工具。
- 所有文字與位元組都留在目前的分頁中。
- 不會上傳、記錄或儲存任何內容。
- 轉換器不會為其他情境正規化、翻譯或逸出文字。
- 結果不會自動複製。
這些條件讓簡短且受控的轉換既實用，又能降低意外曝露來源資料的風險。無論如何都請保留原始資料，尤其是在解碼來自陌生系統的位元組時。
請從已知序列開始，確認表示法，並在依賴解碼後的文字前，確認往返轉換完全無誤。嚴格驗證能將位元組轉換的結果變成你可以檢查的成果，而不僅是單憑信任。