Base64 編碼器與解碼器

介紹

Base64 編碼器與解碼器是一款免費的線上工具，用於將文字轉換為 Base64，並將 Base64 轉換回文字。兩種操作在您輸入時即時進行，無需重新載入頁面或點選提交按鈕。該工具完全在瀏覽器中執行 — 沒有任何內容傳送到伺服器。

同一頁面上有兩個獨立的部分：一個用於編碼，一個用於解碼。每個部分都有自己的文字區域、上傳區域和操作按鈕，讓您可以雙向操作而無需切換模式。

什麼是 Base64

Base64 是一種僅使用可列印 ASCII 字元表示二進位資料的方法。它不是加密或壓縮方案 — 它旨在透過為文字設計的系統安全地傳輸二進位資料。

編碼原理

Base64 字母表使用 64 個字元：

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

編碼過程將輸入分成每組 3 個位元組（24 位元），然後將每組分成四個 6 位元值。每個 6 位元值（0–63）對映到字母表中的一個字元。

輸入：       F   o   o
二進位：     01000110 01101111 01101111
6 位元分組： 010001 100110 111101 101111
十進位：     17     38     61     47
Base64：    R     b    9     v

"Foo" 被編碼為 Rm9v。

為什麼是 64

選擇 64 是因為它是僅使用幾乎所有字元集中都可用的字元（字母、數字和兩個標點符號）的最大 2 的冪。這使得 Base64 在可能會損壞或拒絕非 ASCII 位元組的電子郵件系統、JSON 負載、URL 和其他基於文字的通道中保持可靠。

每個 Base64 字元攜帶 6 位元資訊（一個位元組有 8 位元）。這個 6:8 的比例就是編碼輸出比原始輸入大約大 33% 的原因 — 我們稍後會詳細討論這個話題。

當輸入不是 3 的倍數時

如果最後一組不足 3 個位元組，則會新增填充。編碼器新增 = 字元使輸出長度為 4 的倍數：

• 剩餘 1 個位元組 → 2 個 Base64 字元 + ==
• 剩餘 2 個位元組 → 3 個 Base64 字元 + =
• 3 個位元組已滿 → 4 個 Base64 字元，無填充

例如，"Fo"（2 位元組）被編碼為 Rm8=。

關於 Base64 不是什麼的說明

Base64 經常與加密混淆，因為其輸出看起來像亂碼。只要立即解碼，無需金鑰就能揭示原始文字。如果您需要保護資料，請使用合適的加密演算法（AES、ChaCha20 等），然後將加密後的位元組用 Base64 編碼以便傳輸。僅靠 Base64 不能提供機密性。

Base64 的常見用途

Base64 出現在 Web 上的許多日常場景中，使用者往往沒有意識到。

Data URI

現代瀏覽器允許您使用 data: URI 直接將影像、字型和其他媒體嵌入到 HTML 或 CSS 中：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

Base64 編碼的影像資料直接存在於 HTML 檔案中 — 無需單獨的 HTTP 請求。這在小型圖示、精靈圖和 Web 字型中很常見，當額外的 HTTP 往返比內聯位元組更昂貴時使用。

但 Base64 Data URI 並不總是大型資源的最佳選擇。33% 的大小開銷意味著一個 100 KB 的圖示變成了 133 KB 的內聯文字，而且瀏覽器無法將其與 HTML 頁面分開快取。大多數網站僅對幾 KB 以下的資源使用 Data URI。

JWT 和 API 令牌

JSON Web Token 使用 Base64url（URL 安全變體）對令牌的標頭、負載和簽名區段進行編碼。如果您曾經檢查過 JWT：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

每個用點分隔的區段都是 Base64url 編碼的 JSON。您可以將任何區段貼到此工具的解碼區來檢查其內容。

郵件附件（MIME）

電子郵件最初設計為僅支援 7 位元 ASCII。要傳送二進位附件（影像、PDF、試算表），MIME 標準將它們編碼為 Base64。郵件用戶端在開啟訊息時自動解碼。

