Base64 不是加密：原理、誤區與開發中的實際用途

先說結論：Base64 不是加密

打開任何一個 Base64 解碼工具，把一段 Base64 字符串粘進去，瞬間就能還原原始內容。這說明一件事：Base64 沒有密鑰，任何人都能解碼，它根本不是加密。

但在實際開發中，仍有大量代碼把 Base64 當作"輕量加密"來用——把用戶信息 Base64 編碼後存入 Cookie，或者把 Base64 當作接口參數的"保護"手段。這是一個危險的誤區。

本文從原理層面說清楚 Base64 到底是什麼，以及它真正適合用在哪裏。

Base64 的本質：二進制轉可見字符

Base64 是一種編碼方式，不是加密算法。它的目的只有一個：把任意二進制數據轉換成只包含可打印 ASCII 字符的字符串。

爲什麼需要這個轉換？因爲很多早期協議（比如電子郵件的 SMTP、HTTP 頭部）只能傳輸純文本，無法直接傳輸二進制數據。Base64 就是爲了解決這個兼容性問題而生的。

編碼字符集

Base64 使用 64 個字符來表示數據：

A-Z（26個）+ a-z（26個）+ 0-9（10個）+ +（1個）+ /（1個）= 64個字符

末尾用 = 作爲填充符，確保編碼結果長度是 4 的倍數。

編碼原理

Base64 的核心思路是：每 3 個字節（24位）的二進制數據，重新分組爲 4 個 6 位的組，每組對應一個 Base64 字符。

以字母 Man 爲例：

原始字符:    M         a         n
ASCII值:     77        97        110
二進制:      01001101  01100001  01101110

重新分組（每6位）:
010011  010110  000101  101110

對應Base64字符:
T       W       F       u

結果: TWFu

由於 3 字節變成 4 字符，Base64 編碼後的數據體積會增大約 33%。

和加密的本質區別

一句話：Base64 是給數據"換一套衣服"，加密是給數據"上一把鎖"。 換衣服人人都能換回來，上鎖必須有鑰匙才能打開。

Base64 真正適合用在哪裏

1. JWT（JSON Web Token）

這是目前最常見的 Base64 使用場景之一。JWT 由三部分組成，每部分都是 Base64URL 編碼（Base64 的變體，用 - 和 _ 替換 + 和 /，去掉末尾 =）：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

把第一段解碼：{"alg":"HS256","typ":"JWT"}，第二段：{"sub":"1234567890"}。

JWT 的安全性不靠 Base64，而靠第三部分的簽名（使用密鑰生成的 HMAC 或 RSA 簽名）。Base64 在這裏只是爲了讓 JSON 數據能安全地放在 HTTP 頭部傳輸。

⚠️ 這意味着 JWT 的 payload 是公開可讀的，不要把密碼等敏感信息放進 JWT payload。

2. 在 HTML/CSS 中嵌入圖片

把圖片轉成 Base64 後，可以直接寫進 HTML 或 CSS，不需要額外的 HTTP 請求：

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

.icon {
  background-image: url('data:image/svg+xml;base64,PHN2ZyB4bWxu...');
}

適合場景： 小圖標、loading 動畫、郵件模板（郵件客戶端通常屏蔽外鏈圖片）。

不適合場景： 大圖片。Base64 比原始二進制大 33%，會顯著增加頁面體積，影響加載速度。

3. 在 JSON / XML 中傳輸二進制數據

JSON 只能包含文本，不能直接包含二進制數據（比如文件內容、圖片字節）。把二進制數據 Base64 編碼後，就可以作爲字符串字段放入 JSON：

{
  "filename": "report.pdf",
  "content": "JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwov..."
}

很多文件上傳 API、AI 模型的圖片輸入接口都採用這種方式。

4. HTTP Basic 認證

HTTP Basic Auth 的認證信息格式是：

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

解碼後是 username:password。注意這完全可以被解碼，所以 Basic Auth 必須配合 HTTPS 使用，否則等於明文傳輸密碼。

5. 電子郵件附件

這是 Base64 的歷史起源場景。MIME 標準規定附件內容用 Base64 編碼，以便在只支持 ASCII 的郵件協議中傳輸二進制文件。

常見錯誤用法

❌ 用 Base64 "加密"用戶密碼

// 錯誤示例
const encoded = btoa(password); // 完全不安全

任何人拿到這個字符串，調用 atob() 就能還原。密碼應該用 bcrypt、Argon2 等哈希算法處理，而不是 Base64。

❌ 用 Base64 "隱藏" API 密鑰

把 API Key 存成 Base64 放在前端代碼裏，並不會讓它更安全。攻擊者找到字符串後一秒鐘解碼。API 密鑰應該放在後端環境變量中，永遠不要暴露在前端。

❌ 對大文件使用 Base64 傳輸

Base64 會讓數據體積增大 33%，對幾 MB 以上的文件，應該使用 multipart/form-data 直接傳輸二進制，而不是 Base64 編碼。

在線工具

需要快速編解碼 Base64，或者把圖片轉成 Base64 字符串，可以使用 toolshu.com 的 Base64 在線編解碼工具。支持 UTF-8、GBK、Big5 等多種字符編碼，中文內容也能正確處理，所有操作在瀏覽器本地完成，不上傳數據。