Base64 與十六進位是同一段位元組序列的兩種可逆編碼方式，定義於 RFC 4648，兩者之間的轉換意味著重新標示同一筆承載內容，不會遺漏或虛構任何一個位元組。這種轉換會將每三個輸入位元組對應到四個 Base64 字元，取自 A–Z、a–z、0–9、+ 與 /，而十六進位則將每個位元組寫成恰好兩個 0 到 f 之間的數字。由於兩種形式描述的是完全相同的位元組，「命令列 vs 線上工具」這個問題，最終取決於哪個環境能強制執行接收端工具實際期待的位元組邊界、規則設定與驗證機制。

在比較這兩種做法時，搜尋者通常會分成兩派：一派是開發人員在終端機中把 base64 與 xxd 串接起來進行自動化作業，另一派則是工程師從日誌、測試資料或協定追蹤記錄中抽出一段承載內容，需要在沒有建置工具鏈的工作站上檢視它。Base64 轉 Hex 轉換器正好落在第二派，但它也涵蓋了命令列工具悄悄接受與周遭格式所指定不同規則的狀況。

base64 to hex command line vs online
Base64 與 Hex：命令列與線上工具比較

命令列管線：xxd、base64 與 OpenSSL

在 Linux、macOS 與 WSL 上，標準管線看起來像這樣：先將 Base64 解碼為原始位元組，再用 xxd 將這些位元組重新輸出為十六進位，反向亦然。

echo -n 'SGVsbG8=' | base64 -d | xxd -p 會輸出 48656c6c6f。反向操作——echo -n '48656c6c6f' | xxd -r -p | base64——則會輸出 SGVsbG8=。兩者都能運作，是因為每個工具只執行一個明確定義的轉換，並將原始位元組交給下一個階段，因此中途不會被當作文字重新解讀。

當缺少 xxd 時，OpenSSL 是個可行的替代方案：echo -n '48656c6c6f' | openssl base64 會產生相同的 Base64 結果，而 openssl base64 -d 則可取代另一個方向的 base64 -d。Windows 上的 PowerShell 內建 certutil 與 [Convert]::FromBase64String，但兩者都無法一步輸出十六進位；多數腳本會將解碼後的位元組再透過 Format-Hex 或一段簡短的 .NET 運算式來格式化位元組陣列。

若是 Python 或 Node 腳本，base64.b64decode 與 Buffer.from(s, 'base64') 會回傳位元組陣列，輕鬆就能格式化為十六進位。這些程式庫路徑能讓驗證緊貼 RFC 4648 規則，並以特定的例外拒絕格式錯誤的輸入——比起串接 shell 公用程式時對某些錯誤輸入照單全收、對其他輸入則拒絕，這是更嚴格的契約。

Shell 管線失效之處

第一種失效模式是規則漂移。macOS 與 BSD 的 base64 預設接受換行包裹的輸入，且可能會忽略填補字元，而 GNU 的 base64 則較為嚴格。xxd -r -p 會毫不猶豫地把一串十六進位數字轉成位元組，卻不會告訴你來源是否指定每個位元組兩個數字，或你是否餵入了奇數長度的字串。當管線默默接受了規則不一致的情況，輸出的位元組本身仍然有效，但可能不符合資料原本應該遵循的規格。

第二種失效模式是 base64url 變體。部分網頁 API、JWT 權杖與 URL 安全檔名會將 + 換成 -、將 / 換成 _，並經常省略結尾的 = 符號。GNU 與 BSD 的 base64 -d 都不接受這些字元，也不接受缺少的填補字元。管線不會發出任何警告；你只會得到亂碼輸出，或一則令人困惑的非零退出碼訊息。

第三種失效模式是非標準的填補。RFC 4648 規定，若輸入為一個或兩個位元組，結尾必須分別帶有兩個或一個 = 符號，且最後一個 Base64 字元中未使用的位元必須為零。多數解碼器——包含 base64 -d——都能順利解碼像 Zm9v=== 或 Zm9v===== 這類字串，因為在忽略填補的情況下，編碼後的位元仍然會對應到相同的位元組。這種寬容在顯示內容時沒問題，但對簽署過的承載內容、快取鍵，或任何需要逐位元組精確比對的地方來說，卻是場災難。

第四種失效模式是文字與位元組混用。一旦有雜散字元未加引號逃脫進 shell 管線，或從剪貼簿夾帶了 CRLF 進來，xxd 會發出警告，但 base64 -d 可能會產生一個看起來合理卻是錯誤的結果。你最後只能在深夜除錯，試圖弄清楚為何某個驗證步驟一直失敗。

使用 Base64 轉 Hex 轉換器在瀏覽器中進行轉換

Base64 轉 Hex 轉換器將這次轉換視為一項契約而非猜測，從而解決了上述失效模式。該頁面最多接受 500,000 個解碼後的位元組，並在本地端完成整個轉換，因此輸入內容從不離開瀏覽器分頁。它支援兩個明確的方向：Base64 轉十六進位，以及十六進位轉回 Base64。

Base64 解析器相當嚴格。輸入長度必須為四的倍數，必要的 = 填補必須存在，填補只能出現在結尾，不忽略任何空白字元，每個字元都必須屬於標準的 Base64 字元集。在解碼之後，頁面會重新編碼結果，若填補位元不為零則拒絕該輸入，因為這類輸入對同一組位元組存在第二種標準拼法，而轉換器拒絕猜測你究竟想用哪一種。

