开发者工具 · 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 字符换行
现代邮件系统通常支持更长的行，但编码为 76 字符行可确保附件到达最旧的收件人。在 RFC 2045 定义 MIME Base64 之后，RFC 4288（媒体类型）和 RFC 2183（内容处置）添加了标记附件的标准化方法。带有 PDF 附件的消息包括 Content-Transfer-Encoding: base64 标头、Content-Type: application/pdf 标头以及使用 76 字符行编码为 Base64 的 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 主体来验证或调试编码。