Base64 填充處理

關於 GeekFormat

輸入

0 字符 · 填充：0 个 =

輸入

0 字符 · 填充：0 个 =

結果

0 字符 · 已加 0 个 =

在瀏覽器中按 RFC 4648 標準自動計算 Base64 結尾應有的 = padding 數量，支援補齊或去填充雙向轉換，修復不符合規範的 Base64 字串，全部在本地完成。

什麼是 Base64 padding？

Base64 padding 是 RFC 4648 標準規定的 '=' 字元，用於讓 Base64 輸出長度為 4 的倍數。Base64 把 3 位元組（24 位元）映射為 4 字元，但最後不足 3 位元組時需要用 = 補齊，否則解碼器無法判斷結尾的真實位元組數。

填充規則：①原始位元組數 mod 3 = 0 → 結尾 0 個 =；②mod 3 = 1 → 結尾補 2 個 =；③mod 3 = 2 → 結尾補 1 個 =。任意 Base64 字串長度 mod 4 的結果必須等於缺失的 = 數。

為什麼需要 padding：Base64 解碼需要明確邊界。padding 讓解碼器知道結尾的 = 對應幾個真實位元組，避免歧義。沒有 padding 時，1 位元組和 2 位元組的輸入可能編碼成相同長度的 Base64，讓解碼無法判斷位元組數。

實際應用：大多數通訊協定（Data URL、MIME、JWT、設定檔）嚴格遵循 padding；少數場景（URL 路徑、檔名、短網址）為節省空間會省略 padding。本工具支援兩種方向的轉換。

適用場景

修復 base64 解碼報錯（如 InvalidCharacterError 或長度不是 4 的倍數），先補齊 = 再解碼。
處理來自 API、JWT、日誌的 Base64 輸出時，去掉多餘的換行和缺失的 padding。
產生 Data URL 時確保 Base64 部分嚴格符合 RFC 4648，避免瀏覽器或第三方工具解碼失敗。
為 JWT token、設定檔、API 憑證等場景快速校驗和補齊 padding。
為 URL、檔名等場景去掉 padding 節省字元（前提是通訊協定支援）。
學習 Base64 編碼原理時，對照輸入位元組數與 padding 數量的對應關係。

使用方法

貼上或輸入需要處理的 Base64 字串（可含或不含 padding、換行）。
選擇模式：補齊（在末尾添加 =）或去填充（刪除末尾 =）。
工具自動計算並展示結果，即時顯示字元數和 padding 增減情況。
複製結果到剪貼簿，或下載為 .txt 檔案用於後續處理。

功能特點

自動計算 padding 數量：即時顯示當前輸入應有的 = 數量與已有 = 數量差異。
補齊模式：把任意 Base64 字串補齊到 4 的倍數長度，一鍵修復長度錯誤。
去填充模式：去掉末尾的 = 字元，適合 URL、檔名等需要省字元的場景。
自動忽略換行和空白：貼上帶換行的 Base64（來自郵件、JWT 輸出）也能正確處理。
即時字元計數：顯示輸入字元數、輸出字元數，以及 padding 的增減數量。
一鍵複製 / 下載：結果可一鍵複製到剪貼簿或下載為 .txt 檔案。
本地瀏覽器處理：所有計算在瀏覽器內完成，原始內容不上傳到任何伺服器。

最佳实践

補齊前先確認輸入是真正的 Base64

本工具只補齊末尾的 =，不會清理無效字元。如果輸入混入了空格、中文或換行符之外的非法字元，解碼仍會失敗。建議先用 Base64 清理工具去除非字母數字的字元。

Data URL 和 JWT 一定要補齊

Data URL（RFC 2397）和 JWT（RFC 7519）都嚴格要求 padding。省略 = 在大多數實作裡都會觸發解碼錯誤或結果不一致，提交前請用本工具補齊到 4 的倍數。

URL/檔名可以省略 padding，但要配套 URL-safe 字元集

如果要把 Base64 放進 URL 路徑、檔名或短網址，僅去填充還不夠，還必須把 + 和 / 替換成 - 和 _（Base64URL）。僅省略 = 仍是標準 Base64，+ 和 / 在 URL 裡仍然非法。

去填充後再解碼出現「長度不對」

說明目標工具嚴格要求 padding。請切換到補齊模式，再嘗試解碼。如果仍然失敗，可能是去填充過程中意外刪除非末尾的 =（輸入本身就是非法的）。

大檔案建議先拆分再處理

本工具適合單段 Base64 字串。如果是幾十 MB 級別的 base64 編碼檔案，建議用命令列工具（如 openssl base64、base64 命令）或在程式碼裡直接處理，避免在瀏覽器裡卡頓。

教學或文件裡展示時記得附 padding 計算

Base64 padding 是新手最容易困惑的點。解釋時務必附上「輸入位元組數 mod 3 = 餘數，對應填充多少 =」的對照表（參考本頁的 referenceTables），否則學生很難理解為什麼有時候要補 1 個、有時候要補 2 個。

常見問題

Base64 padding 有什麼用？

