什麼是Base64?
Base64 是一種用 64 個可列印字元來表示二進位資料的編碼方式。它最核心的用途，不是保密，而是讓原本不適合直接放進純文字通道的位元組內容，可以安全地穿過郵件、表單欄位、設定片段、JWT 組件、Data URI 或其他只接受文字的邊界。這也是為什麼 Base64 會在 RFC 4648 與 MIME 相關規範裡長期存在，而且直到今天仍然是開發、除錯與內容傳輸場景中的高頻基礎工具。
Base64 編碼演算法原理
Base64 的原理相對直接：它把原始位元組重新切分成適合文字映射的 6 位區塊，再按照固定字元表輸出結果。真正需要說明的，不是演算法複雜度，而是目前處理的到底是原始位元組、文字內容、Base64URL 片段，還是帶 MIME 前綴的 Data URI。
- 將輸入資料拆分為每 3 個位元組一組。
- 把這 3 個位元組共 24 位重新分組為 4 個 6 位區塊。
- 將每個 6 位值（範圍 0-63）映射到 Base64 字元表。
- 如果最後一組不足 3 個位元組，就用 0 位補齊，並在結果尾端加上相應數量的 `=` 作為填充符。
Base64 字元集：A-Z、a-z、0-9、+、/ 填充字元：=
如何使用這個工具
- 先选择是把普通文字编码成 Base64，还是把複製来的 Base64 解码回可读文字。
- 粘贴 UTF-8 文字样本或完整 Base64 字元串，并檢查填充符、字元编码或 URL-safe 差异。
- 確認輸出與预期字节或可见文字完全一致后，再複製结果。
經典示例：Man 為什麼會變成 TWFu
文字 "Man" 的 ASCII 碼：77 97 110
二進位表示：01001101 01100001 01101110
重組為 6 位：010011 010110 000101 101110
十進位值：19 22 5 46
Base64 結果：T W F u簡化的 JavaScript 實作示例
下面這段示例程式碼的重點，不是取代瀏覽器內建 API，而是讓你更直觀地理解 3 位元組到 4 個 Base64 字元的轉換流程。
function encodeBase64Simple(bytes) {
const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
let output = "";
for (let i = 0; i < bytes.length; i += 3) {
const b1 = bytes[i];
const b2 = i + 1 < bytes.length ? bytes[i + 1] : 0;
const b3 = i + 2 < bytes.length ? bytes[i + 2] : 0;
const triplet = (b1 << 16) | (b2 << 8) | b3;
output += alphabet[(triplet >> 18) & 0x3f];
output += alphabet[(triplet >> 12) & 0x3f];
output += i + 1 < bytes.length ? alphabet[(triplet >> 6) & 0x3f] : "=";
output += i + 2 < bytes.length ? alphabet[triplet & 0x3f] : "=";
}
return output;
}常見用途
- MIME 郵件附件或其他需要走純文字傳輸的二進位資料。
- URL 安全變體 Base64URL 場景，例如 JWT header 與 payload 的組成部分。
- 將小型圖片或字型資料以 Data URI 形式嵌入 HTML 或 CSS。
- 在 XML、JSON 或設定片段中攜帶不適合直接暴露的位元組內容。
- 快速檢查複製來的令牌片段、回應載荷或記錄資料是否只是被 Base64 包裝。
進階邊界與常見誤區
真正棘手的 Base64 問題，往往不在演算法，而在邊界上下文：標準 Base64 與 Base64URL 是否混用、Data URI 前綴是否完整、MIME 場景裡的換行是否被保留、以及文字在進入編稫前究竞採用了哪種字元集。這些問題看起來像“解碼失敗”或“結果亂碼”，實際上多半是上下文沒對齊。
- Base64URL 會把 `+`、`/` 替換成 `-`、`_`，有時還省略填充符，所以並不總能直接丟進嚴格的標準 Base64 解碼器。
- Base64 會讓資料體積平均增加約三分之一，因此它換來的是傳輸便利，不是儲存效率。
- Base64 不是加密。任何人只要拿到內容，都能在不需要密鑰的情況下還原原始位元組。
- 大檔案的 Base64 會顏著增加記憶體與處理成本，尤其在瀏覽器與前端載荷裡更就得留意。
- 如果結果最終要進入 Data URI、JWT 或其他特定容器，周遡語法和前綴常常與編碼値本身同樣重要。
Base64 與其他編碼的比較
| 編碼方式 | 特點 | 主要用途 |
|---|---|---|
| Base64 | 使用 64 個可列印 ASCII 字元表示二進位資料 | 郵件附件、Data URI、JWT 組件、二進位資料文字化傳輸 |
| URL 編碼 | 把特殊字元轉成 `%XX` 形式，服務 URL 上下文安全 | 查詢參數、路徑片段、表單提交 |
| 十六進位編碼 | 每個位元組使用兩個十六進位字元表示 | 雜湊值展示、低階位元組檢查、二進位可視化 |
使用注意
- 複用可檢查的 Base64 文字或解码后的普通文字前，先檢查填充符、字元编码、URL-safe 变体、换行，以及内容是否在其他层真正加密。
- Base64 是可逆编码，不是加密；不要把编码或解码结果当作受保护的密钥存储。
- 当结果会影响生产工作或客户可见内容时，應保留原始普通文字、複製来的 Base64 字元串、令牌片段、資料片段和 UTF-8 内容以便回退和核对。
Base64 編碼/解碼 參考說明
Base64 編碼/解碼 重點說明 Base64 是編碼演算法而不是加密，並解釋它為什麼常用於在文字協定中傳輸二進位資料、令牌片段、圖片或設定內容。
- Base64 會把每 3 個原始位元組拼成 24 位，再拆成 4 組 6 位索引，並映射到 64 個可列印字元上。
- 當輸入位元組數不能被 3 整除時，會補 `=` 填充符，使輸出長度保持為 4 的倍數。
- Base64 可逆，不能單獨用於保護密鑰、密碼或隱私資料。
- 處理中文等非 ASCII 文字時要注意字元集，預設使用 UTF-8 最穩妥。
參考資料
常見問題
以下問題圍繞 Base64 編碼/解碼 的實際用途整理，重點說明輸入要求、輸出結果與常見限制。將文字編碼為 Base64，或將 Base64 解碼回可讀文字。
Base64 編碼/解碼 会把文字加密吗？
不会。Base64 是可逆编码，只是為了让二进制或文字内容更容易在面向文字的系統里传输。拿到编码字元串的人都可以把它解回来。
為什么 Base64 編碼/解碼 解码出来的内容有时会乱码？
原因通常是源内容并不是 UTF-8 文字，或者它本来就是二进制資料而不是可读字元。應先確認原始字元集，以及這段内容是否本来就適合按文字解码。
適合用 Base64 編碼/解碼 處理 JWT 片段或接口样本吗？
它可以帮助查看普通 Base64 文字，但 JWT payload 使用的是 Base64URL，而且还涉及认证語義，不能仅按普通解码場景理解。需要查看令牌声明时，應優先使用专门的 JWT 頁面。
Base64 編碼/解碼 最適合處理什麼樣的普通文本、复制来的 Base64 字符串、令牌片段、数据片段和 UTF-8 内容？
Base64 編碼/解碼 的核心用途是把文字编码成 Base64，或把 Base64 解码回可读文字。当普通文字、複製来的 Base64 字元串、令牌片段、資料片段和 UTF-8 内容需要快速变成可檢查的 Base64 文字或解码后的普通文字，并继续用于API payload 核对、令牌檢查、配置清理、邮件源码查看和 Data URI 准备时，它最有价值。
複用 Base64 編碼/解碼 產生的可检查的 Base64 文本或解码后的普通文本前，最該檢查什麼？
應優先檢查填充符、字元编码、URL-safe 变体、换行，以及内容是否在其他层真正加密。這些细节最能直接判断结果是否已经適合继续交给下游流程。
Base64 編碼/解碼 產生的可检查的 Base64 文本或解码后的普通文本通常會被帶到哪裡繼續使用？
最常见的下一步就是用于API payload 核对、令牌檢查、配置清理、邮件源码查看和 Data URI 准备。這類輸出是按真实交接場景来组织的，不是泛化占位结果。
什麼時候不應該直接相信 Base64 編碼/解碼 的結果，而要人工複核？
Base64 是可逆编码，不是加密；不要把编码或解码结果当作受保护的密钥存储。