一個常令人困惑的細節：MIME Base64 傳統上每 76 個字元換行。如果從郵件原始碼中提取 Base64 資料，它可能包含嵌入的換行符。該工具的解碼器會自動處理換行符 — 您可以直接貼上多行 MIME Base64，無需預處理。

PEM 憑證和金鑰

SSL/TLS 憑證和私鑰以 PEM 格式分發，它用 Base64 編碼 DER 資料，並用標頭和尾部行進行包裝：

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----

PEM 本質上就是帶標籤包裝的 Base64。您可以解碼 PEM 檔案的 Base64 正文來檢查原始的 DER 內容，但結果將是二進位的，而不是可讀文字。

HTTP 基本認證

HTTP Basic auth 標頭將 使用者名稱:密碼 編碼為 Base64：

Authorization: Basic YWRtaW46c2VjcmV0

字串 YWRtaW46c2VjcmV0 是 admin:secret 的 Base64 編碼。這裡的 Base64 是一種序列化機制，而不是安全措施 — 任何看到標頭的人都可以輕鬆解碼憑證。

什麼是 .b64 檔案

.b64 檔案是一種純文字檔案，其全部內容是一個 Base64 字串。.b64 副檔名是一種命名約定，表示「此檔案包含 Base64 資料」 — 與任意文字、原始碼或二進位格式不同。

您可能遇到 .b64 檔案的情況：

• 從此類工具匯出編碼輸出
• 以可攜式文字格式儲存加密金鑰或憑證
• 在使用基於檔案的工作流程的系統之間交換 Base64 資料

.b64 檔案是純文字，因此您可以在任何文字編輯器中開啟它以檢視其內容並將字串複製到解碼器中。該工具在編碼和解碼部分都接受 .b64 檔案，透過拖放或檔案選擇方式。

運作原理

該工具使用瀏覽器的內建 Base64 函數，並增加了一層 UTF-8 安全處理。

核心轉換

JavaScript 提供了兩個原生 Base64 函數：

• btoa(input) — 將字串轉換為 Base64（二進位→ASCII）
• atob(input) — 將 Base64 轉換回字串（ASCII→二進位）

這些函數僅適用於 Latin-1（ISO-8859-1）字元。如果傳入包含超出 Latin-1 範圍的字元（如中文、日文或表情符號）的字串，btoa() 將拋出 DOMException。

UTF-8 安全編碼

為了正確處理所有 Unicode 文字，該工具包裝了原生函數：