讓 Base64 輸出長度始終是 4 的倍數，給解碼器一個明確的結束邊界。沒有 padding 時，1 位元組和 2 位元組輸入可能編碼成相同長度的字元，解碼器無法區分原始位元組數。

為什麼 Base64 長度必須是 4 的倍數？

因為 Base64 把 3 位元組映射為 4 字元，每組是 3→4 的固定比例。當輸入不是 3 的倍數時，末尾需要用 = 補齊才能湊足 4 字元。任何不是 4 的倍數的 Base64 都是非法的。

如何計算 padding 數量？

公式是 (4 - 輸入位元組數 % 3) % 3，或者直接看 Base64 字元數 mod 4：餘 0 對應 0 個 =，餘 2 對應 1 個 =，餘 3 對應 2 個 =。本工具會自動計算。

可以去掉 padding 嗎？

可以去掉，但僅在通訊協定支援時才行。比如檔名、URL 路徑、JSON Web Token 在某些實作下都接受無 padding 的 Base64，但 Data URL、MIME、設定檔通常嚴格要求。本工具的去填充模式只在確認通訊協定支援時使用。

Base64 解碼提示「長度不是 4 的倍數」怎麼辦？

切換到本工具的補齊模式，一鍵在末尾添加 =。如果補齊後仍報錯，說明輸入本身含有非法字元或被截斷，需要用 Base64 清理工具先檢查。

補齊 padding 會改變原始位元組嗎？

不會。補齊只是在末尾追加 =，不會修改中間的字元，因此原始位元組完全保留。解碼後位元組與原始資料一致。

支援帶換行或空格的 Base64 嗎？

支援。本工具會自動去掉換行、回車和空格後再計算 padding。來自郵件附件、JWT 輸出、設定檔的多行 Base64 都可以直接貼上。

Base64 padding 和 Base64URL 是一回事嗎？

不是。Base64 padding 是末尾的 = 字元問題；Base64URL 是字元集問題（用 - 替代 +、用 _ 替代 /）。本工具只處理 padding，要做 URL-safe 轉換請用專門的 Base64URL 工具。

內容會上傳伺服器嗎？

不會。所有 padding 計算都在瀏覽器內本地完成，原始 Base64 字串不會離開你的裝置。處理敏感資料（憑證、token）也可以放心使用。

故障排查

解碼提示「長度不是 4 的倍數」

用本工具的補齊模式補齊 = 後再解碼。如果補齊後仍然報錯，說明輸入本身含有非法字元，建議先用 Base64 清理工具檢查。

懷疑輸入混入了無效字元

標準 Base64 僅包含 A-Z a-z 0-9 + / =，任何其他字元（中文、空格、換行之外的符號）都是非法的。本工具會自動忽略換行和空格，但其他非法字元需要先用 Base64 清理工具。

去填充後 URL 仍然報錯

可能 URL 裡還有 ? & = 等需要 URL 編碼的字元，或者包含 + / 等 Base64 字元集中的符號。去 padding 不等於 URL-safe，需要再走一次 Base64URL 轉換或 URL 編碼。

貼上後沒有結果

可能輸入完全是空白字元（換行、空格、Tab）。本工具會忽略這些字元做計算，但全空白輸入不會觸發結果。請輸入至少一個 Base64 字元。

術語表

padding = 字元: RFC 4648 標準規定的 Base64 結尾填充字元，用於標識缺失的真實位元組。有效填充只能出現在字串末尾。
4 的倍數: RFC 4648 標準 Base64 輸出長度必須為 4 的倍數，否則視為非法編碼。解碼時嚴格 Base64 模式會直接報錯。
padding 計算公式: 需要的 = 數 = (4 - 輸入位元組數 % 3) % 3；等價於看 Base64 字元數 mod 4，結果 0/2/1 對應 0/1/2 個 =。
無 padding Base64: 省略結尾 = 的 Base64 變體，常見於 URL 路徑、檔名，但嚴格來說不符合 RFC 4648 標準，可能在某些通訊協定下解碼失敗。
Base64 字元集: A-Z、a-z、0-9、+、/ 共 64 個字元，加 = 用於 padding。任何其他字元都是無效的，需要先用 Base64 清理工具。

Base64 padding 規則速查

Base64 輸入位元組數和末尾 = padding 數量的對應關係。

輸入位元組數	mod 3	Base64 字元數	= padding 數	示例（輸入→輸出）
`3n`	0	`4n`	0	ABC → QUJD
`3n+1`	1	`4n+2`	2	AB → QUI=
`3n+2`	2	`4n+3`	1	A → QQ==

常見通訊協定對 padding 的要求

不同通訊協定對 = padding 的要求不同，錯誤省略會導致解碼失敗。

使用場景	是否需要 padding	典型用途
`Data URL (RFC 2397)`	推薦（相容性）	HTML / CSS / 圖片內嵌
`JWT (RFC 7519)`	需要（嚴格）	OAuth / API 鑑權
`MIME (RFC 2045)`	需要	郵件附件編碼
`URL 路徑 / 檔名`	可選（常去除）	短網址 / 快取鍵
`設定檔（YAML / JSON）`	需要	憑證、簽章儲存