將 Base64 轉換為十六進位意味著在同一組位元組的兩種文字安全表示法之間進行轉譯:RFC 4648 Base64,它會將每三個輸入位元組編碼為四個字元(取自一個由 64 個字元組成的字母表),以及 Base16 十六進位,它會將每個位元組寫成恰好兩個來自 0–9 與 a–f 的字元。位元組本身永遠不會改變 — 改變的只是它們在螢幕上的格式 — 因此這種轉換是完全可逆的,並且能透過往返(round-trip)測試無損地自我驗證。對於任何解碼後不超過 500,000 位元組的資料承載,瀏覽器端的工具可以驗證字母表、必要的等號填補(equals padding),以及零填補位元(zero pad bits),然後輸出無分隔符的標準小寫十六進位。這種嚴格的轉換,正是當你需要檢查一段已編碼的資料承載、將雜湊值貼到另一個工具,或是將某個值與 RFC 測試向量進行比對時所該採用的方法。反向的同一個工作流程 — 將十六進位位元組轉回 Base64 — 則可讓你在以十六進位形式檢查或編輯某個 token 或協定欄位之後,將其重建以便傳輸。
Base64 與十六進位的真正意涵
Base64 與十六進位都是可逆的編碼方式,而非加密、雜湊或壓縮。它們接收原始位元組,並使用不同的字母表將其以文字形式輸出,使得資料能透過那些可能破壞二進位值的通道進行傳輸,或是能夠在螢幕上一次一個位元組地進行檢視。
RFC 4648 所定義的標準 Base64,會將輸入位元組分組為三元組,並將每組寫成取自一個 64 字元字母表的四個字元:大寫 A–Z、小寫 a–z、數字 0–9、加號,以及斜線。當最後一組只包含一個或兩個位元組而非三個時,會使用一個或兩個等號將輸出填補至四的倍數。十六進位同樣由 RFC 4648 所定義,但更為簡單:每個位元組會變成恰好兩個來自 0–9 與 a–f 的字元。十六進位輸入接受大小寫兩種形式,但為了簡潔與一致性,標準輸出永遠是小寫。
| 特性 | RFC 4648 Base64 | Base16 十六進位 |
|---|---|---|
| 字母表大小 | 64 個可列印字元 | 16 個字元 (0–9, a–f) |
| 每組位元組數 | 3 個輸入位元組 → 4 個輸出字元 | 1 個輸入位元組 → 2 個輸出字元 |
| 填補規則 | 需要 1 或 2 個尾端等號 | 不需要;奇數長度視為無效 |
| 輸出長度 | 每 3 位元組約 4 字元 | 每個位元組恰好 2 字元 |
| 特殊字元 | + 與 / 用作值 62 與 63 | 除數字外無其他字元 |
| 大小寫敏感性 | 區分大小寫的字母表 | 輸入接受兩種大小寫;輸出為小寫 |
| 典型用途 | 在文字通道中傳輸 (MIME、JWT、金鑰) | 檢視、雜湊輸出、位元組層級除錯 |
由於 Base64 在線路上較為精簡但無法直接閱讀,而十六進位較長但能在畫面上明確對應到位元組,這兩種格式會出現在同一個工作流程的不同環節中。這正是為什麼「base64 轉十六進位」會是一個真實且反覆出現的工作,而不是出於好奇,同時也是為什麼轉換必須精確而非近似的原因。
何時需要在兩者之間轉換
在少數幾種情境中,位元組完全一致的 base64↔十六進位轉換會是正確的工具:
- 讀取已編碼的資料承載。 token、憑證欄位、JWT 區段,以及已簽署的資料,常會以 Base64 形式送達。將它們丟進十六進位能讓你確認長度、查看前置零位元組,並在下游引發協定錯誤之前,察覺出夾帶的空白或填補錯誤。
- 與測試向量進行比對。 RFC 4648 提供了一些標準向量,例如空字串、f、fo、foo、foob、fooba 與 foobar,以及一個會用到字母表值 62 與 63 的向量。將你的輸入在兩個方向上各跑一次,並把輸出與規格進行比對,就能在錯字變成協定錯誤之前先將其攔截。
- 雜湊值與識別碼。 SHA-256 摘要、UUID 或二進位識別碼,可能會依產生它們的系統不同,而以任一種格式送達。在兩者之間轉換,比重跑一次雜湊更快,也比一個一個數字元來得輕鬆。
- 建立測試固件。 協定測試、快取鍵與重送檔案,常常需要精確的位元組序列。十六進位能讓位元組邊界在視覺上一目了然,這在你於程式碼審閱中比對固件,或將其貼進多個測試執行器時特別有幫助。
若你的目標正是上述其中之一 — 檢視、比對或組裝精確的位元組 — 那麼嚴格的轉換器就是正確等級的工具。若你實際上是想要解碼 JWT 承載、渲染影像,或是讀取 UTF-8 字串,則需要另一個在轉換之後解讀這些位元組的步驟。
如何在線上將 Base64 轉為十六進位
Base64 轉十六進位工具完全在瀏覽器中執行,並會驗證轉換過程中的每一個步驟。其精確的工作流程如下:
- 選擇方向:若你的來源是 RFC 4648 Base64,就選 Base64 → 十六進位;若你是從十六進位位元組出發,就選 十六進位 → Base64。該頁面也允許你貼上其中一端,讓你能往返(round-trip)一個值來確認正確性。
- 辨識來源設定檔。標準 Base64 使用 +、/,以及必要的 = 填補。若你的輸入使用的是 - 與 _,或省略了尾端的等號,則它屬於另一個設定檔下的 base64url,必須先轉換為標準形式。
- 逐字貼上輸入。對 Base64 而言,貼上無空格、無換行、無外層引號的標準填補文字。對十六進位而言,貼上連續的字串,每個位元組恰好兩個數字,沒有 0x 前綴,沒有空格、底線或冒號分隔符,也不可有奇數長度的尾端半位元組。
- 執行轉換。頁面會解碼位元組、驗證標準填補與零填補位元,然後再將其重新輸出為小寫十六進位或標準填補的 Base64。為使瀏覽器記憶體用量可預期,轉換上限設為 500,000 個解碼位元組,且絕不會靜默截斷輸出。
- 驗證結果。確認位元組長度符合預期 (Base64 字元數 ÷ 4 × 3,再扣除尾端等號),確認任何前置零位元組都以 00 出現在十六進位中,然後透過頁面的複製動作複製精確的輸出 — 放進剪貼簿的只有轉換後的值,不含標籤或說明文字。
使用 RFC 4648 向量 foo 作為快速示範:三個位元組為 0x66、0x6f、0x6f,轉換器會將其渲染為十六進位字串 666f6f,以及 Base64 字串 Zm9v。將任一方向透過同一個工具往返一次,都必須逐位元組地產生另一種表示法 — 這就是此工具設計上要滿足的基本正確性檢查。
轉換器強制執行的規則
此工具刻意採嚴格而非寬容的態度。下列每一條規則的存在,都是為了避免一次「成功」的轉換掩蓋了真正的錯誤:
- 僅限標準 Base64。 字母表嚴格為 A–Z、a–z、0–9、+、/。會拒絕空白字元、拒絕 base64url (- 與 _),也會拒絕 MIME 式的換行包裝。若你不確定自己手上是哪個設定檔,請先辨識它 — 猜測設定檔正是無聲錯誤悄悄滲入協定程式碼的方式。
- 長度必須為四的倍數。 任何其他長度都代表輸入格式錯誤,無法解碼為完整的位元組。
- 填補只能出現在尾端。 等號應只出現在最後一組四字元中,不可出現在別處。夾在中間的雜湊等號並不是「額外填補」 — 它是一種結構性錯誤。
- 拒絕零填補位元不一致的情況。 在解碼之後,此工具會重新編碼這些位元組,並檢查結果是否與輸入完全一致。一個非標準的 Base64 字串,若透過不同的填補位元解碼到同一組位元組,將會被拒絕,因為接受它會讓兩種不同的拼寫代表同一個值。
- 十六進位為每個位元組兩個數字,不可有前綴。 像 0f 這樣的輸入是一個位元組;單獨的 f 是不完整的,會被拒絕。像是 0x 之類的前綴、空格、底線或冒號等分隔符,以及奇數長度的字串,全都會被拒絕,以使位元組邊界永遠不會含糊。
- 輸出為小寫十六進位。 十六進位輸入可以是大寫或小寫,但為了簡潔與跨次執行的一致性,輸出永遠是小寫。
當上述任何一項檢查失敗時,你會得到一條具體的錯誤訊息,而不是半成品。這裡沒有靜默截斷,也沒有猜測式的備援。
正確讀取輸出結果
轉換後的十六進位字串看似簡單,但只要做兩個檢查,就能抓住下游幾乎所有的錯誤。
第一個,數一下十六進位字元數。每個位元組佔兩個字元,所以有效的十六進位字串長度一定是偶數。若你從 Zm9v (四個 Base64 字元,沒有等號) 出發,位元組長度為 3,十六進位字串應為 6 字元長:666f6f。若你從 Zm8= (一個尾端位元組,一個等號) 出發,位元組長度為 2,十六進位字串應為 4 字元長。出現奇數長度的十六進位輸出,是一個明顯的紅旗,代表在傳輸過程中有東西遺失了。
第二個,留意前置零。若輸入的第一個位元組是 0x00,它會以 00 這兩個字元出現在十六進位輸出的最前端 — 在視覺掃讀時很容易漏看。反過來,若你預期最前端應為 00 卻沒看到,那就是一個很強烈的跡象,顯示前端的位元組在上游某個環節被捨棄了 — 可能是在轉換過程中,也可能是在產生來源字串的系統中。保留這些前置零,正是讓表示法能夠做到位元組級精確的原因,而已簽署資料、快取鍵與協定固件所依賴的,正是這個特性。
常見的陷阱與安全注意事項
在貼上第一段字串之前，有幾個常見的錯誤值得特別提出來提醒：
- 混淆 Base64 與 base64url。 JWT 和許多網路 API 使用的是 base64url，它會將 + 和 / 替換為 - 和 _，並經常省略結尾的等號。標準的 Base64 轉換工具會直接拒絕這類輸入。請先轉換為標準的、帶填補的 Base64 格式，再執行工具，而不是試圖「邊執行邊修正」。
- 讓空白字元混入其中。 換行、空格與 Tab 並不屬於標準字母表的一部分。電子郵件流程與從終端機複製貼上時常常會附加這些字元，特別是較長的內容。請在貼上之前先將它們移除，以免嚴格的解析器拒絕其實有效的位元組。
- 把成功轉換當成語意上的驗證。 轉換器只能證明位元組能精準地來回轉換，並無法證明這些位元組代表你以為的意義。對於安全性敏感的協定，請將最終結果與其規範或官方測試向量進行比對，而不是把一次綠燈的轉換視為正確性的證明。
- 誤以為 Base64 或十六進位能保護秘密。 這兩種編碼都是完全可逆的。任何擁有編碼後字串的人，都能取得原始的位元組。無論格式為何，都應以相同程度的謹慎來處理代權杖、私鑰、密碼與個人資料，並避免將它們放進不受信任的剪貼簿、紀錄檔、螢幕截圖、Issue 追蹤系統、分析欄位或共用的瀏覽器工作階段中。
避開這些陷阱之後，轉換本身其實很短：確認設定檔、貼上精確的位元組、執行工具、驗證位元組長度與任何前導零，然後複製結果。這一趟來回轉換，正是 base64↔十六進位之所以能成為日常協定工作中可靠工具的原因，也說明了嚴格驗證相較於寬鬆解碼所多花的那幾秒鐘是值得的。
想進一步了解，請參閱如何將 ASCII 轉換為十六進位：以十進位為起點的逐步說明。
想進一步了解，請參閱可處理 UTF-8、口音與表情符號的 Base64 轉換工具。