十六進位文字編碼將 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 的字母。一個位元組佔 8 個位元，因此一個位元組可以寫成剛好兩個十六進位數字：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 前綴則是無操作（no-op），若來源實際上為混合標記，可能會讓您感到意外。
- 執行解碼。該工具首先檢查 2,000,000 字元的原始輸入預算，然後在配置位元組陣列之前，依據 1,000,000 位元組的輸出預算驗證解析後的位元組數量，最後使用嚴格的 UTF-8 驗證解碼完整的陣列。
- 在唯讀輸出欄位中讀取解碼後的文字。位元組計數會與文字並排顯示，以便您確認來源長度除以二（若是前綴輸入，則除以較大的每個位元組的額外負荷）後的結果與解碼後的位元組數量相符。
- 若您的瀏覽器在安全情境下授予剪貼簿存取權限，請使用複製按鈕複製解碼後的文字。僅當解碼後的文字沒有任何碼位時，該按鈕才會停用，且即使權限請求失敗，文字仍可選取以便手動複製。
如果解碼失敗，介面會報告一個具體原因，而不是進行猜測。奇數長度的數字群組會產生 odd-nibble 錯誤，逗號或其他非 ASCII 分隔符會產生 mixed-syntax 錯誤，獨立的延續位元組或截斷的多位元組序列會產生 invalid-byte 錯誤，而預算溢位則會產生 budget 錯誤。請修正所指出的問題並重新執行；每次編輯時，先前的輸出、錯誤與複製狀態都會自動清除。
為何嚴格 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 | Odd nibble 錯誤 | 空白無法修復不完整的半位元組 |
| 48,65,6C,6C,6F | Mixed syntax 錯誤 | 逗號不在接受的分隔符集合中 |
| 48-65-6C-6C-6F | Mixed syntax 錯誤 | 連字號不接受作為分隔符 |
| 0x410x42 | Mixed syntax 錯誤 | 帶前綴的語彙基元必須由啟用的空白分隔 |
| 0x041 | Invalid token 錯誤 | 帶前綴的語彙基元必須剛好為 0xNN，而非三位數 |
| 41 80 | Invalid byte 錯誤 | 0x80 是沒有前導位元組的獨立延續位元組 |
| C0 AF | Invalid byte 錯誤 | RFC 3629 禁止過長編碼 |
| ED A0 80 | Invalid byte 錯誤 | UTF-16 代理項的一半無法以 UTF-8 編碼 |
對於較長的輸入而言，最常見的失敗是預算溢位。原始輸入最多可包含 2,000,000 個 UTF-16 碼位，解析後的輸出最多可包含 1,000,000 個位元組，而解碼後的文字最多可包含 1,000,000 個 UTF-16 碼位。前綴標記法每個位元組使用的來源字元多於連續標記法，因此可能在達到位元組預算之前就先觸及原始輸入預算；這種順序是預期中的情況，且會明確報告。若需要超出這些上限，請將來源分割成較小的區塊並分別解碼，或在解碼前僅擷取記憶體傾印的位元組欄位。
When to Use a Different Tool
Hexadecimal is one of several ways to transport non-text bytes through text-only channels, and the right decoder depends on the source. For binary rather than hexadecimal input, use Binary to Text, which accepts 8-bit groups or 8-bit binary strings and decodes them with the same fatal UTF-8 rules. For Base64 transport data, use Base64 Encode and Decode, which treats Base64 as RFC 4648 transport and produces strict UTF-8 output. For UTF-16 byte streams, Windows-1252 files, or other legacy encodings, decode the source into hexadecimal first with a trusted workflow and only then pass the resulting hex bytes to the Hex to Text Converter.
For formatted memory dumps with addresses and ASCII columns, the byte column has to be extracted before the converter sees it. For encryption, hashing, signing, or any task that needs a key, the hex-to-text step is at best a small piece of a larger process; for a complete round trip with authenticated encryption, see the AES tool, and for digest verification, see the SHA-256 and CRC-32 calculators. Hex decoding is intentionally narrow: it parses bytes and decodes UTF-8, nothing more. It does not interpret integer literals, reverse byte order, remove nulls, evaluate escapes, or execute decoded text.
All parsing, byte allocation, fatal UTF-8 decoding, display, and clipboard preparation happen locally in the current tab. No source bytes, decoded characters, or clipboard content leave the browser, so converting hex to text with this tool is safe to run on internal logs, captured API responses, and other bytes that should not be uploaded to a remote service.
Related reading: Text Steganography Command Line vs Online Compared.