Base64 編碼解釋:像 Pro 一樣編碼和解碼

我在 toolz。dev 上發布的 Base64 轉換器的第一個版本有一個錯誤 I'我仍然有點尷尬。它在我編寫的每個測試中都完美地工作 - 編碼、解碼、往返、完成。然後有人貼了包含表情符號的文字並得到了這個:

Uncaught DOMException: InvalidCharacterError:
Failed to execute 'btoa' on 'Window': The string to be
encoded contains characters outside of the Latin1 range.

I'd 建構了一個文字編碼工具,但忘記了文字包含,你知道, 大多數文字. 每個非拉丁文字、每個重音字元、每個表情符號 - 都被破壞。我的測試都是 ASCII,因為我認為是 ASCII。這個錯誤比任何規格閱讀都更教會了我關於 Base64 的知識,而 I'稍後會向您展示修復程序,因為它幾乎會絆倒所有接觸過的人 btoa().

Base64 是開發人員每天使用的東西之一 - 在每個 JWT、每個電子郵件附件中 data: URI - 雖然很少看引擎蓋下。 Let'看看引擎蓋下。

TL;DR: Base64 編碼將二進位資料轉換為 64 個安全的 ASCII 字符,因此它可以透過 JSON、URL 和電子郵件等純文字通道傳輸 - 代價是大約 33% 的大小開銷。這是 不是 加密;任何人都可以立即反轉它。要立即編碼或解碼,請使用免費的客戶端 Base64 轉換器 在 toolz。dev 上 - 您的資料永遠不會離開瀏覽器,這在您're 解碼令牌時很重要。

什麼是 Base64 編碼?

Base64 是一種二進位到文字的編碼方案:它僅使用 64 個字元來表示任意字節,這些字元在有史以來建立的每個文字系統中都存在。權威規格是 RFC 4648 (2006),儘管編碼可以追溯到 RFC 1421 和 1993 年的隱私增強郵件 - Base64 比 Web 瀏覽器更古老。

字母表:

• A–Z → 值 0 DOS25
• a–z → 值 26 SY51
• 0–9 → 值 52 DOS61
• + → 62, / → 63
• = → 填充(不是值,只是填充物)

為什麼是這64個?因為它們在 ASCII、EBCDIC 以及有史以來建立的每個電子郵件網關中都完好無損地保存下來。 Base64 是一項和平條約,擁有數十年的純文字基礎設施。

條約的成本:每 3 個輸入位元組變成 4 個輸出字元 - 固定 33% 的大小稅。將這個數字保留在你的腦海中;它決定了真正的架構問題。

Base64 演算法如何運作?

比你更短的答案'd 期望:將 8 的位元重新組合為 6,然後在表中尋找它們。 26 = 64 - 那's 這個名字的由來。

編碼 Hi!:

步驟 1 - 位元組到位元。

連接: 010010000110100100100001- 24 位元。

步驟 2 - 重新組合成 6 位元區塊。

010010 | 000110 | 100100 | 100001
  18   |   6    |   36   |   33

步驟 3 - 尋找字母表中的每個值。

18 → S, 6 → G, 36 → k, 33 → h. 所以 Hi! 編碼為 SGkh.

那'是整個演算法。除了查找表之外沒有數學。

填充 處理 3 位元組的 3 乘以 39;t 的輸入。僅編碼 Hi (2 位元組 = 16 位元)並且只能填入兩位和一位 6 位元組;編碼器對位元進行零填充並附加 = 表明填充量是多少:

Hi  → SGk=    (2 bytes remaining → one '=')
H   → SA==    (1 byte remaining  → two '==')
Hi! → SGkh    (multiple of 3     → no padding)

當我在 toolz。dev 轉換器上實現這一點時,填充是我所有一次錯誤所在的地方。如果您曾經手動滾動 Base64(例如,用於編碼面試),請先編寫填充測試。

