UTF-8 解碼會將一串 UTF-8 位元組轉換為 Unicode 文字，方式是將前導位元組與後續位元組分組，形成完整的字元值，並套用 UTF-8 的有效性規則。 Unicode 碼點不等同於位元組：有效的純量值會使用 1 至 4 個位元組，而 ASCII 則保留其單一位元組的數值。

UTF-8 編碼器／解碼器可將 Unicode 文字編碼為十六進位、十進位或 8 位元二進位位元組表示法，並將這些表示法解碼回文字，且所有作業皆在瀏覽器中完成。請使用顯示表示法檢查位元組序列，然後確認解碼後的文字重新編碼時會產生相同的位元組。

若要獲得可信的結果，應區分有效的轉換與對來源資料預期含意的推測。

utf8 decode explained
UTF8 解碼解析：位元組如何成為 Unicode

以淺顯英文說明解碼模型

Unicode 會為每個有效的 Unicode 字元指派一個純量值。UTF-8 會將該純量值編碼為位元組序列：前導位元組指出序列的寬度，後續位元組則提供其餘的值位元。解碼會反轉這些步驟，並非每個可見字元各對應讀取 1 個位元組。

這些規則由 RFC 3629 與 Unicode 核心規格 定義。UTF-8 允許最高至 U+10FFFF 的純量值，並排除代理項碼點。因此，已編碼的代理項屬於無效的 UTF-8，而不是代表字元的另一種方式。

位元組寬度如何顯示字元範圍

單一位元組純量值涵蓋 U+0000–U+007F；雙位元組純量值涵蓋 U+0080–U+07FF；三位元組純量值涵蓋 U+0800–U+FFFF，但不含代理項；四位元組純量值涵蓋 U+10000–U+10FFFF。因此，U+007F 是最後一個單一位元組純量值，而 U+0800 是第一個需要 3 個位元組的純量值。

經驗證的 UTF-8 參考點可清楚呈現這些寬度：

文字 Unicode 純量值 UTF-8 十六進位位元組 寬度
$ U+0024 24 1 個位元組
A U+0041 41 1 個位元組
¢ U+00A2 C2 A2 2 個位元組
€ U+20AC E2 82 AC 3 個位元組
😀 U+1F600 F0 9F 98 80 4 個位元組
最大純量值 U+10FFFF F4 8F BF BF 4 個位元組

十六進位表示中的空格分隔的是位元組，而非 Unicode 字元。多位元組序列中的每個位元組，都會參與重建單一純量值。

相同位元組的十六進位、十進位與二進位檢視

轉換器接受 3 種位元組表示法，但每種表示法都有不同的輸入語法：

表示法 可接受的解碼輸入 輸出格式
十六進位 以空格或逗號分隔的 1 或 2 位數位元組詞彙、以分隔開的詞彙加上選用的 0x 前置詞，或單一連續且長度為偶數的十六進位字串 以空格分隔的大寫雙位數位元組
十進位 僅限整數詞彙，每個位元組限定在 0 至 255 之間 以空格分隔的 0 至 255 十進位值
二進位 每個詞彙恰好包含 8 個零或一字元 每個位元組恰好 8 個位元

變更表示法不會改變底層的 UTF-8 序列。例如，C2 A2、其十進位位元組形式，以及其 8 位元二進位形式，都描述用來編碼 U+00A2 的位元組。空輸入會解碼為空文字。

UTF-8 不是 Base64、URL 百分比編碼、HTML 實體、十六進位數字、加密或壓縮。它將 Unicode 純量值映射至位元組；其他格式則有各自的儲存或傳輸用途。

嚴格解碼為何拒絕受損輸入

轉換器使用會產生致命錯誤的 UTF-8 解碼器，因此格式錯誤的資料會導致明確錯誤，而不會顯示可能與原始文字混淆的 U+FFFD 替代字元。常見的失敗情況包括：

  • 超長編碼：C0 AF 試圖使用超出必要數量的位元組來表示某個值。
  • 截斷序列：E2 82 在所需的後續位元組抵達前就結束。
  • 孤立的後續位元組：標記為後續資料的位元組出現時，卻沒有有效的前導位元組。
  • 代理項編碼：這些位元組代表遭禁止的 UTF-16 代理項碼點。
  • 超出範圍的值：序列解析後的值高於 U+10FFFF。

