開發者工具 · Base64 編碼器和解碼器
Base64 讓您的資料增大了多少？ 4/3 開銷已解決
· 工作原理
base64 編碼 效能
Base64 輸出大約比輸入大三分之一，加上填充和可能的換行符號。這篇文章得出了精確的公式並將其應用於實際尺寸，以便您可以判斷成本。
捆綁包中的 30 KB 圖示變成了 40 KB — 具體尺寸的跳躍令建立審核感到驚訝
CSS 檔案中以 Base64 形式內聯的 30 KB 圖示變成 40 KB，並出現建置稽核問題：額外的 10 KB 從哪裡來？ Base64 的擴展因子始終為 4/3: 每三個位元組輸入產生四個位元組輸出（四個字元）。對於 30 KB 輸入（30,000 位元組），除以三以獲得 10,000 組，乘以四以獲得 40,000 位元組輸出。
數學是確定性的且不可避免的：Base64 不是壓縮格式。如果內聯資產因為減少了一個 HTTP 請求而花費了 33% 的頻寬並頁面載入速度更快，那麼這是值得衡量的權衡。如果成本增加 33% 且載入速度較慢，則內聯就不值得。 4/3 比率來自位元版面。三個位元組是 24 位元；四個 Base64 字元攜帶 24 位元（每個字元攜帶六個位元）。
為什麼 4/3 是下限 — 每個字元六位而不是每個位元組八位，以及剩餘開銷來自哪裡
到目前為止，比例為1:1。但 Base64 字符是文字（ASCII 0–127），UTF-8 或 Latin-1 編碼中的平均 ASCII 字符是一個字節。因此，四個 Base64 字符是三個字節輸入的四個字節輸出，比率為 4/3。這並不通用：如果 Base64 以二进制格式輸出（每個字符一個字節，打包為六位），則比率將為 3/4（壓縮）。
由於 Base64 是為文字傳輸而設計的，因此它使用文字字符，並且成本是 33% 大小增加。填充在末尾添加了小邊距。如果輸入長度是三的倍數，則不需要填滿。如果輸入長度 1 mod 3 （一個位元組少於多個），則添加兩個填充字符，將輸出增加 2。如果 2 mod 3，則加入一個填充字符，並增加 1。
帶填充的精確公式 — ceil(n/3) × 4 字符，以及 1、2 和 3 位元組輸入的效果
對於大輸入，邊距可以忽略不計：300 位元組輸入需要 400 字元加上最多兩個填充字符，差異小於 0.5%。對於微小輸入（1–3 位元組），填充占主導地位：一個位元組產生 YQ==（四個字元），4 倍擴展。但跨檔案的平均值主要是大檔案。確切的公式為 ceil(n / 3) × 4 個字符，其中 n 是輸入位元組數。
對於 n = 1，ceil(1/3) × 4 = 1 × 4 = 4。對於 n = 2，ceil(2/3) × 4 = 1 × 4 = 4。對於 n = 3，ceil(3/3) × 4 = 1 × 4 = 4。對於 n = 4，ceil(4/3) × 4 = 2 × 4 = 8。對於 n = 30000, ceil(30000/3) × 4 = 10000 × 4 = 40000。小輸入案例解釋了為什麼「大約三分之一」對於每個值都不準確。一個位元組仍然佔用一個四字元塊，兩個位元組也是如此。只有當許多完整的三位元組主導最終的填充區塊時，該比率才接近三分之四。
工作範例：測量 20 字元 UTF-8 字串 — 計算位元組而不是字符，然後計算 Base64 長度
上限函數會考慮最後一組並非三的完整倍數。當 n 變大時，ceil(n/3) 會接近 n/3，因此輸出接近 (n/3) × 4 = 4n/3，也就是 4/3 的比率。
測量具體字串：20 字元混合 ASCII、重音符號和表情符號。 JavaScript 中的字元數為 15（表情符號計為 1）。 UTF-8 位元組數不同：ASCII 字母 1 位元組，重音字母 2 位元組（0xC3 0xA9 表示 é），表情符號 4 位元組（0xF0x9F 0xF0x9F 90x）。此工具分別報告 UTF-16 字元、Unicode 代碼點和 UTF-8 位元組。這種區別防止包含多位元組符號的二十字元句子被定價為二十位元組。編碼長度遵循位元組數，而不是人類在螢幕上計算的長度。
換行符號與 MIME 換行 — 76 欄位格式如何進一步增加幾個百分點
總計約 18 位元組。 Base64 編碼：ceil(18/3) × 4 = 6 × 4 = 24 個字元。由於 18 是三的倍數，因此不需要填充。 Base64 輸出為 24 個字元。編碼增加 24 - 18 = 6 個字節，即 33%，確認了 4/3 公式。 MIME Base64 包裝會帶來額外的開銷。經典 MIME 每行換行 76 個字元並新增換行符。
插入換行符後，400 字元 Base64 輸出大約變成 405 位元組。對於 Base64 輸出的每 76 字符，插入一個換行符位元組。對於大檔案，新增少於 2%。對於電子郵件附件，換行約定是標準的，也是解析器所期望的；工具接受包裝的 Base64 並正確解碼。壓縮相互作用使尺寸分析變得複雜。原始二進位資料（圖片、影片）的壓縮方式與 Base64 文字不同。 ToolAcre 在每個配置的 76 字元切片後插入換行符，並從其顯示的編碼字元測量中排除這些換行符。有線格式預算必須添加分隔符號；可見測量的比較僅描述了 Base64 符號，而不是每個傳輸的行結束位元組。
壓縮互動－為什麼 Base64 文字的壓縮效果往往比它所代表的原始位元組更差
使用 gzip，Base64 字串可能會壓縮到其大小的 60%，圖像可能會壓縮到 25%。由於 gzip 尋找重複的位元組模式，因此文字表示（字母 A–Z 加 + / 或 - _）的重複次數比二進位資料表示的重複次數要少。透過壓縮內聯圖像通常比單獨嵌入要花費更多的程式碼成本。對於字體，特別是具有許多字形的複雜字體，Base64 內聯可能效率低。
權衡分析取決於具體情況。內聯小資料 URI（10–50 位元組）可能值得開銷以避免 HTTP 請求。內嵌大型資源 (100 KB) 可能不會。壓縮取決於來源及其 Base64 表示形式中的模式，因此通用的壓縮開銷百分比是不誠實的。測量周圍響應壓縮之前和之後的實際資產。一定的成本是塊公式給出的未壓縮字元數。
這不包括測量渲染或解碼性能以及特定於格式的最佳化，例如 WebP
如果 CDN 上的資產靠近用戶，避免請求不會受益。如果同一伺服器上的資產和載入需要額外的往返，則內聯可能是合理的。測量至關重要：使用公式計算內聯大小、為 CSS 或 HTML 檔案添加字元數、測量總包大小和載入時間。
33% 開銷是確定的；效能優勢則不然。 URL-安全性 Base64 (base64url) 有相同的 4/3 比率，只是字元不同。在最壞的情況下，刪除填充可以節省兩個字元。對於大文件，可以忽略不計。對於 JWT 令牌（三個 base64url 段連接點），刪除填充是常規做法，但節省的空間很少；實際大小是令牌內容，而不是編碼開銷。渲染速度、影像解碼和替代格式（例如 WebP）需要不同的測量。較短的 Base64 字串並不意味著繪製速度更快，且此純文字工具不接受圖像檔案。它的可靠貢獻是對面板中輸入的 UTF-8 文字進行算術。
重點：額外預算三分之一 — Base64 編碼器和解碼器如何為您提供任何文字的真實編碼長度，以便您可以測量而不是猜測
壓縮也類似地對文字進行編碼；無論最後兩個字元是 == 還是字串較短，在 gzip 輸出中幾乎沒有區別。 Base64 編碼器和解碼器立即報告輸入位元組數和輸出字元數。對於任何文字編碼，都可以看到確切的大小增加。對於具有多位元組字元的 UTF-8 字串，工具顯示字元計數（看到的內容）與位元組計數（Base64 編碼的內容）不同。
如果包含重音符號和表情符號，10 字元字串可能是 15 位元組，從而產生 Base64 輸出的 20 字符，而不是基於字元計數的 4/3 比率。理解差異可以闡明為什麼內聯表情符號重的圖示比 ASCII 藝術更昂貴：不是表情符號花費更多，而是它們代表 UTF-8 位元組。對於候選內聯值，並排記錄工具的 UTF-8 位元組計數和編碼字元計數。然後包括 URI 前綴、CSS 語法和目標所需的任何包裝。這種完整的測量比重複沒有框架成本的四捨五入百分比更有用。