Base64 要解決什麼問題

很多系統只傳「文字」：郵件協定為 7 位元 ASCII 設計，JSON 定義為文字，HTML 屬性裡放的是字串。但我們真正想傳輸的東西——圖片、PDF、金鑰、二進位協定資料——是位元組串流，裡面很容易混進控制字元、引號與換行。

把原始二進位直接塞進文字通道，遲早會出問題：換行被改寫、引號提前結束字串、代理伺服器吃掉一個位元組。Base64 的做法是：只用 64 個所有文字系統都認得的字元重新表示這些位元組。

A–Z  a–z  0–9  +  /

結尾的 = 只用於補齊。整個字母表就這些。

Base64 的原理

Base64 每處理 3 個位元組（24 位元），就把他們重寫成 4 個字元（4 × 6 位元）：

輸入 位元數 輸出
Man 24 位元 TWFu
Ma 16 位元 + 補齊 TWE=
M 8 位元 + 補齊 TQ==

由此直接得到兩個結論：

  1. 結果大約比原文大 33%（3 個位元組變成 4 個字元）
  2. = 的數量告訴解碼器最後一組缺了幾個位元組，一個或兩個 = 表示結尾不完整

Base64 是可逆的、完全公開的編碼，沒有金鑰，也沒有任何保密性。

日常開發中在哪裡遇到 Base64

  • Data URI：background-image: url(data:image/png;base64,...) 把小圖示直接內嵌進 CSS
  • JSON 介面：在 JSON 欄位裡傳檔案、縮圖或簽章
  • 郵件附件：MIME 用 Base64 編碼附件，讓它們能穿過只支援文字的郵件伺服器
  • HTTP Basic 認證：Authorization: Basic dXNlcjpwYXNz 就是 user:pass 的編碼結果
  • JWT：Token 的 header 與 payload 兩段都是 Base64URL 字串

Base64 不是加密

這是最重要的一點：Base64 不提供任何保密性。

任何人拿到 Base64 字串，打開瀏覽器主控台一行就能還原——不需要金鑰，也不需要工具。編碼解決的是「怎麼傳」，加密解決的是「給誰看」。需要保密就用 TLS 傳輸加上真正的加密（AES-GCM、libsodium、age 等），需要文字通道時再對密文做 Base64。

怎麼線上編解碼

不用裝任何東西。本站的 Base64 線上編解碼工具 完全在瀏覽器本機執行，不上傳資料，離線也能用。

  1. 選擇「編碼」或「解碼」
  2. 把文字或 Base64 字串貼到輸入框
  3. 點「開始轉換」（或按 Ctrl／⌘ + Enter）
  4. 複製或下載結果

因為工具是純 HTML、沒有後端，處理內部 ID、設定片段、日誌片段都沒問題；但生產環境的金鑰不要貼進任何你不掌控的線上工具。

五個常見陷阱

1. URL-safe Base64 用的是另一套字母表。 標準 Base64 含 + 和 /，它們在 URL 裡有意義；URL-safe 版本（RFC 4648 §5）會換成 - 和 _。如果解碼器莫名奇妙報錯，先看字母表。

2. 補齊的 = 有時被省略。 不少編碼器會去掉結尾的 = 省空間，解碼時需要自己推斷缺少的位元組。多數函式庫能處理，嚴格的函式庫會直接丟出錯誤。

3. 換行與空白。 經典 MIME 輸出每 76 個字元換行。多數解碼器會忽略 \n 與空白（我們的工具也會），但不要假設所有解碼器都這樣。

4. btoa() 不認得 UTF-8。 瀏覽器裡 btoa('中文') 會丟出 InvalidCharacterError，因為 btoa 只接受 Latin-1。正確做法是先用 TextEncoder 把字串轉成 UTF-8 位元組，再編碼。可靠的工具都替你做了這件事。

5. 重複編碼。 對已經是 Base64 的內容再編碼一次，會得到一層「看起來合法但沒有意義」的結果。如果解碼出來仍是亂碼，多半是編碼了兩遍，或者你編碼的原來就不是文字資料。

常見問題

Base64 會讓資料變大多少？ 壓縮前大約 33%。1 MB 的圖片會變成約 1.37 MB 的文字。

能手工解碼嗎？ 理論上可以，它就是一份 6 位元對照表；實際上用工具更快。

Base64 會壓縮資料嗎？ 不會，它會膨脹。想要更小的體積，先壓縮（gzip、Brotli、zstd）再編碼。

Base64 能直接放進 URL 嗎？ 只有 URL-safe 字母表可以，否則還要再做一次百分比編碼——我們的 URL 編解碼工具 正是做這個的。

相關閱讀