Base64 編碼/解碼

Base64 使用 64 個字元的字母（A–Z、a–z、0–9、+、/）將二進位資料編碼為 ASCII 文字。它將輸入擴展了約 33%，但產生的輸出可以在電子郵件、URL、JSON 和任何純文字傳輸中保留。

該工具會自動偵測方向：如果輸入看起來像有效的 Base64 字串，它就會解碼；如果輸入看起來像有效的 Base64 字串，它就會解碼；否則它會編碼。

24 位輸入，四個字符輸出 — 以及填充

Base64 編碼將二進位資料對應到 64 個字元的字母表（A–Z、a–z、0–9、+、/），如下所示 RFC 4648。輸入文字首先被編碼為 UTF-8 位元組。這些位元組被分組為 24 位元區塊，每個區塊分為四個 6 位元值 (2^6 = 64) 並映射到字母表。如果最後一個區塊少於 24 位，則用零位填充，並用「=」字元填充輸出以保持 4 個字元的倍數。此工具自動偵測操作：如果輸入與有效 Base64 的模式相符（字母字元和適當的填充長度），它會嘗試解碼；否則，它會進行編碼。所有處理完全發生在使用 JavaScript 原生的瀏覽器中 btoa 和 atob 函數，使用 UTF-8 位元組轉換器進行擴展以處理非 ASCII 字元。

如何對 Base64 字串進行編碼或解碼

1. 在輸入框中輸入或貼上文字。
2. 此工具會根據輸入內容自動判斷是否進行編碼或解碼。
3. 點擊“編碼/解碼”按鈕進行處理。
4. 從輸出框複製結果。

URL 安全字母表、填充錯誤和 UTF-8 輸入

非 ASCII 字元

對非 ASCII 字元進行編碼時，該工具首先將字串轉換為 UTF-8 位元組，這會相應增加 Base64 輸出長度。

輸入中的空格

解碼會忽略空白字元（空格、換行符、製表符）以容忍來自其他來源的格式。

無效字元

如果輸入包含 Base64 字母表之外的字元並且無法解碼，則該工具會將其視為純文字並對其進行編碼。

資料 URI、API 金鑰和 33% 的大小損失

• 對於 URL 安全的 Base64，請將“+”替換為“-”，將“/”替換為“_”，並手動移除“=”填滿。
• Base64 將資料擴展約 33%，因此如果大小很重要，請在編碼之前考慮壓縮。
• 由於該工具完全在客户端運行，因此對於敏感數據來説是安全的 - 不會將文本發送到服務器。
• 始終驗證填充：有效的 Base64 長度是 4 個字元的倍數。

Base64 vs Base64url vs 十六進位編碼

以下是該工具與常見命令列和程式設計替代方案的比較。

MIME 電子郵件附件的 Base64

Base64 編碼首次在 20 世紀 80 年代末引入電子郵件，作為 MIME（多用途互聯網郵件擴展）規範（RFC 1341，後來的 RFC 2045）的一部分。它旨在透過 SMTP 等純文字協定可靠地傳輸二進位數據，該協定可能會損壞非 ASCII 字元。名稱「Base64」反映了它使用 64 個字元的字母表。該編碼後來在許多其他環境中採用，包括資料 URI、XML 和 JSON Web 令牌 (JWT)。

Base64 在實際系統中出現的位置

在 CSS 或 HTML 中嵌入圖片

data:image/png;base64,... URI 可讓您直接在 HTML 或 CSS 中內嵌圖片。該工具對位元組進行編碼；將它們貼在前綴之後。

編碼 API 令牌

基本驗證（「授權：基本」）需要 Base64 編碼的「user:pass」字串。在貼上到請求標頭之前對您的憑證進行編碼。

解碼 JWT 有效負載

JSON Web 令牌是由點分隔的三個 Base64 編碼部分。解碼中間部分以讀取聲明（標頭和簽名的工作方式相同）。

郵件附件調試

電子郵件附件在 MIME 部分內進行 Base64 編碼。將原始電子郵件來源貼到解碼器中會顯示原始內容。

快速二進位安全傳輸

需要透過 JSON API 發送二進位內容？ Base64 編碼；在接收端解碼。