Base64 編碼詳解：何時有用，何時有害 | Toolars

Base64 是把任意位元組寫成純文字的標準方式。64 個可列印字元——A–Z、a–z、0–9，外加 + 和 /——代表六位一組的資料，因此每三個輸入位元組恰好變成四個輸出字元。這個映射沒有任何祕密，也絕不會比原始資料更小。

公開字母表字母表是固定且公開的；任何人用任何語言的一行程式碼都能解碼 Base64 字串，這正是它可互通的原因。
沒有保密性它不是加密：沒有金鑰、沒有保密性、沒有存取控制——任何人把訊息貼進解碼器就能讀出內容。
絕不會更小它也不是壓縮：輸出總是比輸入大，絕不會更小，因為六位資料要裝進八位字元裡傳輸。

因為三位元組變成四字元，Base64 輸出恆為輸入的三分之四——未計填充約大 33%。一張 900 KB 的圖片會變成約 1.2 MB 文字，這份膨脹會跟著資料走到每一處。

線路上傳輸成本：嵌入 HTML 或 CSS 的 Data URL 以文字形式被下載、解析與快取，每次頁面載入都要多付這三分之一。
記憶體中記憶體與儲存成本：攜帶 Base64 欄位的 JSON 或 XML 負載以字串形式駐留，有些管線還會把值存兩份——一份編碼、一份解碼。
信箱裡郵件會放大它：為傳輸而 Base64 編碼的附件在線路上膨脹三分之一，所以 25 MB 的附件上限實際只意味著約 18 MB 的檔案。

Base64 存在的理由是許多通道只能傳文字。郵件標準寫於七位元 ASCII 時代，JSON 裝不下原始位元組，URL 遇到二進位資料就會斷裂——於是一種位元組安全的文字表示就成了橋樑。

Data URLData URL 把小素材內嵌：data:image/png;base64,… 讓圖示或微小佔位圖隨 CSS 或 HTML 一起傳輸，省去一次額外請求。
郵件與 MIME郵件附件依賴 Base64，因為 SMTP 是為文字設計的；MIME 把二進位部分編碼，使其在每一跳中繼中完好無損。
權杖與憑證權杖與憑證——JWT 分段、PEM 檔案、HTTP Basic 憑據——使用 Base64 或其 URL 安全變體，讓二進位結構適配文字協定。

編碼後的樣子看似難以辨認，因此常被誤當作保護。它不是：解碼輕而易舉、瞬間完成、不需要任何憑據。把編碼後的祕密當作安全，是已提交程式碼與日誌中憑據外洩最常見的原因之一。

任何人都能讀設定檔裡 Base64 編碼的密碼，只是多了幾步的明文密碼；任何有讀取權限的人都已經擁有了祕密。
仍然是憑據出現在 URL、截圖與錯誤報告中的編碼權杖仍然是憑據——要像對待原始值一樣把它們抹掉。
用真正的保護真正的保護意味著用金鑰加密、用雜湊做校驗，或者乾脆不暴露這個值；編碼永遠無法替代其中任何一項。

大多數 Base64 故障都是方言問題。經典字母表用 + 和 / 並以 = 填充；URL 安全變體換成 - 和 _ 且常常省略填充；MIME 每 76 個字元折行。期望一種方言的解碼器會拒絕另一種，而錯誤訊息很少說明它想要哪一種。

字母表不匹配字母表不匹配：含 - 或 _ 的 URL 安全字串會被嚴格的經典解碼器拒絕，反之經典 + 和 / 也會破壞 URL 安全處理。
填充缺少填充：帶填充的方言要求長度是四的倍數，被剝掉的 = 尾巴會讓嚴格解析器失敗，即使資料完好無損。
雜散字元雜散字元：MIME 折行、開頭的 data:…;base64, 前綴，或從郵件客戶端貼來的空格，都會被判為非法輸入。

Base64 字串通常是某個敏感物的片段：設定檔、權杖、正要發往客戶郵件的圖片。在隨手找到的網站上解碼，等於把這些材料貼進別人的日誌。