十六進位解析器同樣嚴格。輸入必須是每個位元組恰好兩個數字的連續序列，不能有 0x 前綴、不能有分隔符號、不能有空白、不能有底線，也不能有奇數的尾端半位元組。大寫與小寫數字皆可接受，但輸出一律為小寫以保持簡潔一致。像 0f 這樣的值代表一個位元組；單獨的 f 則會被拒絕。

作為可運作的參考，RFC 4648 的標準向量 "Man" 在 Base64 中編碼為 TWFu，在十六進位中為 4d616e。這兩種表示法描述的是相同的三個位元組——0x4D ('M')、0x61 ('a')、0x6E ('n')——而轉換器在雙向往返中不會遺漏任何一個位元。正確性由八個外部測試案例鎖定：空序列，以及標準的 f、fo、foo、foob、fooba 與 foobar 向量，外加一個涵蓋字元集數值 62 與 63 的位元組序列。非標準填補與格式錯誤字元集的案例則分開測試，藉此確認嚴格行為。

在轉換器中進行 Base64 與 Hex 之間的轉換

  1. 選擇與起始資料相符的方向：Base64 轉十六進位，或十六進位轉 Base64。
  2. 確認來源規則設定。標準的 RFC 4648 Base64 使用 + 與 / 並需要填補；若來源使用 - 與 _，請先在另一個規則設定下從 base64url 轉換，再貼上。
  3. 完整無誤地貼上輸入。對於 Base64，請貼上無空白的標準填補文字。對於十六進位，請貼上每個位元組恰好兩個數字、不含前綴或分隔符號的內容。
  4. 執行轉換。頁面會在產生結果之前，先驗證位元組邊界、必要填補、字元集成員資格，以及填補位元是否為零。
  5. 驗證位元組長度與任何前導零位元組（在十六進位中顯示為 00）。成功的轉換並不等於語意驗證——請將最終結果與所屬規格或官方測試向量進行比對，特別是在安全性敏感的協定中。
  6. 複製完全相同的輸出。複製的內容僅包含轉換後的數值，不含標籤或說明文字。

讓兩種做法都上當的規則不一致情況

有三種真實世界的情境會讓管線與線上工具都措手不及。

第一種，來自電子郵件與 PEM 檔案的換行包裹 Base64。符合標準的解碼器接受以 CRLF 結束的 76 字元行；而嚴格的 RFC 4648 解析器（包含本轉換器）則直接拒絕換行。快速檢查方式：先去除空白，再驗證長度是否為四的倍數，並以正確數量的 = 符號結尾。

第二種，JWT 權杖與 URL 參數中的 base64url。請將 - 換成 +、將 _ 換成 /，把填補還原為四的倍數，再行貼上。若跳過這一步，嚴格解析器會回傳錯誤，而不是默默產生錯誤答案。

第三種，來自除錯器的十六進位傾印。除錯器經常會為位元組加上 0x 前綴、以空白分隔，或以 4 位元組為一組搭配換行。本轉換器的嚴格十六進位解析器會拒絕以上所有格式。將傾印清理成扁平的、每個位元組兩個數字的串流，才是可靠的做法。對於需要分隔符號、以文字為主的十六進位轉換，Hex 轉文字轉換器以明確的分隔符與 0x 前綴規則處理相反的問題。

為你的任務選擇命令列或線上工具

情境命令列管線Base64 轉 Hex 轉換器
自動化與 CI 腳本最佳選擇。無需瀏覽器即可執行，且能在各階段之間順暢串接。需要手動複製並開啟瀏覽器分頁；不適合無人值守的腳本。
檢視來自日誌或規格的承載內容可行，但 shell 可能會默默接受不同的規則設定。最佳選擇。嚴格的驗證能在輸入錯誤擴散前就先抓出來。
逐位元組比對已簽署的數值有風險。GNU 與 BSD 的 base64 會接受非標準的填補。最佳選擇。拒絕非標準編碼，以鎖定精確的位元組序列。
來自 JWT 或 URL 欄位的 base64url 輸入需要在管線之外進行前置處理。需要前置處理；轉換器不會猜測規則設定。
最多 500,000 個解碼後位元組的輸入沒有內建上限；改由系統記憶體決定上限。受轉換器 500,000 位元組上限限制，以保護瀏覽器記憶體。
隱私敏感的數值在本機執行，但數值會經過 shell 歷史紀錄與管線。完全在瀏覽器分頁中執行；不會上傳任何內容，但仍須注意剪貼簿的衛生。

對於已知規則設定的例行自動化作業，命令列管線仍然是最快的途徑。對於未知的規則設定、嚴格的逐位元組比對，或是對從規格中抽出的數值進行一次性檢視，轉換器的嚴格驗證能藉由拒絕在輸入有歧義時輸出結果，帶來物有所其值的效益。

無論是 Base64 或十六進位，都無法保護秘密。兩者都是同一組位元組的可逆編碼，沒有機密性、認證或存取控制。對憑證、權杖、私密金鑰或個人紀錄進行轉換並不會保護它們，因此請將敏感數值遠離不受信任的剪貼簿、日誌、螢幕擷圖、議題追蹤系統、分析欄位，以及共用的瀏覽器工作階段。

當規格以一種表示法給定位元組，而另一個工具期待另一種表示法時，請使用本頁面。首先請確認來源確實使用標準的 RFC 4648 Base64，而非 base64url 或 MIME 格式。接著進行轉換，比對位元組長度，並保留任何在十六進位中顯示為 00 的前導零位元組。對於安全性敏感的協定，請將最終表示法與所屬規格或官方測試向量進行比對，而非將成功的轉換視為語意驗證。

若想進一步了解，請參閱 將檔案轉為 Base64：實用編碼指南。

若想進一步了解，請參閱 Gzcompress 線上入門：UTF-8 到 Gzip Base64。