解碼是鏡像:字元回到 6 位元值,重新組合成 8 位元位元組,刪除填充。

你實際上跑進 64 號基地哪裡?

JWT--最大的

每個 JSON Web 令牌都是三個 Base64URL 編碼的段,透過點連接:標頭、有效負載、簽名。調試授權是 50% 解碼這些。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

解碼第一段,你就得到了 {"alg":"HS256","typ":"JWT"}. 第二個給你索賠。當令牌行為不當時,我的工作流程是:在點處分割,解碼其中的每個部分 Base64 轉換器,然後將 JSON 貼到 json 格式化程式 正確閱讀它。兩個糊狀物,你知道是否 exp 索賠是你的問題。

值得一提的是:JWT 有效載荷是 任何持有代幣的人都可以閱讀. 簽名停止篡改,而不是閱讀。 I'已經審查了將敏感資料塞進聲明中的程式碼庫,因為胡言亂語的外觀暗示了隱私。它沒有't。

數據 URI

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

內聯嵌入小型資產可節省 HTTP 請求。我建立圖像密集型 WordPress 管理 UI 的經驗法則:價值低於 ~5 KB,超過 10 KB you'無論如何,要保存請求 HTTP/2 多路復用,請將文件膨脹 33%。

庫伯內特的秘密 - 和咆哮

apiVersion: v1
kind: Secret
data:
  password: cGFzc3dvcmQ=   # decodes to "password"

Kubernetes 的秘密是由 Base64 編碼的,這意味著錯誤的安全性令人震驚。該值以一個貼上進行解碼。這裡的 Base64 存在,因此二進位值在 YAML - a 中倖存下來 格式化 決定,而不是安全決定。如果你的秘密故事在 "they're Base64 in etcd,"它已經't開始了。

清單的其餘部分

HTTP 基本 Auth 標頭 (Authorization: Basic dXNlcjpwYXNz 解碼為普通 user:pass- 因此僅限 HTTPS)。透過 MIME 發送電子郵件附件。 JSON 有效負載內的二進位 blob,因為 JSON 沒有二進位類型。

Base64 加密嗎? (不,請,不。)

值得自己分一杯羹,因為這種誤解不會消失。

Base64 是一個 代表,就像用十六進制寫一個數字一樣。沒有鑰匙。沒有秘密。解碼只需要 RFC 4648 中公開列印的字母表。任何 Base64-"受保護&引用;就像用草書書寫字母一樣受到保護。

如果資料需要機密性:正確加密(AES-GCM 或 libsodium), 然後 如果通道需要文本,Base64 會對密文進行編碼。編碼和加密組成很好 - 它們只是't 替代品。如果您需要完整性而不是保密性,則 's 雜湊's 工作 - 哈希產生器 涵蓋 SHA-256 和朋友。

Base64 與 Hex、URL 編碼和 Base85 相比如何?

我如何選擇: 十六進位 當人類讀取或比較輸出時 - 校驗和、摘要、任何透過眼球調試的內容。 百分比編碼 對於 URL 文本,絕不是二進位。 基地64 對於二進位交叉文字通道 - 大多數真實情況。 ASCII85 從來不是自願的; 8% 的節省尚未證明相容性問題的合理性。

什麼是 URL-Safe Base64 以及為什麼它存在?

標準 Base64 有一個問題: + 意思是&引用;空間&引用;在查詢字串中, / 是路徑分隔符號, = 界定參數。在 URL 中放置一個標準 Base64 令牌,某個中間件會在某個地方損壞它 - 間歇性地,並且僅在生產中。問我怎麼知道。

RFC 4648 第 5 節定義了修復,通常稱為 Base64URL:

相同的演算法,交換兩個字符,刪除填充。 JWT 專門使用 Base64URL - 這正是為什麼將 JWT 段貼上到嚴格的標準 Base64 解碼器中有時會在雜散上失敗的原因 - 或者 _. 的 toolz。dev 轉換器 處理這兩種變體,因為拒絕現實世界 Base64 一半的解碼器是 '解碼器的大部分。

