MIME Base64

輸入文字
0 字元

GeekFormat線上MIME Base64格式化工具，按RFC 2045標準以76字元寬度插入CRLF換行，或將多行MIME Base64還原為單行。適合郵件附件編碼、S/MIME簽章、PEM憑證處理和舊系統相容。純瀏覽器本地處理，資料不上傳伺服器，支援一鍵複製。

相關推薦

Base64 多行合併

影片轉 Base64

Unicode 跳脫

文字轉 Base64

SQL 格式化工具

正規表達式測試器

關於 MIME Base64 格式化

MIME Base64 是郵件系統中使用的一種 Base64 編碼展示格式。MIME（Multipurpose Internet Mail Extensions，多用途網際網路郵件延伸）是一組網際網路標準，定義了郵件中傳輸非文字內容（如圖片、音訊、影片等二進位資料）的方式。Base64 將二進位資料編碼為純 ASCII 文字，使郵件系統能安全傳輸任意二進位附件。

RFC 2045 是定義 MIME 的核心標準之一，其中規定了 Base64 編碼內容在郵件中的折行格式：每行不超過 76 個 Base64 字元，行結束符使用 CRLF（\r\n）。這個限制源於 SMTP 協定的歷史約束——早期郵件傳輸代理（MTA）對單行長度有嚴格限制，76 字元的保守設定確保內容在所有郵件伺服器上都能正確處理，不會被截斷或修改。

MIME Base64 和普通 Base64 在編碼內容上完全相同——同樣的字元集（A-Za-z0-9+/）、同樣的 padding（= 號）、同樣的編碼演算法。區別僅在於展示格式：MIME Base64 按 76 字元插入 CRLF 換行形成多行文字，普通 Base64 通常是連續的單行字串。解碼時換行符會被自動忽略，兩種格式解碼後得到完全相同的原始資料。

雙向轉換是 MIME Base64 處理的核心需求。單行轉折行：將 API 傳回的連續 Base64 字串按 76 字元寬度插入 CRLF，生成符合郵件規範的 MIME 格式，可直接嵌入郵件體。折行轉單行：移除 MIME 格式中的所有換行符，還原為連續字串，方便用於 API 請求參數、JSON 欄位或資料庫儲存。兩種操作互為逆過程。

CRLF（\r\n）是 MIME 標準規定的行結束符序列：CR（Carriage Return，歸位，ASCII 13）+ LF（Line Feed，換行，ASCII 10）。這是網際網路協定的標準行結束符，與 Unix/Linux 系統使用的純 LF（\n）和舊 Mac 系統使用的純 CR（\r）不同。RFC 2045 要求 MIME 內容使用 CRLF，但還原時工具會相容識別所有三種換行符類型。

S/MIME（Secure/MIME）是 MIME 的安全延伸，用於郵件的數位簽章和加密。S/MIME 簽章後的 PKCS#7 資料結構中包含 Base64 編碼的簽章內容，這些內容需要按 MIME 標準折行後嵌入郵件。PEM（Privacy Enhanced Mail）是另一種使用固定寬度 Base64 折行的格式，但它使用 64 字元寬度（RFC 1421），與 MIME 的 76 字元不同。兩者都屬於固定寬度 Base64 展示格式，理解 MIME Base64 有助於處理類似格式。

Content-Transfer-Encoding 是 MIME 郵件頭中的關鍵欄位，標識郵件體的編碼方式。值為 base64 時，表示郵件體使用 Base64 編碼並以 76 字元折行格式呈現。接收方郵件用戶端讀取此標記後，自動將折行 Base64 解碼為原始資料。其他常見的 Content-Transfer-Encoding 值包括 7bit、8bit、quoted-printable 等，Base64 是處理二進位附件最常用的方式。

本工具專注於 MIME Base64 的格式化操作——折行和還原，不執行 Base64 編碼或解碼。所有處理在瀏覽器本地透過 JavaScript 完成，資料不離開你的裝置。折行嚴格遵循 RFC 2045 標準（76 字元 + CRLF），還原時自動相容 CRLF、CR、LF 三種換行符。適合郵件開發、S/MIME 處理、協定除錯和舊系統相容等情境。

