Base64

兩種編碼，兩個任務 Base64 和 URL 編碼都會把「不安全」的字元替換成安全字元。這種表面相似，正是它們經常被搞混的原因——要嘛該用一種卻用了兩種，要嘛乾脆用錯了。 一句話版本： Base64 讓二進位資料能通過只支援文字的通道 百分比編碼 讓文字能安全地放進 URL 各自到底做了什麼 Base64 用 64 個字元的字母表（A–Z a–z 0–9 + /，結尾用 = 補齊）重寫位元組。每 3 個位元組變成 4 個字元，體積因此增加約 33%。 Man → TWFu Hello → SGVsbG8= 百分比編碼把在 URL 裡不安全的字元替換成 % 加兩個十六進位數字（對應 UTF-8 位元組）。 a b → a%20b 書籤管理 → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86 a&b → a%26b 關鍵差別 Base64 百分比編碼 目的 讓二進位穿過文字通道 讓文字安全地待在 URL 裡 字元集 固定的 64 個字元 任意位元組，寫成 %XX 體積變化 +33% 變化很大 誰能還原 任何人 任何人 提供安全性 否 否 常見位置 JSON 欄位、data URI、郵件附件、JWT 查詢參數、路徑片段 什麼時候用 Base64 把小型圖片以 data URI 內嵌進 CSS 或 HTML 在 JSON 裡傳檔案、縮圖或簽章 透過 MIME 寄送郵件附件 構造 Authorization: Basic 請求標頭 JWT 的 header 與 payload 段 需要雙向轉換時，直接用 Base64 編解碼工具，不用裝任何東西。 ...

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== 由此直接得到兩個結論： 結果大約比原文大 33%（3 個位元組變成 4 個字元） = 的數量告訴解碼器最後一組缺了幾個位元組，一個或兩個 = 表示結尾不完整 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 不提供任何保密性。 ...