經驗法則:如果編碼的字串會觸及 URL、檔案名稱或 HTTP 標頭,請從一開始就使用 URL 安全變體。改造是尋找和替換加上祈禱。

如何在程式碼中進行編碼和解碼?

JavaScript - 我陷入的陷阱

這裡'是我發貨的樸素版本:

btoa('Hello')      // "SGVsbG8=" — great!
btoa('café ☕')    // InvalidCharacterError — the bug from my intro

btoa 早於現代 Unicode 處理,僅接受 Latin-1。正確的現代方法明確地通過 UTF-8 位元組:

// Encode: string → UTF-8 bytes → Base64
const bytes = new TextEncoder().encode('café ☕');
const encoded = btoa(String.fromCharCode(...bytes));   // "Y2Fmw6kg4piV"

// Decode: Base64 → bytes → string
const decoded = new TextDecoder().decode(
  Uint8Array.from(atob(encoded), c => c.charCodeAt(0))
); // "café ☕"

(在 Node。js 中,跳過儀式: Buffer.from(str, 'utf8').toString('base64').)

蟒蛇

import base64

encoded = base64.b64encode('café ☕'.encode('utf-8')).decode('ascii')
decoded = base64.b64decode(encoded).decode('utf-8')

# URL-safe variant — note -_ instead of +/
token = base64.urlsafe_b64encode(b'binary\xfb\xff').decode('ascii')

Python 讓正確的事情變得顯而易見:你 必須的 傳遞字節,因此編碼到 UTF-8 的步驟可以'被遺忘。我希望 btoa 設計有相同的書脊。

PHP

$encoded = base64_encode('café ☕');   // handles bytes as-is — PHP strings ARE bytes
$decoded = base64_decode($encoded);

// URL-safe requires manual translation — a WordPress-plugin-developer classic:
$urlSafe = rtrim(strtr($encoded, '+/', '-_'), '=');

那個 strtr/rtrim line 出現在每個 PHP 程式碼庫 I&#39 中;曾經工作過,包括 WP Adminify。 PHP 從未獲得內建 URL 安全變體,因此我們都繼續編寫相同的兩行。

常見問題

base64 編碼用途是什麼？

它將二進位資料轉換為 ASCII 文本,以便它可以通過僅處理文字的系統:JSON 有效負載、URL、電子郵件 (MIME)、HTTP 標頭。您最常在 JWT 代幣中遇到它, data: 用於內聯影像、Kubernetes Secrets 和攜帶檔案的 API 有效負載的 URI。 It'是一種傳輸格式,而不是儲存或安全格式。

Base64 和加密一樣嗎?

不,混淆兩者會導致真正的安全事件。 Base64 沒有金鑰 - 解碼只需要公共字母表,並且可以將一個貼上到任何一個中 解碼器. 首先使用真實演算法(AES-GCM)加密,然後在通道需要文字時對密文進行編碼。

為什麼 Base64 讓資料增加 33%?

每個 Base64 字元攜帶 6 位元訊息,但佔用完整的 8 位元組,因此 3 位元組的輸入始終變成 4 個輸出字元 - 4/3 & 1.33。 It'格式的固定成本,在設計上是不可避免的。如果大小很重要,請在編碼前壓縮,而不是在編碼後壓縮 - 編碼輸出看起來隨機且壓縮嚴重。

什麼'base64 和 Base64URL 之間的差異?

Base64URL 交換 + 對於 - 和 / 對於 _,並且通常會掉落 = 填充,因此輸出可以保留 URL、檔案名稱和標頭而不會轉義。 RFC 4648 第 5 節中定義的相同演算法。JWT 專門使用 Base64URL - 這就是為什麼嚴格的標準 Base64 解碼器有時會卡住它們。