適用場景

  • 將單行 Base64 按 RFC 2045 標準格式化為 76 字元寬度的 MIME 郵件附件格式
  • 將多行 MIME Base64 還原為單行用於 API 介面傳輸或 JSON 欄位嵌入
  • 處理 S/MIME 簽章郵件中的 Base64 編碼內容段，調整換行格式
  • 相容舊系統或歷史協定要求的固定寬度 Base64 輸出格式
  • 郵件開發除錯時驗證 Base64 附件內容的折行是否符合 MIME 規範
  • 將 API 傳回的連續 Base64 字串轉為折行格式，方便在郵件正文中貼上展示
  • 處理 PEM 憑證中的 Base64 內容時參考固定寬度折行邏輯
  • 設定檔中需要 MIME 格式 Base64 的情境（如郵件閘道、SMTP 中繼設定）
  • 編碼郵件附件前預處理 Base64 內容，確保折行寬度正確
  • 將不同來源的 Base64 資料統一格式化為 MIME 標準後用於郵件系統
  • 排查郵件附件編碼問題時，對比折行前後的 Base64 內容差異
  • 在命令列工具（如 OpenSSL）輸出的連續 Base64 和郵件系統需要的折行格式之間轉換

使用方法

  1. 貼上或輸入 Base64 內容到輸入框
  2. 選擇轉換方向：單行轉 MIME 折行（76字元換行）或 MIME 折行轉單行（移除換行）
  3. 工具自動按 RFC 2045 標準處理格式，即時顯示結果
  4. 點選複製按鈕將結果複製到剪貼簿，用於郵件系統、介面參數或設定檔

功能特點

  • RFC 2045 標準折行：嚴格按 76 字元寬度插入 CRLF 換行，符合 MIME 郵件傳輸規範
  • 雙向轉換：支援單行 Base64 轉 MIME 折行格式，也可將多行 MIME 還原為連續單行
  • 瀏覽器本地零上傳：所有格式轉換在瀏覽器內完成，不經過任何伺服器，資料不離開裝置
  • 一鍵複製：處理結果可直接複製到剪貼簿，用於郵件用戶端、介面參數或設定檔
  • CRLF 換行符規範：折行使用標準 CRLF（\r\n）序列，符合 RFC 2045 對 MIME 行結束符的要求
  • 76 字元精確折行：每行恰好 76 個 Base64 字元（最後一行可能更短），確保相容所有郵件傳輸代理
  • 多行智慧還原：自動識別並移除 MIME 格式中的 CRLF/CR/LF 換行符，拼合為連續 Base64 字串
  • 郵件附件相容：輸出格式可直接嵌入 MIME 郵件體，適配 Outlook、Thunderbird 等郵件用戶端解析
  • S/MIME 簽章支援：生成的折行 Base64 可用於 S/MIME 簽章結構中的編碼內容段
  • PEM 格式參考：雖 PEM 使用 64 字元折行，但工具的折行邏輯可輔助理解和處理類似固定寬度編碼格式
  • 即時預覽：輸入內容後即時顯示折行/還原結果，無需點選按鈕等待
  • 輸入自動清洗：自動移除輸入中的空白字元和非 Base64 字元，避免複製貼上帶入干擾內容
  • 大文本處理：支援長 Base64 字串（數萬字元）的快速折行和還原，瀏覽器本地秒級完成
  • 純前端實作：基於瀏覽器原生 JavaScript API，無需安裝外掛或依賴外部服務，離線可用

常見問題

MIME Base64 為什麼固定按 76 字元換行？

RFC 2045 規定 MIME 編碼內容每行不超過 76 字元，這是為了相容早期郵件傳輸代理（MTA）的行長度限制。SMTP 協定歷史上要求每行不超過 1000 字元，但 MIME 規範更保守地限制為 76 字元的 Base64 資料加換行符，確保所有郵件伺服器都能正確處理。

MIME Base64 和普通 Base64 的編碼內容一樣嗎？

編碼內容完全相同，區別僅在於展示格式。MIME Base64 按 76 字元插入 CRLF 換行，普通 Base64 通常是連續單行。解碼時換行符會被忽略，兩種格式解碼後得到相同的原始資料。

可以把多行 MIME Base64 還原為單行嗎？

可以。工具會自動識別 MIME 折行格式中的 CRLF（\r\n）、CR（\r）和 LF（\n）換行符並全部移除，拼合為連續的單行 Base64 字串。還原後更方便用於 API 請求參數、JSON 欄位或設定檔傳輸。

PEM 憑證格式和 MIME Base64 有什麼關係？

PEM 格式（如 SSL 憑證、私鑰）使用 64 字元寬度的 Base64 折行，與 MIME 的 76 字元略有不同。兩者都屬於固定寬度 Base64 展示格式，但遵循不同的標準（PEM 基於 RFC 1421，MIME 基於 RFC 2045）。工具的折行邏輯可輔助理解類似格式。

