將十六進位字串轉換成文字,意味著將每一對十六進位數字視為一個位元組,並將這個完整的位元組序列解碼為 UTF-8,在位元組無法構成有效編碼時,回傳明確的錯誤,而不是靜默地替換為替代字元。十六進位字串「48656c6c6f」中的兩位數字「48」是 'H' 的 ASCII 碼,接下來的兩位數字「65」對應到 'e',依此類推,直到整個字串解碼為「Hello」。其中的訣竅在於,從十六進位解析到字元解碼的每一步都必須嚴格:奇數個十六進位數字、多餘的分隔符、沒有前導位元組的 UTF-8 連續位元組,或是編碼為 Unicode 範圍之外數值的位元組序列,都可能讓看似成功的解碼變成損壞的文字。因此,值得信賴的轉換器拒絕猜測、拒絕輸出「有效前綴」,也拒絕在垃圾位元組的位置插入 U+FFFD。
這個 十六進位轉文字轉換器正是這樣運作的。您貼上一段十六進位字串,工具會根據明確的分隔符與 0x 前綴規則進行解析,接著將產生的位元組透過瀏覽器的 TextDecoder('utf-8', { fatal: true }) 進行解碼。每個階段都在當前分頁中於本機執行;十六進位資料、位元組或解碼後的文字,都不會離開瀏覽器。
解碼器接受的十六進位字串格式
解析器能識別同一底層位元組的三種具體表面形式。純粹群組僅包含十六進位數字 0–9、A–F 或 a–f,每個群組的數字數量為偶數。當啟用 ASCII 空白字元時,群組之間唯一允許的分隔符是 ASCII 空白字元、水平定位字元、換行字元、換頁字元與歸位字元;其他的 Unicode 空白字元(例如不中斷空白)則會被拒絕。連續輸入只是單一不帶分隔符的純粹群組。帶前綴模式要求每個以空白分隔的標記都必須完全符合 0xNN,其中 NN 為一個位元組。純粹與帶前綴的形式不能同時出現在同一段輸入中,因此 0x41 42 會直接失敗,而不是被靜默地重新解析。
| 表示法 | 輸入範例 | 必要選項 | 解碼結果 |
|---|---|---|---|
| 偶數長度的連續群組 | 48656c6c6f | 關閉空白、關閉前綴 | Hello |
| 以空白分隔的群組 | 48 65 6c 6c 6f | 開啟空白、關閉前綴 | Hello |
| 帶 0x 前綴的逐位元組標記 | 0x48 0x65 0x6c 0x6c 0x6f | 開啟前綴、開啟空白 | Hello |
| 多位元組的純粹群組 | c3a9 | 空白開啟或關閉皆可 | é (U+00E9) |
關閉前綴會直接拒絕帶前綴的輸入,而不是在使用者背後悄悄移除 0x;關閉空白則會拒絕所有 ASCII 空白字元,而不是靜默地將其修剪掉。大寫與小寫的十六進位數字會產生相同的位元組值,因此 48656C6C6F 與 48656c6c6f 是等價的。
逐步將十六進位字串轉換為文字
下列流程會透過十六進位轉文字轉換器,從貼上原始十六進位數字開始,一路完成到複製解碼後的文字。
- 貼上十六進位字串。將數字放入輸入欄位。例如,貼上 48 65 6c 6c 6f 以使用以空白分隔的形式、貼上 48656c6c6f 以使用連續形式,或貼上 0x48 0x65 0x6c 0x6c 0x6f 以使用帶前綴的形式。編輯輸入會立即清除先前的輸出、錯誤或複製狀態。
- 選擇 ASCII 空白選項。若您的輸入是以空白、定位字元或換行分隔位元組群組,請啟用此選項;若為單一連續的十六進位字串,請將其關閉。此切換僅接受先前列出的五個 ASCII 空白字元。
- 選擇 0x 前綴選項。只有在輸入中的每個標記都剛好是 0xNN 時,才啟用此選項。對於純粹十六進位,請將其關閉,並且絕對不要在同一段貼上的內容中混用兩種形式。
- 執行解碼。工具首先會檢查輸入最多為 2,000,000 個 UTF-16 字碼單元。接著若出現任何 0x,則會偵測為帶前綴模式,並解析每個群組,計算產生的位元組數量,然後在配置任何型別陣列之前,將該數量與 1,000,000 位元組的解析預算進行驗證。
- 檢查輸出或錯誤。完整的位元組陣列會透過 new TextDecoder('utf-8', { fatal: true }) 進行解碼。成功時,唯讀的輸出欄位會顯示解碼後的文字以及位元組數量。失敗時,該欄位會顯示明確的錯誤:奇數半位元組、混用語法、無效的位元組序列或超出預算,並且不會回傳任何部分結果。
- 複製解碼後的文字。點擊複製按鈕。此動作為非同步,並由一個世代號碼保護,因此較晚才取得的權限成功或失敗,無法覆寫較新的複製內容或已經已移開的介面。若瀏覽器拒絕存取剪貼簿,解碼後的文字仍可選取,且工具會提示您手動複製。
嚴格 UTF-8 驗證與靜默替換的危險性
許多線上解碼器會以預設的 fatal: false 呼叫 TextDecoder。該預設值會在遇到格式不正確的位元組序列時,插入 Unicode 替代字元 U+FFFD,並且即使後續位元組已損壞,仍允許解碼器回傳輸入的「有效前綴」。舉例來說,十六進位字串 C3 28 會輸出 Unicode 替代字元 U+FFFD,接著再輸出「(」,而不是拒絕解碼,這會在沒有任何可見警告的情況下,悄悄地損壞日誌行、編碼後的組態值或傳輸的酬載資料。
嚴格模式會改變這種行為:下列任何一種情況都會讓整個解碼失敗,不會產生部分輸出,也不會出現替代字元。
- 獨立出現的連續位元組(例如 80),沒有有效的對應前導位元組。
- 被截斷的多位元組序列,例如三個位元組的前導 E2 80 卻沒有第三個位元組。
- 過長的編碼(overlong encoding),這在 RFC 3629 的範圍中已明確禁止。
- 編碼為 UTF-16 代理碼點的位元組序列,其在 UTF-8 中沒有對應形式。
- 超過 Unicode 純量上限 U+10FFFF 的四位元組數值。
- 不完整的位元組順序標記,例如 EF BB 卻沒有尾隨的 BF。
解碼器同時遵循標準包裝器的預設 BOM 行為:前導的 EF BB BF 會被消耗,不會產生任何可見字元;同樣這三個位元組若出現在文字中間,則會解碼為字面上的 U+FEFF 並加以保留。因此,單獨的 BOM 是合法的空解碼,介面會回報這個結果,而不是假裝什麼事都沒發生。底層演算法定義於 WHATWG 編碼標準中,有效的序列範圍可在 RFC 3629 中交叉參照,而建構函式的選項則記載於 MDN。
常見的十六進位字串錯誤及其含義
大多數解碼失敗都屬於少數幾種定義明確的類別。辨識工具所回報的精確措辭,能讓後續修正更為迅速。
| 輸入樣式 | 回報的錯誤 | 失敗原因 |
|---|---|---|
| 4 8 | 群組中含有奇數個半位元組 | 空白分隔符無法修復不完整的位元組。 |
| 0x41 42 | 混用純粹與帶前綴語法 | 純粹與 0xNN 形式不能同時出現在同一段輸入中。 |
| 48,65,6c | 不支援的分隔符 | 僅接受 ASCII HT、LF、FF、CR 以及空白作為分隔符。 |
| C0 AF | 無效的 UTF-8 序列 | RFC 3629 禁止對 / 進行過長編碼。 |
| ED A0 80 | 無效的 UTF-8 序列 | UTF-16 代理碼點在 UTF-8 中沒有對應形式。 |
| 0x041 | 格式不正確的 0x 標記 | 帶前綴的標記必須剛好為 0xNN,代表一個位元組。 |
| 輸入超過 2,000,000 字碼單元 | 原始輸入預算超出 | 不會進行解碼、切片、取樣或截斷。 |
預算規則彼此獨立且明確。2,000,000 字碼單元的原始上限保護解析器;1,000,000 位元組的解析上限保護型別陣列;1,000,000 字碼單元的解碼上限保護輸出欄位。帶前綴的表示法每個位元組使用的來源字元比純粹十六進位多,因此一段帶前綴的酬載可能會先於位元組上限觸及原始上限;這是預期中的情況,錯誤訊息會明確指出被超過的具體上限。
十六進位字串與其他位元組表示法的比較
十六進位是您在閱讀日誌、API 回應或擷取檔案時可能遇到的數種常見位元組表示法之一。該工具刻意將範圍設定得很窄:它僅解碼 UTF-8,並且在 UTF-8 解碼失敗時,不會嘗試猜測 Windows-1252、ISO-8859-1、UTF-16 或 Shift_JIS。靜默猜測正是嚴格解碼器存在所要避免的失敗模式。
若您的酬載已包裝為 Base64 以利傳輸,請先透過 Base64 編碼 / 解碼 工具處理;接著您貼到十六進位解碼器中的位元組,才是實際的位元組序列,而不是傳輸編碼。若輸入為原始二進位而非十六進位,請改用 二進位轉文字。若是反向操作——以相同的本機處理模型將文字編碼為精確的 UTF-8 十六進位——請參閱文字轉十六進位:以正確方式編碼 UTF-8 字串指南。
最後提供兩點實用提醒以收尾。第一,位元組 00 是有效的 UTF-8 資料,會解碼為 U+0000;它不會被視為 C 風格字串的結束符,因此含有真正 NUL 的酬載可以完整往返。第二,解碼欄位為唯讀;變更會發生在輸入框、分隔符切換或前綴切換中,每一次互動都會在下一次操作時清除先前的輸出、錯誤與複製狀態。
若想深入了解,請參閱 A1Z26 密碼解碼器:以明確錯誤解碼數字。