為何 Excel 在處理十六進位字串時只能到十進位為止
Excel 的 HEX2DEC 函式會將十六進位輸入轉為十進位數字，因此儲存格中的 48 會回傳 72，而不是 ASCII 字母 H。這個事實正是直接在 Excel 中進行十六進位到文字轉換時通常會失敗的核心原因。HEX2DEC 是針對個別數值運作，而非針對位元組序列，輸入上限為 10 個十六進位數字，並回傳一個 base-10 整數。它沒有對應的 HEX2TXT 或 HEX2UTF8，無法識別多位元組 UTF-8 編碼，也沒有將兩個十六進位數字配對成一個位元組，再將該位元組對應到字元的概念。任何想要把像 48656c6c6f 這樣的字串解讀為 Hello 的人，都必須在試算表中自行設計一條流程，而這條流程幾乎總是在遇到第一個非 ASCII 字元時就壞掉。常見的土法煉鋼做法是對每個位元組執行 HEX2DEC、對每個十進位執行 CHAR，再用 CONCAT 或 & 把字母串接起來。對於純 ASCII 而言這條流程可以運作，因為每個位元組都低於 128，能乾淨地對應到一個碼位，但只要有位元組超過 127，流程就會崩潰，因為 Excel 沒有內建方法能把這些位元組進 CHAR 並還原出有效的 UTF-8 序列。這正是當資料離開試算表後，以獨立瀏覽器為基礎的 UTF-8 十六進位解碼器所要補上的實際落差。
HEX2DEC 對輸入長度的限制眾所皆知:超過 10 個十六進位數字就會回傳錯誤，而且該函式回傳的 base-10 整數沒有位元組邊界的概念。CHAR 函式接受 1 到 255 的數字，並將其轉為對應的單位元組字元，但它不會把這些字元解讀為多位元組 UTF-8 序列的一部分。因此自製的 Excel 解碼器可以還原 ASCII 文字和零散的 Latin-1 字元，但若不從頭重建編碼器，就無法還原 é、€、你 或 😊。這些落差正是以瀏覽器為基礎的 Hex to Text Converter 所要補上的地方，它採用嚴格且具備 UTF-8 感知能力的解碼器，在本機處理你從 Excel 複製出來的任何十六進位資料。
如何將十六進位資料從 Excel 取出以便瀏覽器解碼
第一個實際問題是如何把十六進位資料從 Excel 儲存格移轉到工具的輸入欄位。三種模式幾乎涵蓋你會遇到的所有試算表。
模式一是「一格一個位元組」:一欄由兩個字元組成的十六進位字串，例如 48、65、6c、6c、6f。選取範圍後複製，再貼到工具中。在啟用空白字元分隔符的純文字模式下，工具會將其視為五個等長、以 ASCII 空白分隔的十六進位群組。模式二是「一格多個位元組」:單一儲存格中包含 48656c6c6f。這與模式一是同一筆資料，只是串接在一起。工具會將它視為一組連續的等長群組來接受，因為每個群組只需要只包含十六進位數字且數字總數為偶數。模式三是「一格、程式碼風格的 token」:儲存格中包含 0x48 0x65 0x6c 0x6c 0x6f，這是許多程式語言和資料庫用戶端匯出二進位常值的方式。在啟用前綴的情況下，工具的 prefixed 模式會接受這種格式，因為該選項強制採用精確的 0xNN token 形狀。
Excel 的「文字剖析」精靈可以依據地區設定，以逗號、空格、定位字號、分號或直立線符號來分隔第二與第三種模式。若不需要這種分隔，就不要執行它;請將儲存格內容以單一字串複製，然後直接貼到工具中。如果某個十六進位值在 Excel 中帶有前導單引號(試算表用來強制文字格式的手法)，那個單引號並不是字串的一部分，Excel 在複製時會自動去除，因此你不需要再手動去除。你真正需要去除的是 Excel 在把看起來像十六進位的字串解讀為公式時自動加上的前導等號;工具會拒絕任何不是十六進位數字、未啟用的分隔符，或未啟用的 0x 前綴的字元。
如何使用瀏覽器工具將十六進位轉換為文字
- 在你用於試算表的同一個瀏器分頁中開啟 Hex to Text Converter。頁面載入時，兩種語法選項都使用預設值:允許 ASCII 空白字元、允許 0x 前綴。
- 將十六進位貼到輸入欄位。若你的 Excel 儲存格內容是 48656c6c6f，就原樣貼上。若儲存格內容是 48,65,6c,6c,6f，可以先用逗號執行「文字剖析」後再貼上合併結果，或自行將逗號刪除;剖析器只會把已啟用的 ASCII 空白當作分隔符，逗號會直接被拒絕。
- 確認語法選項。除非你的十六進位完全沒有分隔符而且你想禁止任何夾雜的分隔符，否則請保持啟用 ASCII 空白。除非你的 token 完全不以 0x 開頭，否則請保持啟用前綴;若完全不以 0x 開頭，則停用前綴可在你不小心寫入 0x 時直接拒絕，而不是默默忽略。
- 點擊 Decode。工具會在唯讀欄位中回報位元組數和解碼後的文字。位元組數是剖析器接受的位元組數，而不是十六進位數字的數量。
- 若欄位顯示錯誤，請修正第一個被回報的問題，然後再次解碼。編輯輸入內容或變更任一選項會立即清除先前的輸出，因此過時的文字絕不會與新的錯誤並存。
- 若瀏覽器允許存取剪貼簿，請使用複製按鈕複製解碼後的文字，或自行選取後複製。以 Ctrl+V 貼回單一的 Excel 儲存格中。
可接受的十六進位格式與 Excel 儲存格值的比較
下表顯示剖析器接受的內容與典型的 Excel 儲存格值並列。「Excel 儲存格值」欄描述會出現在資料編輯列中的字串;「工具結果」欄描述瀏覽器工具對從 Excel 複製出來的該字串所進行的處理。
| Excel 儲存格值 | 工具結果 |
|---|---|
| 48656c6c6f | 解碼為 Hello(5 位元組) |
| 48 65 6c 6c 6f | 在啟用空白的情況下解碼為 Hello(5 位元組) |
| 0x48 0x65 0x6c 0x6c 0x6f | 在啟用前綴的情況下解碼為 Hello(5 位元組) |
| 48,65,6c,6c,6f | 錯誤:逗號不是已啟用的分隔符 |
| 4 8 65 6c 6c 6f | 錯誤:4 與 8 是奇數長度的群組 |
| 48g65 | 錯誤:g 不是十六進位數字 |
| EFBBBF41 | 解碼為 A，前置的 3 位元組 BOM 已消耗 |
| 48 | 解碼為 H(1 位元組) |
任何一對小資料都能快速驗證:4869 會解碼為 Hi，因為 0x48 等於 72，也就是 H 的 ASCII 碼，而 0x69 等於 105，也就是 i 的 ASCII 碼。兩者都是單位元組 UTF-8 序列，所以兩個位元組合起來就是兩個字元。
常見的 Excel 十六進位陷阱與工具如何攔截它們
當十六進位資料是從公式鏈匯出時，半位元(nibble)數量為奇數是最常見的失敗原因。Excel 不會在 CHAR 呼叫回傳的碼位不構成完整 UTF-8 序列時提出警告，因此自製的編碼器可能會在試算表中悄悄產生一個看似沒問題的孤立續接位元組。該位元組會在解碼時被工具拒絕，並以「未解碼任何內容」的精確文字回報，因此可以追溯到產生該筆資料的公式。第二個陷阱是 BOM:以 CSV UTF-8 格式儲存的 Excel 活頁簿會在開頭加上 EF BB BF，而這個前置位元組是有效的 UTF-8 位元組順序標記。工具會將它消耗掉，因為標準的 TextDecoder 包裝函式採用其預設的 ignoreBOM false 行為，這代表 EF BB BF 41 會變成 A，而不是 U+FEFF 接著 A。同樣的位元組若出現在較長序列的中段，則會保留為字面的 U+FEFF 字元，這也是為什麼位置很重要。
第三個陷阱是語法混用。由不同公式產生的儲存格可能同時帶有 0x 前綴和無前綴的 token，而剖析器會拒絕解讀 0x41 42，因為它無法判斷 42 是純十六進位還是只去掉一半的前綴。解決方法是為匯出選擇一種語法並嚴格遵守:在貼到純文字模式之前，先移除所有 0x 前綴;或在貼到 prefixed 模式之前，將每個位元組補齊為 0xNN 形狀。第四個陷阱是隱形的空白字元。當從網頁來源匯入值時，Excel 會毫不猶豫地把不換行空格貼進儲存格，而工具會直接拒絕任何非 ASCII 的空白字元。請在 Excel 中以 TRIM 與 CLEAN 函式取代這些字元，或先將儲存格內容複製到 Notepad，以便分辨普通空格與不換行空格的差異。
大小上限是明確的。工具接受的原始輸入最多為 2,000,000 個 UTF-16 碼位，剖析後的位元組最多 1,000,000 個，解碼後的文字最多 1,000,000 個 UTF-16 碼位。帶前綴的標記法每個位元組會用掉較多的來源字元，因此從大型試算表匯出的 0x 前綴資料，可能會在位元組預算用盡之前就觸及原始輸入預算;這是預期中的情況，並會以同樣的「未解碼任何內容」字樣回報。不會靜默截斷任何值，不會切開過大的來源，位元組計數會在配置前計算，因此預算錯誤絕不會產生部分輸出。
工具只能解碼 UTF-8。它不會猜測 Windows-1252、ISO-8859-1、UTF-16 或 Shift_JIS，因為靜默猜測會改變位元組的意義，這正是促使採用嚴格解碼器的失敗模式。這些檢查遵循 WHATWG UTF-8 解碼器與 RFC 3629，而非寬鬆的位元組到碼位捷徑。若你的 Excel 匯出來自舊版活頁簿，而解碼後的文字看起來不對，那些位元組幾乎可以確定不是 UTF-8，此時正確的下一步是確認來源編碼，而不是去鑽研解碼技巧。對於 UTF-8 十六進位，工作流程是:從 Excel 複製、貼到工具、解碼、複製結果、貼回去。三個步驟，不用公式，不用上傳伺服器，沒有靜默的替換字元。