折行時使用的是什麼換行符？

按 RFC 2045 標準，MIME Base64 折行使用 CRLF（\r\n）作為行結束符。這是網際網路協定的標準行結束符，確保相容所有郵件伺服器和傳輸代理。部分系統可能只使用 LF（\n），工具還原時兩種都會自動識別。

S/MIME 簽章中需要用到 MIME Base64 嗎？

需要。S/MIME（Secure/Multipurpose Internet Mail Extensions）簽章結構中的編碼內容段使用 MIME Base64 格式，簽章後的 PKCS#7 資料需要按 76 字元折行嵌入郵件。工具可以幫助產生符合 S/MIME 規範的折行 Base64。

最後一行也會補齊到 76 字元嗎？

不會。RFC 2045 規定最後一行可以是任意長度（1-76 字元），不需要補齊。這與固定長度編碼（如每行恰好 76 字元的某些二進位格式）不同，MIME Base64 的最後一行保持原始 Base64 編碼的自然結尾。

Base64 padding（= 填充符）怎麼處理？

Base64 編碼使用 = 號作為末尾填充符（0-2 個），MIME 折行時 = 號會出現在最後一行的末尾。工具保持 padding 不變，折行和還原操作都不會修改 Base64 編碼本身的內容。

工具會修改 Base64 的編碼內容嗎？

不會。工具只做格式調整（插入或移除換行符），不會修改 Base64 字元本身。折行後的 Base64 解碼後與原始輸入完全一致，可以放心使用。

輸入中包含非 Base64 字元會怎樣？

工具會自動過濾輸入中的空白字元（空格、定位字元、換行符）和非 Base64 字元（不在 A-Za-z0-9+/= 範圍內的字元），只保留有效的 Base64 內容進行處理，避免複製貼上時帶入干擾字元。

支援多長的 Base64 字串？

工具基於瀏覽器本地 JavaScript 處理，支援數萬字元級別的 Base64 字串快速折行和還原。超長內容（如大型附件的 Base64 編碼）也能秒級完成處理。

可以用來解碼 Base64 嗎？

本工具專注於 MIME 格式化（折行/還原），不執行 Base64 編碼或解碼操作。如需 Base64 編解碼，請使用站內的 Base64 編碼/解碼工具。MIME 格式化只調整 Base64 字串的換行格式。

Content-Transfer-Encoding: base64 是什麼意思？

這是 MIME 郵件頭中的欄位，表示郵件體內容使用 Base64 編碼。接收方郵件用戶端看到此標記後，會將郵件體中的 Base64 內容（含 76 字元折行）解碼為原始二進位資料。工具生成的折行 Base64 可直接用於此類郵件體。

為什麼郵件中的 Base64 看起來有很多換行？

因為郵件系統按 RFC 2045 標準將 Base64 編碼內容每 76 個字元換行一次。這是 MIME 規範的要求，確保內容能被所有郵件伺服器正確傳輸。一封帶附件的郵件中，附件的 Base64 編碼會以多行折行形式出現在郵件原始碼中。

離線可以使用這個工具嗎？

可以。頁面載入完成後所有功能都在瀏覽器本地執行，不需要網路連線。即使斷網也能正常進行 MIME Base64 折行和還原操作，處理的資料不會上傳到任何伺服器。

故障排查

折行後 Base64 解碼失敗？

MIME Base64 折行只插入 CRLF 換行符，不修改編碼內容。如果折行後解碼失敗，可能是輸入本身就不是有效的 Base64 編碼。請先用 Base64 驗證工具檢查輸入內容是否合法，再進行 MIME 格式化。

還原後 Base64 字串中有換行符殘留？

工具會自動移除所有 CRLF（\r\n）、CR（\r）和 LF（\n）換行符。如果還原後仍有殘留，可能是輸入中包含其他不可見字元（如空格、定位字元）。工具也會自動過濾這些字元，但如果問題持續，請檢查來源內容是否有特殊控制字元。

郵件用戶端顯示附件亂碼？

MIME Base64 折行格式只是郵件編碼的一環。如果附件顯示亂碼，可能是 Content-Transfer-Encoding 頭部設定不正確、Base64 編碼本身有誤，或 Content-Type 不匹配。確保郵件頭中設定 Content-Transfer-Encoding: base64，並使用正確的 MIME boundary 分隔。

PEM 憑證折行寬度不對？

