用「十六進位轉文字轉換器」取代遠端的 hex to text API 這個瀏覽器工具，可在目前分頁中解析連續、以空白分隔，或逐位元組加上 0xNN 前綴的十六進位資料，並透過 fatal 模式的 UTF-8 解碼器將產生的位元組解碼。這裡不需要儲存 API 金鑰，不需要讀取速率限制標頭，不需要將反向代理伺服器的 URL 視為機密，也不需要將任何內容主體上傳到遠端服務，因此任何裝有現代瀏覽器的機器都能重現這個工作流程。解碼結果是確定性的：格式錯誤的 UTF-8 會回傳明確的錯誤，而不是 U+FFFD 替換字元、截斷的有效前綴，或悄悄被捨棄的尾段。本機解碼器遵循 WHATWG Encoding Standard 與 RFC 3629 的範圍，因此它接受單位元組 ASCII，以及最多到 U+10FFFF 的兩位元組、三位元組和四位元組序列，並拒絕獨立的續接位元組、截斷的多位元組序列、過長編碼、代理碼點，以及任何超出純量上限的值。對於從日誌、API 負載或逆向工程輸出中複製十六進位字串的開發者來說，這種明確的通過或失敗行為，正是捨棄遠端 API、改為在本機執行解碼的原因。
為什麼開發者要尋找十六進位轉文字 API 的替代方案
遠端的 hex to text API 原則上能解決問題 —— POST 十六進位資料、取得文字 —— 但實際工作流程的成本比看起來高。每次呼叫都需要 API 金鑰、基底 URL、認證標頭，以及包裹請求與回應的 JSON 封包。即使是一個小型的包裝腳本，也必須處理重試、逾時與配額錯誤；而沙箱環境往往完全無法連到該端點。
更嚴重的問題是隱私。許多團隊解碼的日誌中包含權杖、客戶識別碼、內部 IP 或部分負載，這些資料他們並不想傳送給第三方。瀏覽器端的轉換器會將十六進位的位元組、解析後的輸出、解碼後的文字，以及剪貼簿寫入動作，全部保留在目前分頁內 —— 在你自行貼到其他位置之前，什麼都不會外洩。
確定性是第三個問題。典型的遠端端點使用寬鬆的解碼器：遇到孤立的續接位元組或截斷的多位元組序列時，會以 U+FFFD 取代，呼叫端收到一個看起來正常的字串，直到下游程式碼將它與預期的雜湊值比對，或將它當作 JSON 解析時才會發現問題。嚴格的本機解碼器要嘛以完全相同的位元組序列成功解碼，要嘛以明確的錯誤失敗，這通常才是開發者真正想要的訊號。
本機十六進位解碼器內部
十六進位轉文字轉換器 以 WHATWG Encoding Standard 與 RFC 3629 為建構核心，這兩份規格定義了如何將位元組轉成 Unicode 純量。它接受三種輸入形式：
- 連續且長度為偶數的群組，例如 48656c6c6f，其中每兩個十六進位數字構成一個位元組。
- 以 ASCII 空白分隔的群組，例如 48 65 6c 6c 6f，必須在啟用 ASCII 分隔符支援時才會生效。
- 逐位元組加上前綴的詞元，例如 0x48 0x65 0x6c 0x6c 0x6f，其中每個詞元都必須剛好是 0xNN，且解析器禁止混用有前綴與無前綴的詞元。
解析完成後，位元組陣列會交給瀏覽器的 TextDecoder，並設定 fatal: true，因此任何格式錯誤的 UTF-8 序列都會中止整個解碼程序，而不是產生替換字元。解碼結果會顯示在一個唯讀欄位中，附上位元組計數；若瀏覽器授予剪貼簿存取權限，解碼後的文字也能被複製。可接受的語法刻意比任意的程式設計師表示式更為嚴格，這正是嚴格驗證得以實現的原因。
如何使用本機工具將十六進位轉為文字
- 將十六進位位元組貼到輸入欄位。例如 48656c6c6f 這種連續配對、48 65 6c 6c 6f 這種以空白分隔的群組，或 0x48 0x65 0x6c 0x6c 0x6f 這種逐位元組加上前綴的詞元，全部都能正常運作。請依據來源選擇「ASCII 分隔符」與「0x 前綴」選項。
- 執行解碼。工具會先檢查 2,000,000 個字碼單位的原始輸入預算，接著解析位元組，再檢查 1,000,000 位元組的輸出預算，然後將陣列交給 fatal 模式的 TextDecoder 進行 UTF-8 解碼。
- 讀取或修正結果。成功時，解碼後的文字與位元組計數會出現在唯讀欄位中。失敗時，錯誤訊息會明確指出問題 —— 奇數的半位元組、混用的語法、無效的位元組序列，或預算超支。
- 複製文字。若已授予剪貼簿存取權限，請點擊複製按鈕。只有在解碼後的文字沒有任何字碼單位時，按鈕才會停用；若權限授予失敗，文字仍可選取，讓你手動複製。
解析器接受的十六進位語法
解析器會依據輸入本身區分兩種模式。如果輸入含有任何不區分大小寫的 0x 前綴，則每個詞元都必須剛好是 0xNN，且輸入會被視為前綴模式。否則，解析器會以純模式執行，並套用所設定的空白規則。
| 格式 | 範例 | 規則 |
|---|---|---|
| 連續 | 48656c6c6f | 純模式，僅接受偶數個十六進位數字 |
| 以 ASCII 空白分隔 | 48 65 6c 6c 6f | 當分隔符選項啟用時，可使用空格、Tab、LF、FF、CR |
| 0xNN 前綴詞元 | 0x48 0x65 0x6c 0x6c 0x6f | 每個詞元必須剛好是 0xNN，混用形式會被拒絕 |
| 大寫或小寫數字 | 48656C6C6F 或 48656c6c6f | 兩者會產生相同的位元組值 |
幾種常見的形式會被刻意拒絕：4 8 無法靠加入分隔符修復為 48；0x410x42 無法在沒有空白的情況下分割；三位數的詞元（例如 0x041）過長；單獨的 0x 不是有效的位元組。不換行空格及其他 Unicode 間隔字元也會被拒絕，因此貼上的十六進位字串絕不會被套用任何隱形的正規化。
有一個具體的對應值得一看。十六進位配對 0x48 等於十進位的 72，也就是 ASCII 中的字元 H。逐一讀取 48656c6c6f 的位元組會得到 72、101、108、108、111，拼起來就是 Hello。
Fatal UTF-8 驗證及其帶來的改變
寬鬆解碼器與本工具所使用之嚴格解碼器的決定性差異，在於處理格式錯誤序列的方式。在寬鬆模式下，瀏覽器的 TextDecoder 會為每個受損的位元組插入 U+FFFD，並繼續執行。這會讓損壞的輸入看起來像成功的文字，隱藏了真正的問題 —— 毀損的日誌、錯誤的位元組順序，或位移了一個位元組的偏移量。
十六進位轉文字轉換器使用 fatal: true 的 TextDecoder，因此一旦遇到以下任何一種情況，整個解碼就會失敗：
- 獨立的續接位元組（落在 0x80–0xBF 範圍、卻沒有引導位元組的位元組）。
- 截斷的多位元組序列，例如三位元組字元只有前兩個位元組而沒有第三個。
- 過長編碼，例如歷史上用兩個位元組表示斜線字元的 C0 AF 形式。
- 以 UTF-8 編碼的代理碼點，這在 Unicode 標準中是禁止的。
- 超過 U+10FFFF 的四位元組值，超越了 RFC 3629 所定義的純量上限。
此工具亦遵循位元組順序標記的標準包裝行為。前導的 EF BB BF 會被消耗掉，因為 ignoreBOM 維持在預設值 false，所以 EF BB BF 41 會解碼為 A。同樣的三個位元組若出現在字串中間，則會解碼為真正的 U+FEFF 字元，不會被悄悄移除。位元組 00 會被視為普通的 UTF-8 資料並產生 U+0000，而不是 C 風格的字串結束符。這些規則都不是經驗法則 —— 它們是 WHATWG Encoding Standard 為瀏覽器內建解碼器所做出的明確選擇，而嚴格的本機工具會保留這些規則，而不是在使用者不知情的情況下放寬它們。如果你想深入了解為何靜默替換是危險的，請參閱 《如何在不出現靜默錯誤的情況下將十六進位字串轉換為文字》 一文中的逐步說明。
限制、預算與邊界情況下的行為
三項獨立的預算保護解碼程序，避免因失控的輸入鎖死瀏覽器分頁。每個限制都是硬性上限：剛好等於上限值會被接受，超過一個單位則會被拒絕，並附上「未解碼、未回傳、未截斷」的相關說明。
| 預算 | 最大值 | 邊界情況下的行為 |
|---|---|---|
| 原始輸入 | 2,000,000 個 UTF-16 字碼單位 | 在解析前進行檢查，超過的輸入會被拒絕 |
| 解析後的位元組 | 1,000,000 位元組 | 在配置 Uint8Array 之前計算 |
| 解碼後的文字 | 1,000,000 個 UTF-16 字碼單位 | 在 fatal 解碼後進行驗證 |
解析器絕不會對過大的來源進行切片、絕不會忽略多出的完整位元組、絕不會抽樣文字，也不會悄悄為數字設定上限。前綴標記法的每個位元組含有較多的來源字元，因此可能比位元組預算更早達到原始輸入預算 —— 這是預期中的情況，會回報為原始輸入錯誤，而非解析後位元組錯誤。編輯十六進位輸入、變更任一語法選項，或開始新的解碼時，都會立即清除先前的輸出、錯誤、已複製狀態與複製計時器，因此過時的結果不會跨越不同嘗試殘留下來。
什麼時候這不是合適的工具
十六進位轉文字轉換器的範圍刻意限定在以 UTF-8 解碼的十六進位位元組標記法。它不會猜測 Windows-1252、ISO-8859-1、UTF-16 或 Shift_JIS，因為靜默猜測可能改變位元組的意義。它不會解讀整數字面值、反轉位元組順序、去除空字元、求值跳脫序列、解析帶位址的十六進位傾印、解密資料，或執行解碼後的文字。對於格式化的記憶體傾印，請使用合適且可信的工作流程先擷取其位元組欄位，再進行貼上。
若是二進位而非十六進位的輸入，二進位轉文字 工具以相同的 fatal 模式驗證支援 8 位元二進位位元組。若是 Base64 傳輸資料，Base64 編碼與解碼 工具可處理帶填補的標準格式。若要做反向操作，文字轉十六進位 可將 UTF-8 文字編碼為連續、帶空白或 0x 前綴的十六進位，並對無效的純量值顯示明確的替換警告。