什麼是 Base64？

Base64 是 1980 年代為 email 附件設計的編碼方式（RFC 4648），把任何「二進位資料」用 64 個 ASCII 可印字元（A-Z、a-z、0-9、+、/）重新表示。原意是讓二進位檔案能在「只接受純文字」的系統（如早期 SMTP email、HTTP headers）中安全傳輸，不被換行、空白、控制字元破壞。

今日 Base64 幾乎無所不在：email 附件（MIME）、JWT token、HTTP Basic Auth、Data URL（把圖片塞進 HTML / CSS）、API 傳檔（圖片轉 Base64 放進 JSON）。理解它有助於 debug 各種「為什麼這串字看起來很長且結尾有 = 號」的場景。

常見使用情境

JWT decode：JWT 的 header / payload 是 Base64 編碼，貼進來可看欄位內容
HTTP Basic Auth：Authorization: Basic dXNlcjpwYXNz 解開就是 user:pass
Data URL：把小圖直接寫進 HTML / CSS，減少 HTTP request，用圖片轉 Base64 工具更方便
API 傳輸二進位：JSON 不能放 binary，用 Base64 包進去 string 欄位
看不明訊息：log 或網址中看到「SGVsbG8gV29ybGQ=」這種感覺像密碼的字串，解碼看看是不是普通文字

為什麼編出來會變長？

Base64 把每 3 個位元組編成 4 個字元，長度會變成原來的約 4/3 倍（增加 33%）。這是設計使然——犧牲體積換取「能在純文字環境傳輸」。

如果原本資料不是 3 的倍數，結尾會補 =（padding）讓總長度是 4 的倍數。這就是為什麼 Base64 字串常以一個或兩個 = 結尾。

中文怎麼處理？

本工具用 UTF-8 編碼中文，與現代瀏覽器、Node.js、Python 3、Go 預設行為一致。一個中文字通常編成 3 個位元組，Base64 後變成 4 字元。

如果解碼後出現亂碼，通常是來源用了非 UTF-8 編碼（早期 Big5、GB2312 系統）。Base64 本身只規範「位元組到字元的對應」，不規範「位元組對應什麼字元集」。

Base64 變體

標準 Base64（RFC 4648 §4）：用 + /，結尾 = padding。本工具預設此種
URL-safe Base64（RFC 4648 §5）：把 + 換 -、/ 換 _，避免在 URL 中需要再 escape。JWT 用這種
無 padding 版本：省略結尾 =，JWT 也常用
Base32 / Base16（HEX）：類似概念，字元集更小，用於特殊情境（OTP 密鑰常用 Base32）

常見問題

Base64 是加密嗎？

不是。Base64 是「編碼」（任何人都能 decode，無 key），不是「加密」（需 key 才能 decrypt）。用 Base64 包密碼或私鑰不會增加安全性，只是讓人看不懂表面字。真正要保密請用 AES 等加密演算法。

為什麼解碼失敗？

常見原因：（1）字串內有非 Base64 字元（空格、換行、其他符號）；（2）長度不是 4 的倍數且沒 padding；（3）來源是 URL-safe Base64 但用標準 decoder。可以先試刪空白與換行再解。

Base64 可以壓縮資料嗎？

不行，反而會更大。Base64 是編碼，會讓資料長 33%。要壓縮用 gzip / brotli，不是 Base64。

Base64 編碼解碼