UTF-8 編碼器 / 解碼器會將 Unicode 文字轉換成一序列格式正確的 UTF-8 位元組，並以十六進位、十進位或二進位表示法顯示，再把這些位元組表示法以嚴格錯誤檢查的方式解碼回原始文字。UTF-8 是由 RFC 3629 所標準化的可變寬度編碼，能以每個碼位 1 到 4 個位元組表示 U+0000 到 U+10FFFF 之間的每個 Unicode 純量值。基於瀏覽器的 UTF-8 編碼器 / 解碼器 將兩個方向整合在同一個本地面板中，讓你可以在編碼與解碼之間切換，而無需在網站之間複製資料。編碼使用瀏覽器的 TextEncoder；解碼則使用嚴格模式的 TextDecoder，因此過長序列、截斷序列、孤立的續接位元組、代理編碼，以及 U+10FFFF 以上的值都會被明確地以錯誤拒絕，而不是被悄悄替換成 U+FFFD。兩個方向的上限皆為 200,000 個 UTF-16 碼元（用於文字）或位元組（用於表示法），以確保記憶體、解析與輸出保持可預測。由於整個轉換過程都在目前分頁中本地執行，無論是你的文字或產生的位元組，都不會被上傳、記錄、正規化、翻譯，或複製到任何其他地方。
將文字編碼為十六進位、十進位或二進位位元組
十六進位、十進位與二進位是同一底層 UTF-8 位元組陣列的三種顯示格式；切換表示法並不會改變編碼後的序列，只會改變每個位元組的書寫方式。本工具以固定的格式序列化每個位元組：十六進位輸出使用以空格分隔的大寫兩位數位元組，十進位輸出使用以空格分隔、值域為 0 到 255 的數值，二進位輸出則是每個位元組恰好使用 8 個位元。字母 A（U+0041）編碼為十六進位的 41、十進位的 65、二進位的 01000001。歐元符號（U+20AC）的三個位元組以十六進位表示為 E2 82 AC、以十進位表示為 226 130 172、以二進位表示為 11100010 10000010 10101100。可供轉換器往返驗證的參考錨點包括：美元符號 U+0024 為 24、A 為 41、分符號 U+00A2 為 C2 A2、歐元符號 U+20AC 為 E2 82 AC，以及笑臉表情 U+1F600 為 F0 9F 98 80。由於 UTF-8 是可變寬度，單一字元依其純量值的不同，可能佔用 1、2、3 或 4 個位元組；一個四位元組的表情符號仍然只是一個 Unicode 碼位，通常是兩個 JavaScript UTF-16 碼元。
編碼過程也會在呼叫平台編碼器之前檢查未配對的 UTF-16 代理碼元，因為 JavaScript 字串可能包含這些格式錯誤的片段，而底層的 TextEncoder 通常會將它們替換為 U+FFFD。本工具會拒絕未配對的代理碼元，因此宣稱的無損轉換不會悄悄變更你的輸入；代表輔助字元且正確配對的代理對則會被接受。
將位元組表示法解碼回 Unicode 文字
解碼方向接受嚴格格式的位元組記號。十六進位輸入可以是單一連續的偶數長度字串（例如 E282AC）、以空格分隔的記號（例如 E2 82 AC）、以逗號分隔的記號（例如 E2,82,AC），或加上選擇性 0x 前綴的記號（例如 0xE2 0x82 0xAC）；奇數長度的連續字串會在預設階段就被拒絕。十進位輸入僅接受整數記號，例如 226 130 172。二進位輸入要求每個記號恰好是 8 個零或一字元，例如 11100010 10000010 10101100；長度不符的記號會被拒絕。空輸入會解碼為空文字。最大純量值 U+10FFFF 編碼為十六進位的 F4 8F BF BF，七位元邊界 U+007F 由單一位元組 7F 解碼而得，而 U+0800 邊界則標示出三位元組序列的下緣。
解碼採用嚴格模式。若位元組無法構成有效的 UTF-8 序列——例如過長編碼（如 C0 AF）、截斷序列（如 E2 82）、孤立的續接位元組、代理值，或任何會產生 U+10FFFF 以上純量的序列——轉換器會明確地引發錯誤，而非替換為 U+FFFD。這項保證能讓結果面板中不會出現看似原始文字的替換字元，這在你驗證未知位元組來源時特別重要。若你像 Windows-1252、Shift JIS、GBK 或任何 ISO-8859 系列的舊式位元組無法在此解碼，表示其原始編碼並非 UTF-8，強行透過本工具處理只會得到錯誤；請改為識別其來源編碼。
三步驟使用轉換器
無論你是要編碼 Unicode 文字或解碼位元組表示法，工作流程都相同；只是控制項會切換方向與表示法。
- 選擇方向——文字到 UTF-8 位元組，或 UTF-8 位元組到文字——然後挑選十六進位、十進位或二進位表示法來表示位元組。
- 輸入你的 Unicode 文字，或將嚴格格式的位元組記號貼入輸入欄位，然後按下轉換按鈕以產生結果面板。
- 將結果與你的來源格式比對，對一個簡短的已知樣本執行往返（先編碼再解碼），確認無誤後再替換原始資料。
每次開始時先用一個簡短的已知樣本，例如 A、€ 或 😀，以便在貼上大段內容之前，先確認位元組數量與表示法規則。
UTF-8 位元組寬度參考表
下表整理了 RFC 3629 中明確定義的位元組寬度。每一列顯示純量範圍、該範圍內碼位所需的 UTF-8 位元組數、首位元組位元模式、一個計算範例字元，以及對應的十六進位位元組。表格中的範例值與轉換器本身使用的參考錨點一致，因此以此表進行往返驗證是很好的健全性檢查。
| 純量範圍 | 位元組數 | 首位元組模式 | 範例 | 十六進位位元組 |
|---|---|---|---|---|
| U+0000 – U+007F | 1 | 0xxxxxxx | A (U+0041) | 41 |
| U+0080 – U+07FF | 2 | 110xxxxx 10xxxxxx | ¢ (U+00A2) | C2 A2 |
| U+0800 – U+FFFF | 3 | 1110xxxx 10xxxxxx 10xxxxxx | € (U+20AC) | E2 82 AC |
| U+10000 – U+10FFFF | 4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx | 😀 (U+1F600) | F0 9F 98 80 |
有效的 Unicode 純量值止於 U+10FFFF，且排除 UTF-16 代理碼位（U+D800 到 U+DFFF），因此任何會解碼為代理值或 U+10FFFF 以上值的位元組序列，都會被視為格式錯誤而拒絕。如需針對解碼方向的深入說明，請參考 UTF-8 解碼指南。
為什麼嚴格解碼會拒絕其他工具接受的內容
許多解碼器會以 U+FFFD（官方 Unicode 替換字元）取代無效的位元組，因此即使位元組已損毀、被截斷，或使用了錯誤的字元集，結果面板仍可能顯示文字。本工具中的嚴格解碼器在此情況下拒絕產生文字，這代表成功解碼中的每一個碼位都來自輸入中格式正確的序列。這個特性在你驗證未知位元組來源時格外重要：大量替換字元的出現就是錯誤解碼的明顯徵兆，而嚴格模式會將問題以明確錯誤呈現，而非隱藏在結果之中。
本工具也僅假設為 UTF-8，並不會自動偵測舊式編碼，如 Windows-1252、Shift JIS、GBK 或任何 ISO-8859 系列。能以舊式單位元組編碼乾淨解碼的位元組，在此通常會解碼失敗；這種失敗其實很有用，因為它告訴你原始編碼並非 UTF-8——而這正是靜默替換會掩蓋的資訊。根據 Unicode 17.0 第 3 章，在不知道其編碼的情況下，位元組序列本身並無可見的意義，因此識別來源編碼是驗證工作流程的一部分，而非獨立的事項。
限制、邊界與驗證工作流程
本轉換器將文字輸入上限設為 200,000 個 UTF-16 碼元，將解碼後的表示法上限設為 200,000 個位元組，以限制記憶體使用、記號解析與結果面板的大小；它不會串流處理大型檔案，也不接受上傳，因此對數 MB 等級的資料，請改用具備二進位處理能力的專用工具。所有轉換都在瀏覽器中本地執行，因此輸入與輸出都留在目前分頁中，不會被上傳、記錄、儲存、正規化、翻譯、為其他情境進行跳脫處理，或自動複製。
在你信任本轉換器處理真實資料之前，請依下列簡短的檢查清單進行：
- 先以已知樣本（如 A、€ 或 😀）開始，並確認位元組數量與表示法與位元組寬度表中的參考值相符。
- 將該樣本編碼後，把得到的位元組複製回解碼面板，驗證往返結果與原始文字完全相同。
- 保留原始資料——在往返確認完成之前，保留一份未經更動的來源位元組副本。
- 貼上連續十六進位時，請檢查位元組邊界：每兩個字元必須對齊到位元組邊界，奇數長度會被拒絕。
- 將任何錯誤視為修正輸入的訊號，而非用同一份位元組重試；嚴格錯誤代表這份位元組本來就不可能往返成功。
UTF-8 位元組並不等同於 Unicode 碼位、UTF-16 碼元、HTML 實體、URL 百分號編碼、Base64、十六進位數字、加密或壓縮，因此結果面板會依你所選的操作回報位元組或碼位，而非混用單位。清楚區分這些概念，正是將一次性轉換變成可驗證、可重複的工作步驟的關鍵。
延伸閱讀：二進位到文字編碼：UTF-8 指南。