首頁
相關知識
Base64 藏在哪裡？從 Email 附件到 JWT Token，你每天都在用卻不知道的編碼…
發布於 2026-05-15

Base64 藏在哪裡？從 Email 附件到 JWT Token，你每天都在用卻不知道的編碼技術

Base64 JWT Email附件 編碼原理 資料格式 前端開發 API設計 JSON Data URL 工程師

如果你打開瀏覽器的開發者工具，隨便找一個網站的網路請求，幾乎可以肯定你會看到某個地方出現一長串 Base64 字串——Authorization header 裡的 Bearer token、CSS 裡的 data URL、或是 API 回傳的圖片欄位。Base64 無所不在，但很多開發者對它的認識停留在「把東西變成亂碼」，這個理解其實差了一截。

一、Base64 是什麼？先從「為什麼需要它」說起

電腦內部所有資料都是二進位（0 和 1），但很多早期的通訊協定（SMTP、HTTP/1.1）在設計時只考慮了純文字（ASCII 字元）的傳輸。當你要傳送圖片、PDF、或任何二進位資料時，這些協定就無法正確處理。

Base64 解決這個問題的方式很直接：把每 3 個 byte（24 bits）的二進位資料，重新分組成 4 個 6-bit 數字，再用一個 64 個字元的字母表（A–Z、a–z、0–9、+、/）來表示。結果是：任何二進位資料都可以用純文字字元表達。

特性說明
字元集A–Z（26）、a–z（26）、0–9（10）、+、/，共 64 個字元
填充字元=，用來對齊 3 的倍數
大小膨脹原始資料增加約 33%
用途讓二進位資料可在純文字管道安全傳輸
直接試試看：Base64 編解碼工具可以把任意文字或資料編碼成 Base64，或把 Base64 字串還原成原始內容。

二、Base64 藏在你每天收到的 Email 裡

電子郵件使用的 SMTP 協定原本只支援 7-bit ASCII 文字。要在 Email 裡傳送附件（圖片、PDF、Word 檔）需要一個叫 MIME（Multipurpose Internet Mail Extensions） 的標準，而 MIME 附件通常就是用 Base64 編碼的。

你可以在任何 Email 用戶端「查看原始郵件」，會看到類似這樣的內容：

Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAABHNCSVQICAgI
fAhkiAAAAAlwSFlzAAAApgAAAKYB3X3/OAAAABl0RVh0U29mdHdhcmUAd3d3
...

那一長串看起來像亂碼的文字，就是被 Base64 編碼過的圖片檔案。MIME 協定把整個檔案切成每行 76 個字元的 Base64 文字，讓 SMTP 可以正確傳輸。

三、JWT Token：登入系統裡最常見的 Base64

如果你用過任何需要登入的網站或 API，十之八九碰過 JWT（JSON Web Token）。JWT 的格式是三段 Base64 用 . 分隔：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyMTIzIiwiZXhwIjoxNzQ4MDAwMDAwfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

把第一段貼進 Base64 解碼器，你會得到：

{"alg":"HS256","typ":"JWT"}

第二段解碼後：

{"sub":"user123","exp":1748000000}

JWT 的 header 和 payload 都只是 Base64url 編碼的 JSON（Base64url 是 Base64 的變體，用 - 和 _ 代替 + 和 /，避免在 URL 裡需要 percent encoding）。第三段才是簽名，用來驗證前兩段有沒有被竄改。

重要觀念：JWT 的前兩段沒有加密，任何人都可以解碼閱讀。這就是為什麼 JWT 裡不應該放密碼或敏感資料——只能放伺服器用來辨認你身份的資訊（如 user ID、角色、到期時間）。

解碼 JWT：把 JWT 的第一或第二段（兩個 . 之間的部分）貼入Base64 解碼工具，可以直接看到 JSON 內容。解碼後貼入JSON 格式化工具，可以更清楚地閱讀結構。

四、Data URL：CSS 和 HTML 裡內嵌的圖片

網頁裡有一種特殊的 URL 格式，叫 Data URL，可以把整個檔案直接內嵌在 HTML 或 CSS 裡，不需要額外發送一個 HTTP 請求：

<img src="data:image/png;base64,iVBORw0KGgo...">

/* 或在 CSS 裡 */
.icon {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxu...");
}

這個技術在以下情況很常見：

  • Email 範本：避免圖片被 Email 用戶端封鎖
  • 小圖示：減少 HTTP 請求數量（在 HTTP/1.1 時代效果明顯，HTTP/2 後較少用）
  • 離線應用：把必要資源打包進 HTML 本身
  • 單一 HTML 檔案：讓整個網頁可以用一個檔案完整分享

五、Authorization Header：API 認證裡的 Base64

HTTP 的基本認證（Basic Auth）也用 Base64，格式是把 username:password 直接 Base64 編碼：

Authorization: Basic dXNlcjpwYXNzd29yZA==

把 dXNlcjpwYXNzd29yZA== 解碼，得到 user:password。

注意：Basic Auth 的 Base64 不是加密，任何人攔截到這個 header 都可以立刻解碼。這也是為什麼 Basic Auth 必須配合 HTTPS 使用，否則等同於明文傳送密碼。

六、Base64 常見的誤解

誤解 1：Base64 是加密

完全不是。Base64 是編碼，不是加密。它只是換了一種表示方式，任何人都可以立刻解碼，不需要任何金鑰。真正的加密（如 AES）才會讓資料在沒有正確金鑰的情況下無法讀取。

誤解 2：Base64 可以壓縮資料

相反，Base64 會讓資料增加約 33%。3 bytes 的原始資料會變成 4 個 Base64 字元。這是用可讀性換取了大小，在需要傳輸效率的情況下要特別注意。

誤解 3：Base64 字串末尾的 = 是加密填充

那是對齊填充，不是加密。Base64 每次處理 3 bytes，如果原始資料的長度不是 3 的倍數，就用 = 補齊到 4 個字元的倍數。1–2 個 = 代表補了 1–2 個空 byte。

URL 裡的 Base64 要額外處理：標準 Base64 的 + 和 / 在 URL 裡有特殊意義，需要 percent encoding。如果你在 URL 裡看到 Base64 字串，通常會是改用 - 和 _ 的 Base64url 變體。URL 編解碼工具可以幫你處理 URL 裡的特殊字元。

七、什麼時候該用 Base64，什麼時候不該用

適合用 Base64不適合用 Base64
在純文字協定裡傳輸二進位資料（Email 附件、JWT、Basic Auth）需要加密時（用 AES 等真正的加密演算法）
把資源內嵌進 HTML/CSS（Data URL）大型資料（傳輸大小會增加 33%）
讓二進位資料可以安全放進 JSON 字串欄位希望混淆或隱藏資料（Base64 任何人都能解碼）

總結

  • Base64 把二進位資料轉成 64 個純文字字元，讓它可以在只支援文字的協定裡傳輸
  • Email 附件（MIME）、JWT Token、Data URL、Basic Auth 都是 Base64 最常見的應用
  • JWT 的 header 和 payload 只是 Base64url 編碼，沒有加密——任何人都可以解碼
  • Base64 不是加密，也不會壓縮資料，大小反而增加 33%
  • 在 URL 裡需要用 Base64url 變體（- 和 _ 代替 + 和 /）

相關工具

Base64 編解碼 JWT 解碼器 URL 編解碼 AES 加解密
← 回到知識庫