PEM 格式使用 64 字元折行（RFC 1421），而 MIME 使用 76 字元折行（RFC 2045）。本工具按 MIME 標準（76 字元）折行，不適用於 PEM 憑證格式化。如果需要 PEM 格式的 64 字元折行，請使用專門的憑證處理工具或 OpenSSL。

術語表

MIME
Multipurpose Internet Mail Extensions，多用途網際網路郵件延伸，一組網際網路標準（RFC 2045-2049），定義了郵件中傳輸非文字內容的方式，包括 Base64 編碼、Content-Type 和 Content-Transfer-Encoding 等機制。
RFC 2045
定義 MIME 第一部分的標準文件，規定了 Base64 編碼在郵件中的折行格式：每行不超過 76 字元，使用 CRLF 作為行結束符。
CRLF
Carriage Return + Line Feed（\r\n），網際網路協定標準的行結束符序列。RFC 2045 要求 MIME Base64 折行使用 CRLF，與 Unix 的 LF（\n）和舊 Mac 的 CR（\r）不同。
Content-Transfer-Encoding
MIME 郵件頭欄位，標識郵件體的編碼方式。值為 base64 時表示內容使用 Base64 編碼並按 76 字元折行，是二進位附件最常用的編碼方式。
S/MIME
Secure/Multipurpose Internet Mail Extensions，MIME 的安全延伸，用於郵件數位簽章和加密。簽章內容中的 Base64 編碼段需要按 MIME 標準折行。
PEM
Privacy Enhanced Mail，一種使用 64 字元寬度 Base64 折行的格式（RFC 1421），常用於 SSL 憑證和私鑰檔案。與 MIME 的 76 字元折行不同。
Base64 padding
Base64 編碼末尾使用 = 號（0-2 個）填充至 4 的倍數長度。MIME 折行時 padding 出現在最後一行末尾，不會被移除或修改。
MTA
Mail Transfer Agent，郵件傳輸代理，負責在伺服器間轉發郵件的軟體。早期 MTA 對單行長度有嚴格限制，MIME 76 字元折行就是為相容 MTA 而設計的。
SMTP
Simple Mail Transfer Protocol，簡易郵件傳輸協定，網際網路郵件傳輸的基礎協定。SMTP 要求每行不超過 1000 字元（含 CRLF），MIME 的 76 字元限制更為保守。
quoted-printable
MIME 支援的另一種 Content-Transfer-Encoding 方式，主要用於大部分為 ASCII 文字的內容，僅對非 ASCII 字元進行編碼，比 Base64 更節省空間。
PKCS#7
Public Key Cryptography Standards #7，S/MIME 使用的加密訊息語法標準，定義了數位簽章和加密的資料結構，其中的編碼內容使用 MIME Base64 格式。
RFC 1421
定義 PEM（Privacy Enhanced Mail）格式的標準文件，規定 Base64 按 64 字元寬度折行，比 MIME 的 76 字元更窄，常用於憑證檔案。

MIME Base64 與普通 Base64 對比

兩種格式的核心區別在於展示方式，編碼內容完全相同：

對比項MIME Base64普通 Base64
折行寬度76 字元/行通常不折行（單行）
行結束符CRLF (\r\n)無（或由系統決定）
標準依據RFC 2045RFC 4648
典型用途郵件附件、S/MIMEAPI 參數、Data URL
解碼結果相同相同

常見固定寬度 Base64 格式對照

不同標準使用的折行寬度對比：

格式標準折行寬度典型用途
MIME Base64RFC 204576郵件附件編碼、S/MIME 簽章
PEMRFC 142164SSL 憑證、私鑰檔案
普通 Base64RFC 4648不折行API 參數、Data URL、JWT

MIME Content-Transfer-Encoding 方式對比

MIME 支援的常見編碼傳輸方式：

編碼方式適用內容空間效率
base64任意二進位資料（圖片、影音等）約 33% 膨脹（3位元組→4字元）
quoted-printable大部分 ASCII 文字，少量非 ASCII僅非 ASCII 字元膨脹
7bit純 ASCII 文字（無需編碼）無膨脹
8bit含 8 位字元的文字（需 8BITMIME 支援）無膨脹

Privacy & Security

本 MIME Base64 格式化工具所有操作完全在你的瀏覽器本地透過 JavaScript 完成，不會向任何伺服器發送輸入的 Base64 內容、處理結果或使用記錄。頁面載入後不需要網路連線即可使用，所有資料僅存在於瀏覽器記憶體中，關閉或重新整理頁面後自動清除，不存在任何資料上傳或儲存，沒有隱私洩露風險。

Authoritative References