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