如何用 Base64 與 Hex 編碼／解碼資料
何時用 Base64、Base64-URL、Base32、Hex；二進位無法當 ASCII 時怎麼辦；解碼又不丟尾端零。
與本篇教學搭配使用的更多工具：
為什麼重要
二進位資料必須經過只接受文字的系統。經典例子：JSON API 附帶的 PNG。Base64 把 3 位元組變 4 個 ASCII 字元，這就是安全傳輸的代價。變體搞錯（+/ vs -_、有無補位）解碼就變垃圾。知道該用哪種編碼與其眉角，可把一行惱怒變成小事。
三個實際場景
檔案編 Base64 放入 JSON，伺服器再解回位元組。
單次請求往返
依點切開，Base64-URL 解 header 與 payload，再以密鑰驗簽。
驗證簽章
貼上 hex 對，工具輸出原始位元組供分析。
還原幀
操作說明
開啟 編碼／解碼工具。
選編碼
Base64（RFC 4648 標準）、Base64-URL（URL 安全）、Base32 或 Hex。字母表與補位規則各有不同。
放入輸入
文字或檔案放左側。若是二進位檔而非 ASCII，請切換輸入模式。
切換編碼／解碼
對稱：編後再解應得原文。解出垃圾通常是變體不對。
輸出選 UTF-8 或原始位元組
文字酬載解成 UTF-8；圖片、壓縮檔請下載為檔案。
複製或下載
純文字複製到剪貼簿；二進位以下載與推斷的 MIME 型別。
位元組
Hello, GitHub?編碼
Standard: SGVsbG8sIEdpdEh1Yj8=
URL-safe: SGVsbG8sIEdpdEh1Yj8
(no padding, '+'/'/' replaced with '-'/'_')位元組
\x00\x0F\xA5\xFFHex
00 0F A5 FF
實用技巧
- JWT 各段是無補位的 Base64-URL。 標準 Base64 解碼器可能抱怨——請用 URL 安全 profile。
- 解碼前先去掉空白。 PDF 貼上的 Base64 常有每 76 字元軟換行。
- 網路側錄 human-readable 用 hex；傳輸偏好 Base64。 Hex 是來源位元組的 2 倍大；Base64 約 1.33 倍。
- 驗證檔案完整性： 解碼後用 雜湊產生器 與來源雜湊比對。
常見陷阱
常見陷阱
解出怪字或「?」
位元組是有效二進位但非有效 UTF-8。輸出模式從「UTF-8 文字」改為「原始位元組」／下載檔案。
常見陷阱
郵件貼上的 Base64 尾端 `=` 被拒
有些編碼器用 = 補位，有些省略。請依目的地重新編碼（或移除補位）以對齊。
常見陷阱
帶分隔符的 hex（00:0F:A5）解不出
先去掉冒號、空白與換行——解碼器要純 hex 數字。
何時不適合用這套
- 雜湊（單向驗證或密碼儲存）——用 雜湊產生器。Base64 可逆，不是雜湊。
- 加密（機密性）——Base64 不是加密。請用真實加密演算法並保護金鑰。
- 壓縮——Base64 膨脹資料。在意體積時先 gzip 再 Base64。
FAQ
為什麼 Base64 多 33% 開銷？
每 3 輸入位元組對應 64 字母表裡 4 個字元。4／3 ≈ 1.33×。補位在長度非 3 倍數時再加一點點。
Base64 是雜湊嗎？
不是。Base64 是可逆編碼。任何人只要有字串就能還原原文。
資料會送到伺服器嗎？
不會。編解碼在瀏覽器執行；檔案不上傳。
下一步
- 解出的二進位用 雜湊產生器 做完整性檢查。
- 用 HMAC 產生器 簽署 API 酬載。
- 需在 HTML／CSS 免 CDN embed 圖片時用 圖片轉 Base64。