十六進位格式只是將位元組以 0–9 與 A–F 的字元配對來表示的一種方式,因此將十六進位格式轉換為文字,就是將這些配對讀成位元組,再用 UTF-8 標準解碼該位元組序列。實際上,這讓你可以把像 48656c6c6f 這樣的內容轉成 ASCII 字串 Hello,或是將多位元組序列 C3 A9 解碼為單一字元 é。這個轉換分為兩個階段:一個嚴格的語法解析器,用來判斷哪些字元配對算是一個位元組;以及一個 UTF-8 解碼器,把每個有效的位元組序列轉成 Unicode 純量。各工具在處理這兩個階段的嚴格程度上有所不同 — 許多工具會在位元組格式錯誤時悄悄以 U+FFFD 替代,這可能會隱藏真實的損毀。瀏覽器式的做法是在當前的分頁中執行這兩個階段,只解析語法規則允許的內容,並在任何位元組無效時完全不回傳文字。這會產生一個明確、可信任的結果,因為一旦解碼成功,就代表每個位元組都是有效的,而你看到的每個字元確實來自那些位元組。
十六進位格式如何解碼為文字
磁碟上或記憶體中的每個位元組都是 8 個位元,把每個位元組寫成兩個十六進位字元,就會得到一串由 0 到 F 之間的數字和字母組成的字串。因此,將十六進位格式轉換為文字,就是將這些字元兩個一組讀回以重建原始位元組,再用字元編碼去解讀該位元組序列,使其變得可讀。UTF-8 是網路、現代作業系統上大多數檔案,以及瀏覽器內建 TextDecoder 所使用的編碼,這也是為什麼每個可靠的十六進位轉文字工具最終都會呼叫 UTF-8。
挑戰在於,十六進位格式並不是單一固定的東西。同樣的內容可能以連續字串、以空格分隔的位元組,或是每個位元組加上明確 0x 前綴的形式出現。一個值得信賴的工具會清楚說明它接受哪些形式,並拒絕其餘的,而不是在背後悄悄改寫你的輸入。對應的工具 Text to Hex 則執行反向作業,使用相同的 UTF-8 慣例將任何 Unicode 字串編碼回十六進位位元組,因此這兩個頁面共用相同的解析與解碼規則。
可接受的十六進位語法及其拒絕情況
Hex to Text Converter 所採用的嚴格做法,將語法解析與位元組解碼分開,並套用三條明確的規則。在下表中,每個輸入都是純 ASCII 十六進位,其中大寫和小寫數字會產生相同的位元組值,而逗號、破折號、冒號、方括號、跳脫字元、註解以及單位標籤一律視為錯誤。
| 格式 | 範例 | 接受條件 | 拒絕的範例 |
|---|---|---|---|
| 連續配對字串 | 48656c6c6f | 純模式,不需要分隔符 | 48656c6c6 (奇數個 nibble) |
| 以空白分隔 | 48 65 6c 6c 6f | 啟用空白切換;允許 ASCII 空格、Tab、LF、FF、CR | 48,65 (拒絕逗號) |
| 每個位元組 0xNN | 0x48 0x65 0x6c 0x6c 0x6f | 啟用前綴切換;每個標記恰好為 0xNN | 0x48 42 (混合形式) |
| 裸 0x 或三位數標記 | 0x, 0x041 | 永不接受 | 一律視為錯誤 |
有幾個細節對真實資料很重要。ASCII 空白的支援範圍經過精確定義:只接受空格、水平 Tab、換行 (LF)、換頁 (FF) 與歸位字元 (CR);而非斷行空格或任何其他 Unicode 空白字元則會被拒絕。純模式與前綴模式不能混用,因此即使 0x41 與 42 兩部分各自有效,0x41 42 仍會失敗。分隔符無法修復不完整的 nibble,因此 4 8 會被拒絕,而不是悄悄變成 48。在預算檢查之前,原始輸入絕不會被修剪或重寫,但在有效內容周圍,所啟用的前置或後置 ASCII 空白會被視為分隔而被接受;只有空白的輸入仍然視為錯誤。關閉 0x 前綴切換會拒絕帶前綴的輸入,而不是在使用者不知情的情況下移除前綴。
三個步驟將十六進位格式轉換為文字
依下列順序使用 Hex to Text Converter,即可將任何可接受的十六進位字串轉成 UTF-8 文字,而不會出現悄悄發生的意外。
- 將你的十六進位輸入貼上,可以是偶數長度的連續分組、以 ASCII 空白分隔的分組,或是精確的 0xNN 位元組標記,然後啟用或停用 ASCII 分隔符與 0x 前綴切換,讓解析器知道該預期哪種語法。
- 使用嚴格的 UTF-8 驗證解碼已解析的位元組陣列。如果工具回報奇數 nibble、語法混用、無效的位元組序列,或預算錯誤,請依它指出的具體問題修正並重新執行解碼,而不是去猜測原本的位元組。
- 檢視唯讀的文字欄位和顯示的位元組數,然後複製結果。複製按鈕只有在解碼器回傳非空文字時才會啟用,而瀏覽器會在寫入解碼後的字元之前要求剪貼簿權限。
作為一個具體的完整範例,é 的雙位元組 UTF-8 序列在十六進位中為 C3 A9。在啟用正確切換的情況下,貼上 C3A9、C3 A9 或 0xC3 0xA9 任一種,工具都會回傳單一字元 é。在其後加上 ASCII 位元組 41 會得到 éA,因為 41 解碼為 U+0041 A。若將同樣的三個位元組組合成 41 C3 A9,則會得到 Aé,因為 UTF-8 序列可以出現在位元組串流中的任何位置,不需對齊字邊界。位元組 00 也是有效的 UTF-8 資料,會成為 U+0000,因此工具絕不會將它視為 C 風格字串的結束符號。
為什麼嚴格 UTF-8 解碼優於替換字元
十六進位解碼器中最常見的悄悄失敗,就是出現替換字元。JavaScript 預設的 TextDecoder 與許多函式庫一樣,只要看到孤立的續接位元組、截斷的多位元組序列、過長的編碼、被編碼的代理碼點,或超過 U+10FFFF 的值,就會插入 U+FFFD。這種行為會讓損壞的輸入看起來像成功的文字,隱藏真實的損毀,並產生字元數與來源位元組數不一致的字串,而這正是嚴格解碼所要避免的混淆。
Hex to Text Converter 則改用帶有 fatal: true 選項的 TextDecoder,因此任何格式錯誤的序列都會讓整個解碼失敗,介面只會回報沒有任何部分輸出。這些嚴格規則依循 WHATWG Encoding Standard 中的解碼器邏輯,以及 RFC 3629 中的純量上限,兩者共同定義了哪些算是一開始就有效的位元組序列。前導的 UTF-8 位元組順序標記 EF BB BF 會被標準的 TextDecoder 包裝器消耗掉,因為 ignoreBOM 維持其預設值 false,所以輸入開頭的這個特定三元組會從輸出中消失。同樣的 U+FEFF 序列若出現在文字中間,則會被保留為可見字元,因為它已不再是 BOM 位置。MDN TextDecoder 參考資料記載了這個包裝器的行為,而多位元組序列的有效範圍以及 U+10FFFF 上界則來自 RFC 3629。
位元組預算、空白規則與錯誤訊息
三個獨立的限制讓轉換作業在瀏覽器中保持安全。原始輸入在開始解析前最多只能是 2,000,000 個 UTF-16 碼點。解析完成後,輸出最多只能包含 1,000,000 個位元組,這項檢查會在配置 Uint8Array 之前執行。解碼後,產生的文字最多只能包含 1,000,000 個 UTF-16 碼點。恰好等於上限的值會被接受,只要超出上限一個單位,就會以「沒有解碼任何內容、沒有回傳、沒有截斷」之類的用語拒絕,絕不會悄悄截斷。
| 預算 | 上限 | 檢查時機 |
|---|---|---|
| 原始輸入碼點 | 2,000,000 | 在任何解析之前 |
| 解析後輸出位元組 | 1,000,000 | 解析後、配置 Uint8Array 之前 |
| 解碼後文字碼點 | 1,000,000 | 在嚴格 UTF-8 解碼之後 |
編輯十六進位輸入、切換任一語法選項,或開始新的解碼,都會立即清除先前的結果、錯誤訊息、複製狀態與複製計時器,因此介面絕不會顯示過期的文字。剪貼簿寫入是非同步的,因此每次複製嘗試都帶有世代編號,以防止延遲到達的權限回呼在輸入已變更後更新畫面。如果瀏覽器拒絕剪貼簿存取,有效的解碼文字仍可被選取,讓使用者手動複製。整個處理流程都在本機進行:沒有任何來源位元組、解碼後的字元或剪貼簿內容會被上傳到任何地方,這在內容可能是權杖、金鑰或私人訊息時特別重要。
何時該使用其他編碼工具
十六進位只是一種傳輸格式,嚴格的 UTF-8 解碼器只能解決其中一個相關問題。當輸入已經是十六進位位元組時,請使用 Hex to Text Converter。當輸入是 0 與 1 的 8 位元二進位字串時,請使用 Binary to Text。當傳輸層是 Base64 時,請使用 Base64 Encode / Decode;當你需要在小寫十六進位與 Base64 之間互通而不經過文字時,請使用 Base64 to Hex。當輸入已經是你可以讀成字元、而非視為數字代碼的原始位元組文字時,請使用 UTF-8 Encoder / Decoder。
這個工具刻意不去嘗試解碼 Windows-1252、ISO-8859-1、UTF-16、Shift_JIS 或任何其他舊式編碼。悄悄猜測會改變位元組的意義,而這正是嚴格解碼所要避免的問題。對於左側帶有位址、右側帶有 ASCII 欄位的格式化記憶體傾印,請先以值得信賴的工作流程只擷取位元組欄,然後再把清理過的位元組貼到轉換器中。十六進位也不是加密:如果位元組是經過加密的,本工具只會呈現該密文的 UTF-8 解讀結果,而不是原本的明文,因此像是 AES Encryption Online 這類工具才是反轉加密步驟的正確選擇。它也不會解讀整數字面值、反轉位元組順序、移除 null 位元組、求值跳脫字元、解密資料、解析帶位址的十六進位傾印,或執行解碼後的文字。
想深入了解,請參閱 HMAC-SHA256 標籤產生器:十六進位與 Base64 指南。
想深入了解,請參閱 將摩斯密碼翻譯為英文:實用工作流程。