錯誤可能表示表示法格式錯誤，也可能是無效的 UTF-8，因此應同時檢查輸入格式與來源編碼。在編碼方向，工具也會在使用瀏覽器的 TextEncoder 前，檢查是否有未配對的 UTF-16 代理項碼元。雖然平台編碼器通常會以 U+FFFD 取代這類片段，但此轉換器會拒絕它們，以免在宣稱無損轉換期間悄悄改變文字。代表補充字元的有效代理項配對則會被接受。

將 UTF-8 位元組解碼為文字

  1. 保留原始資料。保留一份未經修改的副本，尤其是在來源編碼不確定時，並先從一小段已知樣本開始。
  2. 選擇解碼方向。選取「UTF-8 位元組轉文字」，然後依來源表示法選擇十六進位、十進位或二進位。
  3. 輸入格式嚴格的位元組詞彙。十六進位可使用分隔的位元組，例如 C2 A2；以逗號分隔的位元組，例如 C2,A2；或連續且長度為偶數的字串，例如 C2A2。以空格分隔的十六進位詞彙可加上選用的 0x 前置詞。二進位詞彙各自必須恰好包含 8 個位元。
  4. 執行轉換。選取轉換按鈕，然後等待結果或明確的錯誤訊息。
  5. 檢查解碼後的文字。確認可見結果符合預期的應用程式情境。如果解碼失敗，請修正表示法或找出原始編碼，而不要強迫位元組通過 UTF-8。
  6. 驗證往返轉換。使用相同的表示法重新編碼完全相同的解碼文字，然後將每個產生的位元組值與來源序列比較。
  7. 只替換經過驗證的資料。在解碼文字與往返輸出都符合預期之前，保留原始資料。

若要執行反向工作流程，請選擇「文字轉 UTF-8 位元組」，輸入 Unicode 文字，選取所需的表示法，並在將輸出用於其他位置前檢查位元組邊界。

成功解碼無法證明的事項

成功解析可證明位元組符合 UTF-8，但無法證明來源原本預期使用 UTF-8 編碼。離開該情境，位元組序列本身並沒有可見的含意。轉換器假設使用 UTF-8，並不會自動偵測 Windows-1252、Shift JIS、GBK 或 ISO-8859 系列等舊版編碼。如果舊版位元組無法通過解碼，請找出其原始編碼，而不要強迫它們使用這個僅支援 UTF-8 的工作流程。

UTF-8 位元組也不同於 Unicode 碼點與 JavaScript UTF-16 碼元。微笑臉 U+1F600 是 1 個 Unicode 碼點、4 個 UTF-8 位元組，通常也是 2 個 JavaScript UTF-16 碼元。工具不會正規化文字，因此依標準等價形式書寫的字串，不會被悄悄改寫為偏好形式。

往返轉換可確認解碼文字會映射回相同的 UTF-8 位元組，但無法確立來源的語意、修復受損資料，或將 UTF-8 轉換為 Base64 或 URL 編碼等傳輸格式。

限制與本機資料處理

  • 文字輸入：轉換器最多接受 200,000 個 UTF-16 碼元。1 個補充字元可能會占用其中 2 個碼元。
  • 已解碼的表示法：輸入上限為 200,000 個位元組。二進位表示法會將每個位元組展開為 8 個位元，增加詞彙解析與輸出作業量。
  • 大型資料：轉換器不會串流處理大型檔案，也不接受上傳。大型資料應使用專用的二進位工具。
  • 本機處理：文字與位元組會留在目前的分頁中。不會有任何內容被上傳、記錄、儲存、正規化、翻譯、逸出至其他情境，或自動複製。

請仔細閱讀結果面板中的單位，因為它會依操作內容顯示位元組或碼點。碼點計數不應視為 UTF-8 位元組計數，而位元組計數也不應解讀為可見字元的數量。

相關閱讀：大型文字的線上 XOR 加密：100,000 位元組限制。

相關閱讀：Mac 上的 Base32 解碼：嚴格 UTF-8 瀏覽器工作流程。