十六進位文字編碼會將 UTF-8 字串中的每個字元表示為一個或多個位元組，並將每個位元組表示為剛好兩個十六進位數字，因此像 Hello 這樣的 5 個字母 ASCII 單字會變成 10 個字元的字串 48656c6c6f。將十六進位轉回文字就是反向執行該步驟：將輸入分割成位元組配對、把每一對視為 0 到 255 之間的數字，再用 UTF-8 標準解碼所得到的位元組序列。Hex to Text Converter 可在同一個瀏覽器分頁中處理所有三種常見表示法（連續配對、以 ASCII 空白分隔的群組、以及精確的 0xNN 詞彙），明確拒絕格式錯誤的輸入，並以嚴格的 UTF-8 驗證解碼整個位元組陣列，使損壞的位元組絕不會以 Unicode 替換字元 U+FFFD 悄悄出現。
十六進位文字編碼的樣貌
十六進位（hex）是一種以 16 為基底的編號系統，使用 0 到 9 的數字以及 A 到 F 的字母。一個位元組包含八個位元，因此一個位元組可以剛好以兩個十六進位數字表示：00 到 FF。當文字以 UTF-8 編碼時，ASCII 字元佔一個位元組，常見的附腔調字母佔兩個位元組，大多數亞洲文字的字元佔三個位元組，而表情符號等輔助平面字元則佔四個位元組。這代表單一字元在來源中可能佔一、兩、三或四對十六進位數字。
最簡單的例子就是 ASCII 本身。H 字元的碼點是 U+0048，因此編碼為單一位元組 0x48；e 字元是 U+0065，編碼為 0x65；第一個 l 是 U+006C，編碼為 0x6C；第二個 l 同樣為 0x6C；而 o 是 U+006F，編碼為 0x6F。將這五對串接起來會形成連續字串 48656c6c6f，解碼器必須將其解析為剛好五個位元組 48 65 6C 6C 6F，然後以 UTF-8 進行解讀。解碼後的字元依序為 H、e、l、l、o。
多位元組字元讓結構變得更有趣。帶腔調的字母 é 是 U+00E9，UTF-8 將其編碼為兩個位元組序列 C3 A9，因此該單一字元的十六進位來源為 C3A9，也就是四位數而非兩位數。輔助平面表情符號 😀 是 U+1F600，編碼為四個位元組 F0 9F 98 80，會變成八位數字串 F09F9880。在計算輸入長度並將其與下文所述的工具預算進行比對時，必須意識到單一字元可能橫跨多個十六進位配對。
接受的十六進位格式與該選擇哪個選項
十六進位文字來自許多來源，而其周圍的表示法也各不相同。網路 API 可能會回傳連續的二進位區塊，說明文件範例可能會為了可讀性而加入空格，而 C 風格的程式碼片段則可能在每個位元組前加上 0x 前綴。轉換器會將每種樣式視為獨立規則，因此解析器永遠不需要猜測。
| 表示法 | 範例輸入 | 需啟用的選項 |
|---|---|---|
| 連續配對 | 48656c6c6f | 關閉 ASCII 空白、關閉 0x 前綴 |
| 以空白分隔 | 48 65 6c 6c 6f | 開啟 ASCII 空白、關閉 0x 前綴 |
| 每個位元組使用 0xNN 詞彙 | 0x48 0x65 0x6C 0x6C 0x6F | 開啟 ASCII 空白、開啟 0x 前綴 |
| 混合純文字與 0x (無效) | 0x41 42 | 一律拒絕 |
純文字模式要求每個群組只能包含 0 到 9 的數字和 A 到 F 的字母（大寫或小寫），且必須有偶數個數字，因此當啟用空白分隔時，群組 4869 代表兩個位元組，群組 48 代表一個位元組。前綴模式更為嚴格：如果輸入中任何位置出現不區分大小寫的 0x，則每個以空白分隔的詞彙都必須剛好是 0xNN，且同一個輸入中不能出現純文字詞彙。這種嚴格區隔能避免解析器將 0x41 42 視為有效，因為第二個詞彙缺少前綴。如需深入了解這兩種表示法，請參閱 純文字與 0xNN 參考資料。
如何將十六進位轉換為文字
- 從來源複製十六進位位元組。連續來源（例如 48656c6c6f）可直接貼上；以空白分隔的來源（例如 48 65 6c 6c 6f）需要啟用 ASCII 空白選項；每個位元組使用前綴的來源（例如 0x48 0x65 0x6C 0x6C 0x6F）則還需要啟用 0x 前綴選項。
- 開啟 Hex to Text Converter，將輸入貼到十六進位欄位中。如果來源包含開頭的位元組順序記號（例如 EF BB BF），請保留不動；工具會自動消耗開頭的 BOM，並將其餘部分以一般 UTF-8 解碼。
- 切換語法選項，使允許的表示法符合您的輸入。當來源是連續的，啟用空白分隔仍然可以運作；但當來源不含前綴時啟用 0x 前綴並不會產生作用，若來源實際上是混合內容，可能會讓您感到意外。
- 執行解碼。工具會先檢查 2,000,000 字元的原始輸入上限，然後在配置位元組陣列之前，將解析後的位元組數與 1,000,000 位元組的輸出上限進行比對，最後以嚴格的 UTF-8 驗證解碼整個陣列。
- 在唯讀輸出欄位中讀取解碼後的文字。位元組數會與文字並排顯示，方便您確認來源長度除以二（若是前綴輸入則除以較大的每個位元組額外負荷）的結果是否與解碼後的位元組數相符。
- 若瀏覽器在安全情境下授予剪貼簿存取權限，請使用複製按鈕複製解碼後的文字。唯有當解碼後的文字沒有任何碼元時，按鈕才會停用；而即使權限授予失敗，文字仍可手動選取複製。
如果解碼失敗，介面會明確回報一個具體原因，而非進行猜測。奇數長度的數字群組會產生奇數半位元組錯誤，逗號或其他非 ASCII 分隔符號會產生混合語法錯誤，獨立的續接位元組或截斷的多位元組序列會產生無效位元組錯誤，而超出上限則會產生預算錯誤。請修正所指出的問題並重新執行；每次編輯時，前一次的輸出、錯誤和複製狀態都會自動清除。
為何嚴格的 UTF-8 解碼至關重要
非嚴格解碼器會將每個格式錯誤的位元組替換為 Unicode 替換字元 U+FFFD，這會讓損壞的輸入看起來像是成功解碼的文字，並隱藏您需要調查的關鍵位元組。Hex to Text Converter 使用瀏覽器的 TextDecoder 並設定 fatal: true，因此任何散落的續接位元組、截斷的多位元組序列、過長編碼、編碼過的代理字元，或 U+10FFFF 以上的值，都會使整個解碼失敗且不返回部分輸出。不會悄悄替換任何內容，不會將較早的有效前綴視為成功而返回，也不會丟棄錯誤的後綴。此行為遵循 MDN TextDecoder 參考資料 中關於 fatal 選項的說明，以及 WHATWG 編碼標準中底層的 UTF-8 狀態機。
以下是幾個具體案例，說明為何這很重要：
- ASCII（48 65 6C 6C 6F）解碼為 Hello，是最常見的基準。
- U+00E9（C3 A9）解碼為 é，是最簡單的雙位元組案例。
- 兩個 CJK 字元（例如 E4 B8 AD E5 9B BD）解碼為 中國，屬於三位元組案例。
- 輔助平面表情符號（例如 F0 9F 98 80）解碼為 😀，屬於四位元組案例。
- 獨立的續接位元組（例如 80）、過長編碼（例如 C0 AF）或編碼過的代理字元（例如 ED A0 80），皆會回傳明確的無效序列錯誤，而非返回 U+FFFD。
- 開頭的 BOM（EF BB BF 41）會解碼為 A，因為標準的 TextDecoder 包裝會消耗開頭的位元組順序記號；而同樣的位元組若出現在文字中間（41 EF BB BF 41），則會解碼為兩個 A 之間的可見字元 U+FEFF，且不會被移除。
這些規則符合 WHATWG 編碼標準中 UTF-8 解碼器的規範，以及 RFC 3629 中獨立定義的有效位元組範圍與 U+10FFFF 純量上限。此工具不會猜測 Windows-1252、ISO-8859-1、UTF-16、Shift_JIS 或任何其他舊式編碼，因為靜默猜測可能會改變位元組的意義。如果來源確實屬於上述編碼之一，請將該轉換視為獨立作業，先將位元組預先轉換為 UTF-8 再傳入。
常見錯誤與修正方式
從說明文件、終端機輸出或 API 追蹤記錄複製的十六進位字串，經常包含看似分隔符號但實際上不在接受範圍內的字元。Hex to Text Converter 會以明確的原因拒絕它們，因此修正方式從錯誤訊息本身即可一目了然。
| 輸入 | 結果 | 原因 |
|---|---|---|
| 4 8 | 奇數半位元組錯誤 | 空白無法修補不完整的半位元組 |
| 48,65,6C,6C,6F | 混合語法錯誤 | 逗號不在接受的分隔符號集合內 |
| 48-65-6C-6C-6F | 混合語法錯誤 | 連字號不作為分隔符號使用 |
| 0x410x42 | 混合語法錯誤 | 帶前綴的詞彙必須以啟用的空白分隔 |
| 0x041 | 無效詞彙錯誤 | 帶前綴的詞彙必須剛好為 0xNN，而非三位數 |
| 41 80 | 無效位元組錯誤 | 0x80 是沒有前導位元組的獨立續接位元組 |
| C0 AF | 無效位元組錯誤 | RFC 3629 禁止過長編碼 |
| ED A0 80 | 無效位元組錯誤 | UTF-16 代理字元的一半無法以 UTF-8 編碼 |
對於較長的輸入，最常見的失敗是超出預算上限。原始輸入最多只能包含 2,000,000 個 UTF-16 碼元，解析後的輸出最多只能包含 1,000,000 個位元組，解碼後的文字最多只能包含 1,000,000 個 UTF-16 碼元。前綴表示法每個位元組使用的來源字元數比連續表示法多，因此可能會在達到位元組上限之前就先觸及原始輸入上限；這個順序屬於預期行為，且會被明確回報。如需突破這些限制，請將來源分割成較小的區塊並分別解碼，或在解碼前先從記憶體傾印中僅取出位元組欄位。
When to Use a Different Tool
十六進位是透過純文字通道傳輸非文字位元組的數種方式之一,正確的解碼器取決於來源。若輸入為二進位而非十六進位,請使用 Binary to Text,它接受 8 位元群組或 8 位元二進位字串,並使用同樣的嚴格 UTF-8 規則進行解碼。若為 Base64 傳輸資料,請使用 Base64 Encode and Decode,它將 Base64 視為 RFC 4648 傳輸格式,並產生嚴格的 UTF-8 輸出。對於 UTF-16 位元組串流、Windows-1252 檔案或其他舊式編碼,請先透過可信的工作流程將來源解碼為十六進位,然後再將產生的十六進位位元組傳遞給 Hex to Text Converter。
對於含有位址與 ASCII 欄位的格式化記憶體傾印,必須先在轉換器處理之前擷取出位元組欄位。對於加密、雜湊、簽署,或任何需要金鑰的工作,十六進位轉文字的步驟充其量只是更大流程中的一小部分;若需要具備驗證加密的完整往返流程,請參 AES 工具;若需要摘要驗證,請參閱 SHA-256 與 CRC-32 計算機。十六進位解碼刻意範圍很窄:它只會剖析位元組並解碼 UTF-8,不做其他事。它不會解讀整數字面值、反轉位元組順序、移除空位元、評估跳脫字元,或執行已解碼的文字。
所有剖析、位元組配置、嚴格 UTF-8 解碼、顯示與剪貼簿準備作業,皆在本機目前分頁中執行。不會有任何來源位元組、解碼後的字元或剪貼簿內容離開瀏覽器,因此使用此工具將十六進位轉換為文字時,可放心用於內部日誌、擷取到的 API 回應,以及其他不應上傳至遠端服務的位元組。