function encode(text, urlSafe, noPad) {
  let utf8 = encodeURIComponent(text);
  let base64 = btoa(utf8);
  if (urlSafe) base64 = base64.replace(/\+/g, '-').replace(/\//g, '_');
  if (noPad) base64 = base64.replace(/=+$/, '');
  return base64;
}

function decode(base64) {
  let restored = base64.replace(/-/g, '+').replace(/_/g, '/');
  while (restored.length % 4 !== 0) restored += '=';
  let utf8 = atob(restored);
  return decodeURIComponent(utf8);
}

encodeURIComponent 將文字轉換為 UTF-8 百分比編碼形式，僅包含 btoa 可以處理的 ASCII 字元。解碼路徑以相反順序恢復。

要檢視為什麼這很重要，嘗試直接用 btoa 編碼表情符號「😊」 — 它會拋出錯誤。使用 UTF-8 包裝器後，它變成 J UmbKSA4bQ，並能正確解碼回 😊。

處理 URL 安全輸入

解碼函數在將字串傳遞給 atob 之前始終執行兩個轉換：

1. 將 - 替換為 +，將 _ 替換為 /（反轉 URL 安全編碼）
2. 如果字串長度不是 4 的倍數，新增 = 填充

這表示解碼端無需切換任何設定。無論標準 Base64、URL 安全 Base64、帶填充還是不帶填充，解碼器都能自動處理。

事件流程

當您在文字區域中輸入或貼上時，input 事件監聽器觸發。排程器會緩衝快速的按鍵（大約 16 毫秒的去抖，與一個畫面同步），然後執行編碼或解碼函數。結果會在下一個畫面更新時顯示在輸出文字區域中。

標準 Base64 與 URL 安全 Base64

編碼區的兩個核取方塊對應 Base64 的兩個明確定義的變體。

標準 Base64（RFC 4648 §4）

使用完整字母表：A–Z、a–z、0–9、+、/。這是原始形式，除了 + 和 / 具有特殊意義的地方之外，在任何地方都適用。

URL 安全 Base64（RFC 4648 §5）

替換兩個在 URL 中會引起問題的字元：

標準 Base64 Pz4/Pj8+QA== 在 URL 安全形式下變為 Pz4_Pj8- QA_（注意：範例中的填充 = 也已省略，但 URL 安全也可以使用填充）。

何時使用哪種

該工具的解碼端會自動偵測使用的變體，因此您無需變更設定即可貼上任何格式。

常見誤解

一些開發者認為 URL 安全 Base64 是一種不同的演算法。其實不是 — 只是字母表變了兩個字元。任何標準 Base64 解碼器可以透過在處理前對映 - → + 和 _ → / 來適應它。這正是該工具在解碼端所做的。

Base64 的填充

Base64 字串末尾的 = 字元是填充 — 它們不是編碼資料的一部分。

為什麼存在填充

Base64 以 3 個位元組為一組處理輸入。如果最後一組不足 3 個位元組，編碼器會新增 = 作為填充，使總長度為 4 的倍數。某些解碼器需要這樣做，並且它允許無歧義地連線多個 Base64 字串。

「無填充」的含義

啟用「無填充」後，編碼器會從輸出中去除尾部的 = 字元。範例：

• 輸入：Fo → Rm8=（帶填充）→ Rm8（無填充）
• 輸入：Foo → Rm9v（兩種情況都無填充 — 正好是 3 的倍數）

許多現代系統接受無填充的 Base64，該工具的解碼器始終處理它。如果輸出要傳送到的系統不需要或不想要填充，請啟用此選項。

互通性矩陣

該工具的解碼端自動接受所有四種組合：

無需調整任何設定。解碼器在處理前會正規化輸入。

何時需要填充

某些系統嚴格要求填充，特別是：

• Data URI: data:image/png;base64,... — 瀏覽器解析器期望正確填充的 Base64。
• 較舊的 Base64 函式庫: 某些實作會完全拒絕無填充的輸入。

如果您不確定目標系統是否需要填充，請保持啟用（預設）。只有在您同時控制編碼器和解碼器時，才安全地去除填充。

Base64 與其他編碼方案的比較

Base64 是幾種二進位到文字編碼方案之一，每種方案在密度、字母表大小和用例方面有不同的權衡。

為什麼 Base64 最受歡迎

Base64 對大多數實際應用來說是一個最佳平衡點。與使輸入大小翻倍的 Hex 相比，Base64 的 33% 開銷顯著更高效。與 Base85 相比，Base64 實作更簡單（每種語言都有內建解碼器），其字母表避免了 Base85 中某些字元（如 " 或 \）在某些上下文中引起的引號問題。

何時使用其他方案

• Hex: 當人類可讀性和偵錯比大小更重要時。像 4f6f 這樣的 Hex 字串可以立即被識別為編碼資料。b293 作為 Base64 就不那麼明顯了。
• Base32: 當不需要大小寫區分時（例如，在電話上朗讀、印刷在產品上）。Base32 僅使用大寫字母和數字。
• Base85: 當在受限通道中一個位元組的開銷很重要，並且您控制管道的兩端時。

對於一般的 Web 編碼，Base64 是正確的預設選擇。該工具遵循這個約定。

效能與大小考量

Base64 簡單且通用，但在處理大量資料時，實際成本很重要。

33% 的開銷

每 3 個輸入位元組產生 4 個輸出位元組，比例為 4:3。實際上，包括填充和換行在內，小輸入的開銷約為 37%，對於足夠大的輸入，穩定在 33%。

Base64 與壓縮

對 Base64 文字進行 Gzip（或 Brotli）壓縮通常效果不佳。Base64 輸出具有均勻的字元分佈 — 64 個字元中的每個出現的頻率大致相同 — 這消除了壓縮演算法賴以生存的模式。壓縮的 Base64 字串通常只比未壓縮形式小 5–10%，而原始二進位資料可以達到 60–80% 的壓縮率。

這表示：

• 不要在壓縮前對資料進行 Base64 編碼。先壓縮，如果需要再編碼。
• 不要依賴傳輸層壓縮（如 HTTP gzip）來補償 Base64 的開銷。它不會起作用。

何時不應該使用 Base64

Base64 在您需要將二進位資料塞進純文字通道時很有用。如果通道原生支援二進位傳輸，則跳過 Base64：

• 檔案上傳: 使用 multipart/form-data 的原生二進位，而不是 JSON 中的 Base64。否則檔案到達伺服器時大 33%，上傳時間更長。
• 資料庫儲存: 將二進位資料儲存為 BYTEA（PostgreSQL）、BLOB（MySQL/SQLite）或 varbinary（MSSQL），而不是 Base64 文字。
• 服務間 API 呼叫: 使用帶二進位欄位的 gRPC、Thrift 或 MessagePack，而不是 Base64 編碼的 JSON 字串。

對於文字負載（JWT 負載、HTML 內容、電子郵件正文），開銷可以忽略不計，Base64 的便利性值得權衡。

快取影響

將 Base64 Data URI 嵌入到 HTML 或 CSS 中會使編碼內容成為頁面資源的一部分。瀏覽器無法獨立快取該 Data URI — 對頁面的變更會使其失效。透過 <img src="icon.png"> 請求的單獨影像檔案可以使用 Cache-Control 標頭在不同頁面之間快取。對於超過幾 KB 的資源，單獨的檔案在大多數情況下效能更好。

常見陷阱與誤解

Base64 很簡單，但一些反覆出現的誤解會導致實際錯誤。

Base64 不是加密

這是最常見的誤解。因為 Base64 的輸出看起來像隨機字元，許多開發者假設它提供了一些保護。其實不是。解碼不需要金鑰或金鑰。將 Base64 字串視為任何人都可以讀取的純文字。

如果您看到一個服務將密碼或 API 金鑰儲存為 Base64，請將其視為安全問題 — 資料是以明文儲存的。

大小寫敏感性

Base64 字母表區分大小寫：

• 大寫：A–Z（值 0–25）
• 小寫：a–z（值 26–51）

像 R 和 r 這樣的錯誤會完全改變解碼後的值。如果解碼輸出看起來不對，請檢查輸入的大小寫錯誤。

MIME 換行

MIME 編碼的郵件附件每 76 個字元對 Base64 正文進行換行：

SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdCBvZi BiYXNlNjQgZW5jb2Rpbmcu
VGhpcyBpcyB0aGUgc2Vjb25kIGxpbmUu

並非所有 Base64 解碼器都能處理這些嵌入的換行符。該工具可以 — 您可以直接貼上多行 MIME Base64，無需預處理。不處理換行的解碼器會產生亂碼結果或錯誤。

隱藏的空白

從電子郵件、PDF 或網頁複製文字可能會帶入不可見的空白字元（空格、製表符、零寬空格、不間斷空格）。這些不是有效的 Base64。如果一個看起來有效的 Base64 字串無法解碼，首先將其貼上到純文字編輯器中檢查隱藏字元，或從來源重新複製。

拼接帶填充的字串

直接拼接兩個帶填充的 Base64 字串不一定會正確解碼。填充 = 屬於每個字串的最後一組，拼接可能會建立歧義的邊界。這是故意的 — 填充防止了單個字串的歧義。對於多部分資料，請分別處理每個部分。

如何使用

使用 Base64 編碼器與解碼器無需設定、註冊或帳戶。

將文字編碼為 Base64

1. 在 Base64 編碼 區域，在輸入文字區域中輸入或貼上文字。
2. 輸出區域會自動更新為編碼結果。
3. 可選地，啟用 URL 安全（用於 Web 的安全變體）或 無填充（去除尾部 =）。
4. 點選 複製 將編碼文字複製到剪貼簿，或點選 下載 Base64 儲存為 .b64 檔案。

將 Base64 解碼為文字

1. 在 Base64 解碼 區域，將 Base64 字串貼上到輸入區域。
2. 解碼後的文字會立即出現在輸出區域。
3. 如果輸入不是有效的 Base64，將顯示錯誤訊息。
4. 點選 複製 或 下載 儲存解碼結果。

使用檔案上傳

• 編碼區域: 將 .txt 檔案拖放到上傳區域以載入要編碼的內容。
• 解碼區域: 將 .b64 或 .txt 檔案拖放以載入要解碼的 Base64 內容。

檔案內容被讀取並放入輸入文字區域，立即進行處理。

教學

場景： 您正在建構一個與 API 通訊的 Web 應用程式。API 期望請求負載中的簡短文字欄位編碼為無填充的 URL 安全 Base64。您需要對文字進行編碼，檢查輸出，並確認 API 會接受它。稍後，您將從同一 API 收到包含需要解碼的 Base64 編碼欄位的回應。

本教學涵蓋完整的往返過程。

第 1 部分：編碼

1. 在瀏覽器中開啟 Base64 編碼器與解碼器。您將看到兩個部分：左側是編碼，右側是解碼。

2. 在編碼輸入區域中輸入以下文字：

   你好，API 伺服器。這是負載。
   

   輸出區域會立即顯示標準 Base64 編碼。結果以 5L2g5aW9 開頭。到目前為止一切順利。

3. API 規範要求無填充的 URL 安全 Base64。同時啟用 URL 安全 和 無填充 核取方塊。觀察輸出如何變化：

   • + 字元（如果有）變為 -
   • / 字元變為 _
   • 尾部的 = 字元被去除

4. 點選 複製 將編碼結果複製到剪貼簿。將其貼上到您的 API 請求負載中。

第 2 部分：解碼

5. API 回應一個包含 Base64 編碼欄位的 JSON 負載：

   {
     "status": "ok",
     "message": "eyJzdWIiOiAiMTAwMSIsICJuYW1lIjogIkFQSSBHYXRld2F5In0="
   }
   

6. 複製 message 的值並將其貼上到 解碼 輸入區域。

   輸出區域會立即顯示解碼後的文字：

   { "sub": "1001", "name": "API Gateway" }
   

7. 您現在可以讀取像 JWT 這樣的 JSON 負載了。如果 API 使用了 URL 安全 Base64（字串中沒有 +//，或者有 -/_），解碼器會自動處理它。

第 3 部分：基於檔案的工作流程

8. 假設您需要將編碼後的負載傳送給更喜歡檔案的同事。在編碼區域，點選 下載 Base64。瀏覽器會開啟「另存新檔」對話框，建議檔名 download.b64。儲存檔案。

9. 同事收到檔案，開啟同一個工具。他們將 download.b64 拖放到 解碼 區域的上傳區。檔案內容出現在輸入區域，解碼後的文字立即顯示。

這個往返過程 — 帶選項編碼 → 複製或下載 → 自動偵測解碼 — 涵蓋了最常見的實際工作流程。您無需考慮字元變體或填充規則，因為工具會處理所有正規化工作。

專業提示

• 同時編碼和解碼: 兩個區域是獨立的。您可以在編碼區域輸入文字的同時，在解碼區域貼上另一個 Base64 字串。使用這種方法並排比較兩個方向的輸入和輸出。

• JWT 使用 URL 安全: 處理 JWT 令牌時，始終啟用 URL 安全模式。JWT 區段使用 URL 安全變體（RFC 7515）。將 JWT 區段貼上到解碼區域時，工具會自動偵測 URL 安全字元。

• 貼上前修剪空白: 某些 Base64 資料來源包含尾隨換行符或空格。解碼器處理修剪後的輸入效果最佳。如果看到「無效的 Base64 字串」錯誤，檢查貼上的文字中是否有多餘的空白。

• 長輸出請下載: 對於長的 Base64 字串，使用下載按鈕而不是複製。原生的「另存新檔」對話框讓您選擇儲存位置，結果儲存為 .b64 或 .txt 檔案，便於轉發或封存。

• 上傳代替輸入: 如果您已有包含文字或 Base64 資料的檔案，直接拖放到上傳區域。這比開啟檔案、全選、複製、然後貼上更快 — 尤其是大檔案。

• 解碼以檢查格式: 收到 Base64 字串但不確定它包含文字還是二進位資料？貼上到解碼區域。如果輸出是可讀文字，您就完成了。如果包含亂碼或取代字元（），則原始來源可能是二進位（影像、PDF 或其他非文字格式）。

替代工具

還有其他幾種方法可以編碼或解碼 Base64，每種方法都有不同的權衡。

對於隱私、即時回饋和無需命令列知識來編碼或解碼 Base64 文字，此工具提供最佳使用者體驗。

資料隱私

Base64 編碼器與解碼器在您的瀏覽器中本機處理所有內容。您輸入的文字永遠不會傳送到伺服器、儲存在資料庫中或由系統記錄。

所有轉換都使用 JavaScript 原生的 btoa() 和 atob() 函數在瀏覽器記憶體中執行。此頁面不包含分析指令碼、追蹤畫素或第三方嵌入。不會建立或讀取 cookie、localStorage 或 sessionStorage 條目。

初始頁面載入後，該工具完全離線工作。即使斷開網際網路連線，您也可以繼續編碼和解碼，不會中斷。您可以透過在飛航模式下使用該工具或在瀏覽器開發者工具中檢查網路活動來驗證 — 頁面載入後，沒有請求離開您的裝置。

故障排除

技術規格

• 核心演算法: btoa() / atob() 包裝 encodeURIComponent / decodeURIComponent 實現 UTF-8 安全
• 標準: RFC 4648 §4（標準 Base64）、RFC 4648 §5（URL 安全 Base64）
• 輸入處理: 解碼時自動轉換 URL 安全字元（- → +、_ → /）和填充正規化
• 即時處理: 文字區域的 input 事件監聽器，去抖到大約一個畫面（16 毫秒）
• 檔案 I/O: 上傳使用 FileReader API，下載使用 showSaveFilePicker（File System Access API）和 <a download> 回退
• 下載格式: .b64（編碼後）、.txt（解碼後）
• 上傳格式: .txt（編碼區域）、.b64 / .txt（解碼區域）

效能基準

在 2020 年中階筆記型電腦上測量，使用 Chrome 120。效能隨輸入大小線性擴展。對於小於 100 KB 的典型文字負載，轉換幾乎是瞬時的。

瀏覽器相容性

showSaveFilePicker 需要基於 Chromium 的瀏覽器（Chrome、Edge、Opera、Samsung Internet）。在 Firefox 和 Safari 中，下載會自動回退到 <a download> 方法。

隱私與安全

• 零資料傳輸：所有文字處理在瀏覽器記憶體中完成
• 不使用 Cookie、localStorage 或 sessionStorage
• 工具頁面上無分析或追蹤指令碼
• 初始頁面載入後完全離線工作
• 無需註冊、登入或 API 金鑰

功能特色

• 將文字編碼為 Base64，將 Base64 解碼為文字（即時轉換）
• URL 安全模式（使用 -_ 代替 +/，RFC 4648 §5）
• 無填充選項（去除尾部 = 號，RFC 4648 §3.2）
• 內建 Base64 編碼方案和 .b64 檔案格式說明
• 支援 .txt 和 .b64 檔案的拖放上傳
• 透過原生「另存新檔」對話框將結果下載為 .b64/.txt 檔案
• 完全在用戶端執行 — 不向伺服器傳送資料，離線也可使用

常見問題