開發者工具 · Base64 編碼器和解碼器
為什麼電子郵件附件是 Base64：MIME、7 位傳輸和 76 列行
· 背景
base64 編碼
電子郵件是為 7 位 ASCII 文字建構的，並附件必須適合它。這篇文章追蹤了 MIME 如何採用 Base64、為什麼行用 76 字元換行以及這對大小和調試意味著什麼。
到達的配件透過舊中繼損壞 - MIME 的發明是為了解決 8 位元問題
電子郵件是在 20 世紀 70 年代和 80 年代設計的，僅適用於 7 位元 ASCII 文字。 SMTP（承載電子郵件的協定）要求每行最多為 7 位元 ASCII 的 998 個字元（字元 0-127）。直接透過 SMTP 發送諸如 PDF 之類的二進位檔案或映像將失敗：位元組 128-255 將被舊郵件伺服器和中繼損壞或拒絕。附件需要編碼。 MIME（多用途互聯網郵件擴展，RFC 2045）透過定義 Content-Transfer-Encoding 標頭值（包括 base64）解決了這個問題，它將任何位元組序列表示為 7 位元 ASCII 文字。
MIME 提供多種內容傳輸編碼選擇：7 位元（無編碼，僅適用於安全性 ASCII）、8 位元（適用於支援 8 位元組的伺服器，不是通用的）、quoted-printable（僅編碼非安全位元組，保持 ASCII 可讀）和 base64（對所有內容進行編碼，最大化相容性）。選擇 Base64 作為二進位附件是因為它簡單、標準化，並可以保證任何郵件系統的安全，無論郵件系統有多舊或嚴格僅 7 位元。權衡是大小：Base64 比原始位元組大約大三分之一。
Base64 解決的傳輸問題－以可列印字元表示任意位元組
3 KB PDF 大致變成 Base64 文字的 4 KB 。 76 字元行限制來自 RFC 2045。
SMTP 允許最多 998 個字元的行，但較舊的郵件系統和某些垃圾郵件過濾器會拒絕長行。 RFC 2045 指定 MIME Base64 行不得超過 76 個字元（加上 CRLF 行結尾），因此郵件伺服器永遠不會中斷傳輸。極限並不神奇；它是可讀性（76 字元適合大多數 20 世紀 80 年代終端）、與舊系統的兼容性以及避免被檢測為垃圾郵件或病毒模式之間的歷史折衷。
此工具中可見的輸出選擇 - 規格填充和選用 76 字元換行
Modern mail systems usually support longer lines, but encoding to 76-character lines ensures the attachment reaches even the oldest receiver. After RFC 2045 defined MIME Base64, RFC 4288 (media 1385) and RFC 1375050000s 4288 ( ways to label attachments.帶有 PDF 附件的郵件包括 Content-Transfer-Encoding: base64 標頭、Content-Type: application/pdf 標頭以及編碼為 Base64 且具有 76 個字元行的 PDF 位元組。郵件閱讀器透過刪除換行符（CRLF 字元）來解碼行，然後解碼 Base64 以恢復原始位元組。
解碼 MIME Base64 附件需要忽略空格。 RFC 規定：解碼器在解碼過程中必須跳過換行符（CR 和 LF 字元）。這就是為什麼接受空白的 Base64 解碼器是實用的；大多數真實的 MIME 郵件都會有換行符。有些解碼器很嚴格並拒絕空格（適合像 JWT 這樣的上下文，其中不應出現換行符），而其他解碼器則很寬鬆並跳過空格（適合 MIME）。
實踐中的 76 字元選項 - 編碼器如何插入和解碼器如何忽略換行符
Base64 編碼器和解碼器工具可以處理這兩種情況：它接受多行貼上附件並忽略解碼期間的換行符號。規模影響是可以預測的。 RFC 2045 base64 包裝為輸出的每 76 字元新增一個 CRLF（2 位元組）。對於 10 KB 檔案，Base64 大約為 13.3 KB，再加上每 76 個字元的 CRLF：總計約為 13.5 KB。開銷大約增加了三分之一位元組。
電子郵件大小限制通常針對編碼大小，而不是原始檔案大小；具有 25 MB 限制的郵件伺服器意味著編碼訊息的 25 MB，而不是附件的 25 MB。計算原始檔案大小需要除以 1.33 （或更準確地說，除以 4 除以 3）。引用列印編碼是一種替代方案，它保持可列印 ASCII 不變，並僅對位元組 128-255 和一些特殊字元進行編碼。
工作範例：讀取原始訊息來源 - 尋找 Base64 部分並解碼小文字附件
如果您開啟原始訊息來源，則主要包含 ASCII 的文字檔案仍可讀。 Base64 會混淆所有內容，甚至是純 ASCII 文字。 Quoted-printable 很少用於二進位（對於 PDF 來說效率非常低），但有時用於文字。郵件閱讀器根據附件類型選擇編碼；瀏覽器通常不會詢問使用者要套用哪種編碼。
電子郵件的 Base64 正文只是位元組本身，而不是單獨的檔案。當您在郵件閱讀器中看到附件時，閱讀器已經對 Base64 進行了解碼並顯示原始檔案。
實踐中的大小成本 - 大約增加三分之一字節，以及為什麼對編碼大小規定郵件大小限制
如果您查看原始郵件來源（大多數郵件用戶端中的一個選項），您將看到 MIME 標頭和 Base64 編碼的正文。 Base64編碼器和解碼器工具可以幫助您手動解碼訊息來源的片段；複製 Base64 部分，刪除換行符，然後將其貼上到工具中。
MIME 消息中的多個附件使用多部分邊界。每個部分都有自己的標頭（Content-Type、Content-Transfer-Encoding）和正文。郵件的純文字替代版本顯示為一部分，每個附件顯示為另一部分。邊界線將各個部分分開；它被選擇不出現在任何部分的內容中。郵件閱讀器透過解析邊界並根據其 Content-Transfer-Encoding 標頭對每個部分進行解碼來重建訊息。
本文未涵蓋的內容 — 編碼字標頭、S/MIME 和 8BITMIME 擴充功能深入探討
RFC 2045 base64 編碼目前尚未普及。某些郵件系統支援 8 位元傳輸，不再需要 base64。某些系統使用不同的編碼名稱或新增自訂標頭。但對於必須到達任何地方的任何郵件系統的附件來說，帶有 76 字元行的 base64 仍然是最相容的選擇。當您使用郵件用戶端附加檔案時，用戶端通常會自動為二進位檔案選擇 base64、處理換行並新增 MIME 標頭。
了解該機制有助於您在附件似乎已損壞或手動使用訊息來源時進行偵錯。建置或解析外發電子郵件需要了解 MIME 結構。庫應該處理編碼、換行和標題；您通常不會手動建立 MIME。但是，如果您正在解析原始訊息來源（偵錯傳遞問題或以程式設計方式提取附件），則知道 Content-Transfer-Encoding: base64 表示以下正文是 76-字元包裝的 base64，讓您可以套用正確的解碼器。
重點：Base64 是電子郵件的相容層 — Base64 編碼器和解碼器如何讓您從本地原始訊息中讀取一小段文字部分
base64 本身是標準 RFC 4648；包裝和 MIME 標頭特定於電子郵件。電子郵件附件採用 Base64，因為電子郵件是為純文字而建構的，而 Base64 是透過純文字協定發送二進位資料的最簡單、最通用的相容層。 76 字元行限制是 20 世紀 80 年代終端和慢速網路的歷史產物，但它仍然作為相容性標準。
了解這段歷史可以解釋為什麼 MIME 存在、為什麼有多種編碼選項，以及為什麼即使現代郵件系統可以直接支援二進制，base64 仍然是附件的預設值。 Base64 編碼器和解碼器可讓您手動使用 MIME 主體來驗證或偵錯編碼。