為什麼 btoa () 會拋出 InvalidCharacterError?

您的字串包含 Latin-1 以外的字元 - 表情符號、重音字元、任何非西方腳本。 btoa 是一個 20 世紀 90 年代的 API,早於合理的 Unicode 處理。首先編碼為 UTF-8 位元組 TextEncoder64 位元組;我在生產工具中運送了這個確切的錯誤,所以沒有判斷力。

如何判斷字串是否為 Base64?

有效 Base64 僅使用 A–Z, a–z, 0–9, +, / (或者 -, _ 對於 URL 安全性),可選尾隨 =,長度為 '填充時為 4 的倍數。但很多普通單字也與這種模式相符 - cafe 是有效的 Base64,可以解碼為垃圾位元組。真正的測試是對其進行解碼並檢查輸出是否有意義。

為什麼我的 Base64 字串末尾有雜散換行符?

因為 echo 之前加一個 base64 曾經見過它,所以 echo "hunter2" | base64 編碼八個字節,而不是七個。使用 printf 或者 echo -n 相反。這是 Kubernetes Secrets 在清單中看起來正確並在運行時失敗的首要原因:解碼的密碼帶有不可見的尾隨 \n. 的 base64 命令還在某些系統上以 76 列包裝輸出 - 通過 -w 0 在 GNU coreutils 上抑制它。

如何手動解碼 JWT 代幣?

將令牌的兩個點分開,取第一段(標頭)和第二段(有效負載),並逐個運行 Base64 解碼器- 他們're Base64URL,所以使用一個可以接受的工具 - 和 _. 然後將產生的 JSON 格式化為 a JSON 格式化程式 閱讀聲明。切勿將生產代幣貼上到伺服器端工具中;僅限客戶端。

如何將影像或檔案編碼到 Base64?

將檔案讀取為位元組,然後讀取這些位元組的 Base64,並在 data-URI 標頭之前添加類似 data:image/png;base64, 所以瀏覽器可以將其內聯。在 JavaScript 中, FileReader.readAsDataURL() 為您執行這兩個步驟;在命令列上, base64 logo.png 列印原始編碼。將其保留給小型資產 - 33% 的規模稅使得 Base64 不太適合任何大型資產,而大數據 URI 會破壞您的 HTML 或 CSS。

如何在 JavaScript、Python 或終端機中解碼 Base64?

在現代 JavaScript 中,安全地解碼 Unicode new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))) 而不是裸露 atob. 在Python中, base64.b64decode(str) 傳回位元組 - 呼叫 .decode('utf-8') 對於文字。在終端機中, echo "aGk=" | base64 -d (或者 --decode).這三者都期待標準 Base64,所以翻譯一下 -/_ 回到 +// 首先,如果您'正在處理 Base64URL 字串。

外賣

Base64 是一種已有 30 年歷史的位元洗牌技巧,它悄悄地支撐著現代網路的一半 - auth 令牌、附件、內聯資產、aren&#39 的秘密;t-secret。了解 6 位元重組,尊重 33% 的稅,永遠不會誤認為加密,並在涉及 URL 的任何地方存取 URL 安全變體。那'實際掌握 Base64 的 95%。

對於動手部分, toolz。dev 上的 Base64 轉換器 完全在瀏覽器中進行標準和 URL 安全編碼 - 由透過艱苦方式學習 Unicode 課程的人構建,因此您不必這樣做 '。

本系列中的更多內容:完整 編碼工具指南 涵蓋日常駕駛員實用程式的其餘部分 正規表示式建構器指南 解決開發人員假裝擁有的其他技能,並且由於 Base64 調試的一半以 JSON 結束,因此 終極 JSON 工具指南 是自然的下一篇閱讀。

相關文章:

• 編碼工具完整指南
• JSON 工具終極指南 (2026)
• 如何在線上格式化 JSON
• 正規表示式產生器指南