Base64 轉 Hex 解碼器會將 Base64 字串轉成其所代表的精確十六進位位元組，因此每四個 Base64 字元會對應到三個輸入位元組，並以三組兩位數的十六進位配對呈現。這種轉換是在位元組層級而非文字層級進行，代表前導 00 位元組、精確長度，以及 API、雜湊或協定欄位實際承載的二進位值，都能在轉換過程中完整保留下來。
當你從 API、已簽署的權杖、測試 fixture 或封包擷取中收到 Base64 字串時，通常需要查看底層的原始位元組，以便與規格進行比對、複製到其他工具，或是找出多餘的空位元組。嚴格的 RFC 4648 解碼器不需要猜測就能完成這項工作:它要求使用帶填補的標準 Base64、拒絕空白字元與 base64url 變體，並輸出小寫十六進位，使位元組邊界保持明確。
對於大多數除錯工作來說，工作流程很短:確認來源確實使用標準 Base64、貼上編碼後的字串、執行轉換，並在將結果複製到下一個工具之前，檢查位元組數量以及任何前導 00 位元組是否符合預期。
Base64 轉 Hex 解碼器實際上做了什麼
Base64 是一種位置編碼，會將三個輸入位元組打包成四個輸出字元，這些字元取自 A–Z、a–z、0–9、+ 與 /。每個字元承載六個位元的有效負載，因此 24 個輸入位元會變成四個字元;當最後一組只有一個或兩個位元組時，等號會填滿四個字元的配額，以保持剩餘位元位置不產生混淆。相比之下，Hex 為每個位元組剛好分配兩個字元:0–9 與 a–f，其中每個數字涵蓋四個位元。
Base64 轉 Hex 解碼器會反轉第一步並執行第二步。它一次讀取四個 Base64 字元、重新組合原始的 24 個位元、將其拆成三個位元組，然後將每個位元組以兩位小寫十六進位數字輸出。相同的位元組序列輸入，相同的位元組序列輸出;中間沒有雜湊、壓縮或字元集解讀。這項特性正是使輸出值得信賴、可用於規格比對的原因:當協定規定下一個欄位是 4 個位元組的零時，你應該在十六進位輸出中看到 00000000，而不是「空」。
這個 Base64 轉 Hex 轉換器遵循 RFC 4648，該標準統一了字母表與填補規則。它還會重新編碼解碼後的位元組，並拒絕任何尾部等號帶有非零填補位元的輸入，因為這會為相同的位元組序列產生第二種拼法，破壞精確的位元組相等性檢查。
解碼器何時真正發揮價值
每當你需要比對酬載中的內容與應該存在的內容時，解碼器就能發揮價值。以下是一些常見的情境:
- 承載二進位識別碼(UUID 為 16 位元組、64 位元 ID、不透明的控制代碼)的 API 酬載，通常以 Base64 形式送達，因為 JSON 與 URL 能乾淨地處理該字母表。
- 已簽署的權杖與 JWT 會拆成三段 Base64;在除錯整合或稽核聲明時，標頭與酬載段都值得解碼。
- 雜湊摘要常以 Base64 在系統之間複製，但程式碼或規格表中的比對通常以十六進位撰寫。
- 來自封包擷取器的協定欄位擷取通常為十六進位，而記錄檔與儀表板可能將相同的位元組以 Base64 呈現。
- 規格中的測試 fixture 與回歸向量通常以十六進位提供;如果廠商提供的是 Base64，解碼器可讓你驗證位元組是否符合發布的向量。
在每個情境中，問題都相同:這個編碼字串是否恰好解碼為這些位元組?一個默默接受空白、遺漏填補或 base64url 的解碼器會在真正答案是「幾乎對，但尾端位元組位移了」時回答「是」，而這個「幾乎」正是破壞已簽署比對的原因。
如何以三個步驟將 Base64 解碼為 Hex
轉換流程刻意設計得很短，以免解碼器本身成為除錯的來源。
- 選擇 Base64 → Hex，並確認來源確實是標準的 RFC 4648 Base64:大寫與小寫字母、數字、+、/，以及尾端的 = 填補。如果你的字串使用 - 或 _ 而非 + 與 /，則屬於 base64url，需要使用獨立的轉換器，而不是默默替換。
- 貼上帶有填補的標準字串，不要包含空白、換行、data-URL 前綴或任何周圍的標籤。長度必須是 4 的倍數，任何必要的等號都必須出現在尾端。
- 執行轉換。檢查位元組數量(每兩個十六進位數字代表一個位元組)，確認任何前導 00 位元組仍然存在，然後將小寫十六進位複製到下一個工具，或與規格進行 diff 比對。
如果轉換器回傳錯誤而非結果，請修正輸入而非重試。格式錯誤的輸入在第二次點擊時不會變好，而接受部分解碼正是這類工具所要避免的隱性失敗。
能捕捉真實錯誤的嚴格輸入規則
解碼器刻意設計得很嚴格。標準 RFC 4648 只有一套字母表與一條填補規則，而每個被接受的變體都是獨立的描述檔。將它們視為可互換，正是解碼錯誤藏身之處。
| 輸入模式 | 是否接受 | 原因 |
|---|---|---|
| 帶填補的標準 Base64(例如 SGVsbG8=) | 是 | 符合 RFC 4648 且具備必要的 = 填補 |
| 無填補的 Base64(SGVsbG8) | 否 | 必須具備必要的填補 |
| 含空白或換行的 Base64 | 否 | 不會默默忽略空白字元 |
| base64url 字母表(使用 - 或 _) | 否 | 字母表不同;請在其專屬描述檔下轉換 |
| 尾部等號帶有非零填補位元 | 否 | 會為相同的位元組產生第二種拼法 |
| 含標頭行的 MIME 包裝輸入 | 否 | MIME 是容器格式，並非原始 Base64 |
十六進位解析器遵循相同的原則。輸入必須是連續的兩位數配對序列:不得有 0x 前綴、不得有分隔符、不得有底線、不得有空白，總長度必須為偶數。接受大寫數字;輸出永遠為小寫以保持一致的簡潔性。單一字元值(例如 f)會被拒絕，因為它並未指稱一個完整的位元組。
這些規則看似吹毛求疵，但一旦比對失敗就顯得至關重要。被捨棄的前導 0x00 位元組、被多加的填補字元、被忽略的 base64url 字母表替換——每一項都會位移後續所有位元組，並破壞已簽署的相等性檢查。
位元組長度與前導零位元組
十六進位輸出為每個位元組剛好使用兩位數，這正是該格式適合逐位元組檢視的原因。實務上有兩項重要意涵。
首先，長度完全可讀。長度為 N 的十六進位字串，必然剛好代表 N/2 個位元組。在十六進位層級沒有填補字元可以遮蔽最後一個位元組是否為真實資料或填充;你所看到的位元組數，就是下一個工具將接收的位元組數。
其次，前導 00 位元組並非可有可無。0x0001 這類值在 Base64 中編碼為 AAE=，在十六進位中為 0001。如果十六進位輸出捨棄前導零而印出 1，長度就會從兩個位元組縮短為一個，任何讀取固定寬度欄位的下游解析器都會失敗。輸出小寫十六進位的解碼器會保留這些零，並拒絕將其強制移除。
作為具體範例，RFC 4648 中三位元組輸入 foo 的向量眾所周知:foo 以 Base64 編碼為 Zm9v,Zm9v 解碼後的十六進位為 666f6f。將 Zm9v 貼入轉換器，你應該會看到 666f6f，共三個位元組，沒有需要擔心的前導零。與確實以零位元組開頭的向量進行比對，你就能同時確認位元組數量正確，以及前導零在來回轉換後依然存在。若需要更嚴格的來回檢查，Base64 Hex 轉換器精確位元組參考會以標示位元組邊界的方式，逐步展示相同的 RFC 4648 向量。
解碼器不會為你做的事
可逆編碼並非安全邊界，轉換器也不會假裝它是。你所解碼的位元組，正是當初被編碼的位元組;過程中沒有金鑰、沒有檢查碼，也沒有解讀動作。將憑證、權杖、私鑰或個人資料貼上，輸出將逐字呈現這些位元組，因此請避免將輸入用於共用剪貼簿、記錄檔、螢幕圖與分析欄位。
轉換器同樣不會解讀這些位元組。它不會嘗試將其解碼為 UTF-8、將其渲染為影像、將其剖析為 JSON，也不會將其視為憑證或檔案格式。如果規格將位元組包裝在 data-URL、MIME 信封或 PEM 標頭中，轉換器會回傳原始位元組，並將包裝作業留給獨立的工具處理。
輸入上限為 500,000 個解碼後的位元組，以維持瀏覽器的回應速度。轉換使用數值型位元組陣列而非文字強制轉換，輸出絕不會被默默截斷，格式錯誤的輸入會產生明確的錯誤，且不會有部分結果。複製動作只會複製轉換後的值，而不會包含標籤或說明文字。
如果你正在權衡選項，在 Angular 元件中將檔案轉換為 Base64對此有詳細說明。