兩種編碼，兩個任務

Base64 和 URL 編碼都會把「不安全」的字元替換成安全字元。這種表面相似，正是它們經常被搞混的原因——要嘛該用一種卻用了兩種，要嘛乾脆用錯了。

一句話版本：

  • Base64 讓二進位資料能通過只支援文字的通道
  • 百分比編碼 讓文字能安全地放進 URL

各自到底做了什麼

Base64 用 64 個字元的字母表（A–Z a–z 0–9 + /，結尾用 = 補齊）重寫位元組。每 3 個位元組變成 4 個字元，體積因此增加約 33%。

Man     → TWFu
Hello   → SGVsbG8=

百分比編碼把在 URL 裡不安全的字元替換成 % 加兩個十六進位數字（對應 UTF-8 位元組）。

a b            → a%20b
書籤管理        → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86
a&b            → a%26b

關鍵差別

Base64 百分比編碼
目的 讓二進位穿過文字通道 讓文字安全地待在 URL 裡
字元集 固定的 64 個字元 任意位元組，寫成 %XX
體積變化 +33% 變化很大
誰能還原 任何人 任何人
提供安全性 否 否
常見位置 JSON 欄位、data URI、郵件附件、JWT 查詢參數、路徑片段

什麼時候用 Base64

  • 把小型圖片以 data URI 內嵌進 CSS 或 HTML
  • 在 JSON 裡傳檔案、縮圖或簽章
  • 透過 MIME 寄送郵件附件
  • 構造 Authorization: Basic 請求標頭
  • JWT 的 header 與 payload 段

需要雙向轉換時，直接用 Base64 編解碼工具，不用裝任何東西。

什麼時候用百分比編碼

  • 查詢參數的值裡含有 &、=、#、?、空白或非 ASCII 字元
  • 檔名或 slug 要放進路徑
  • 把一個 URL 當作另一個 URL 的參數傳遞（重複編碼的 bug 就出在這裡）

URL 編解碼工具 用的是 encodeURIComponent，正是處理參數值時需要的行為。

三種最常見的陷阱

1. 該用百分比編碼的地方用了 Base64。 Base64 裡有 + 和 /，直接放進查詢字串時，很多解析器會把 + 當成空白。解決辦法：用 URL-safe 字母表（- 和 _），或者對結果再做一次百分比編碼。

2. 重複編碼。 對已經編碼過的內容再編碼一次，會得到一層「看起來合法但毫無意義」的結果。典型特徵是開頭出現 %25（%25 就是 %）。

3. 把兩者當成加密。 兩者都可以在沒有任何金鑰的情況下還原。需要保密就先加密，再編碼。

我這種情況該用哪個？

只問一個問題：目標位置是 URL，還是文字容器？

  • URL（查詢字串、路徑）→ 百分比編碼
  • 文字容器（JSON、HTML 屬性、郵件本文、CSS）→ 內容是二進位就用 Base64，否則保持純文字

兩個工具放一起試

常見問題

能先 Base64 再放進 URL 嗎？ 可以，但要先對 Base64 結果做百分比編碼（或者直接用 Base64URL），否則 +、/、= 會出問題。

百分比編碼一定比 Base64 長嗎？ 通常是。中文按 UTF-8 百分比編碼後，一個漢字要 9 個字元，遠超 Base64 的 33% 開銷。

兩者會壓縮資料嗎？ 都不會。想減小體積先壓縮（gzip／Brotli），再編碼。

密碼該用哪種？ 都不用。用密碼管理器加上真正的加密——編碼不等於保護。

相關閱讀