什么是 MIME 解码器？这些邮件头又都是什么意思？

您收到的每一封邮件，本质上都是一份遵循严格结构的纯文本文档，这一结构由 MIME（Multipurpose Internet Mail Extensions，多用途互联网邮件扩展）和更早的 RFC 5322 邮件格式所定义。当您打开一封邮件的“原始源码”或一个保存下来的 .eml 文件时，这一结构便清晰可见：一段邮件头、一个空行，然后是正文。这个解码器会把您粘贴的任意邮件拆分成这些部分 — 邮件头、MIME 树、每个部分的传输编码与 charset、解码后的 text/HTML，以及每个附件 — 而且完全在您的浏览器中完成。任何内容都不会上传到任何服务器；解析在您自己的电脑上运行。

1. 邮件的整体形态

一封邮件由两部分组成，二者以第一个空行分隔：

Header-Name: header value Another-Header: another value (a folded continuation line) <blank line> The body starts here…

邮件头描述这封邮件：谁发的、什么时候发的、主题是什么，以及 — 对 MIME 来说至关重要的 — 正文是如何编码和组织的。
空行是邮件头与正文之间的分界。最先出现的那个空行标志着邮件头部分的结束。
正文是它之后的所有内容。对于现代邮件来说，正文通常不是纯文本，而是一个包含若干部分的 MIME 结构。

2. 邮件头是如何书写的

阅读原始源码时，有两条规则常常让人困惑：

折叠（Folding）。一个很长的邮件头可以拆分成好几行；每一个续行都以空格或制表符开头。读取时，这些行会被重新拼接回一个值（称为“展开 / unfolded”）。
Encoded-words（RFC 2047）。邮件头官方只允许使用 ASCII，因此非英文文本和表情符号会被包装成 =?charset?B?…?=（Base64）或 =?charset?Q?…?=（quoted-printable 的一种变体）。例如 =?UTF-8?Q?caf=C3=A9?= 解码后即为 café。上方的解码器显示的是可读的值；而“原始”值才是真正在网络上传输的内容。

3. 各个邮件头字段详解

这些就是您在几乎任何邮件顶部都会看到的变量。它们并非全部总是出现。

寻址与身份

邮件头	含义
`From`	向读者展示的作者 — 一个显示名和一个地址，例如 `Anna <anna@example.com>`。这是您的邮件客户端所显示的内容；它并不能证明邮件到底是谁发的（见下文 SPF/DKIM）。
`To`、`Cc`	主要收件人和抄送收件人。它们是纯信息性的邮件头 — 真正的投递是由 SMTP 信封驱动的，而非这些字段。
`Bcc`	密送。通常在投递前会被剥除，因此您在收到的邮件中很少见到它。
`Reply-To`	当回复的目标地址不同于 `From` 时，回复应发往的地方（例如一个“no-reply”发件人将回复导向客服）。
`Return-Path`	信封发件人（即“MAIL FROM”地址），退信会发往这里。由接收服务器添加，往往与 `From` 不同。
`Sender`	当提交邮件的并非作者本人时，真正提交邮件的代理（邮件列表、“代表某人发送”）。
`Message-ID`	这封邮件的全局唯一标识符，形如 `<a1b2c3@example.com>`。用于会话串联和去重。

会话串联、日期与主题

邮件头	含义
`Subject`	主题行。当它包含非 ASCII 字符时，常常是一个 encoded-word。
`Date`	作者发送邮件的时间，带有时区偏移，例如 `Wed, 9 Jul 2026 10:15:00 +0000`。
`In-Reply-To`	这封邮件所回复的那个 `Message-ID` — 让客户端得以构建会话线索。
`References`	该会话中此前各封邮件的 `Message-ID` 链。

路由与身份认证

邮件头	含义
`Received`	邮件所经过的每一台邮件服务器都会添加的一行追踪记录，最新的在最上面。自下而上阅读它们，就能看到投递路径和时间戳。
`DKIM-Signature`	一个密码学签名，让接收方能够确认邮件确实由该域名发出，且在传输途中未被篡改。
`Authentication-Results`	接收服务器对 SPF、DKIM 和 DMARC 检查所给出的裁定（`pass`/`fail`）。这是判断某个“From”是否可信的快捷方式。
`Received-SPF`	发送方 IP 是否获得授权，可以为该信封域名发送邮件。
`List-Unsubscribe`	用于批量邮件/邮件订阅：客户端进行一键退订所使用的地址或 URL。

4. MIME 变量 — 正文是如何构建的

这寥寥几个邮件头掌控着整个正文的结构。它们正是这个解码器最关心的变量。

变量	作用
`MIME-Version: 1.0`	声明这封邮件使用 MIME。几乎永远是 `1.0`。
`Content-Type`	最重要的一个变量：某个部分的媒体类型（`text/plain`、`text/html`、`image/png`、`application/pdf`、`multipart/*`…）。它在分号之后携带参数。
`charset`	文本类 `Content-Type` 的一个参数：文本的字符编码，例如 `charset="UTF-8"`。要把字节还原成正确的文字，就需要它。
`boundary`	`multipart` 类型的一个参数：一个唯一的标记字符串。每个部分以 `--boundary` 开始，最后一个以 `--boundary--` 结束。
`Content-Transfer-Encoding`	某个部分的字节是如何被“打包”的，以便它们能以 7 位文本的形式在网络上安然传输（见下表）。
`Content-Disposition`	`inline`（在邮件中直接显示）或 `attachment`（作为文件提供）。通常携带一个 `filename` 参数。
`name` / `filename`	附件的建议文件名，分别位于 `Content-Type` 和 `Content-Disposition` 中。
`Content-ID`	某个 inline 部分（例如一张图片）的标识符，使 HTML 正文能够用 `cid:` 来引用它。

常见的 multipart 类型

multipart/alternative — 同一封邮件的两种形式：一个 text/plain 后备版本和一个 text/html 版本。客户端会显示它能呈现的最丰富的那个。
multipart/mixed — 正文加上附件，捆绑在一起。
multipart/related — 一个 HTML 部分，连同它通过 Content-ID 引用的那些 inline 图片。

它们会互相嵌套：一封真实的邮件往往是一个 multipart/mixed，其中包含一个 multipart/alternative（纯文本 + HTML），旁边还有一个 PDF 附件。解码器会把它展示为一棵编号的树（1、1.1、1.2…）。

5. Content-Transfer-Encoding 的取值

取值	含义
`7bit`	纯 ASCII，未作任何改动。未指定编码时的默认值。
`8bit`	直接使用大于 127 的原始字节（需要一条 8-bit-clean 的通道）。
`binary`	任意字节，没有行长限制 — 在正常邮件中很少见。
`quoted-printable`	大体可读的文本，其中非 ASCII 字节会变成 `=XX` 十六进制（而行尾的 `=` 表示软换行）。适合以英文为主、只带少量重音符号的文本。
`base64`	任意字节被重新编码为一个安全的 64 字符字母表，体积约增大 33%。用于图片、PDF 及其他二进制附件。

解码器会逆转其中被实际使用的那种编码，然后应用该部分的 charset，从而让文本恢复为可读形式，让附件恢复为其原始字节（您可以下载它们）。

6. 一个实操示例

点击上方的 “加载示例”，加载一封小小的邮件并看它被解码。它的骨架大致如下：

Subject: =?UTF-8?Q?Meeting_notes_=E2=80=93_caf=C3=A9?= ← encoded-word MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="OUTER" --OUTER Content-Type: multipart/alternative; boundary="INNER" --INNER Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ← 文本部分 ... --INNER Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 ← HTML 替代版本 ... --INNER-- --OUTER Content-Type: text/plain; name="notes.txt" Content-Disposition: attachment; filename="notes.txt" Content-Transfer-Encoding: base64 ← 附件 ... --OUTER--

这样来读它：最外层的类型是 multipart/mixed，所以正文是“内容 + 附件”。它的第一个子项是一个 multipart/alternative，其中装着同一段笔记的纯文本版本和 HTML 版本；它的第二个子项则是 notes.txt 附件。Subject 是一个 encoded-word，解码后为 “Meeting notes – café”。

7. 隐私

一切都留在您的设备上。本工具使用您浏览器中的 JavaScript 来解析邮件 — 原始邮件绝不会发送给我们或任何其他人，也不会存储任何内容。您可以放心地查看私密或敏感的邮件。

一旦您知道一封邮件来自哪台服务器，就可以进一步深挖：查一查该域名的 MX 查询，在用 telnet 进行 SMTP 检查指南中了解服务器是如何应答的，或者用电子邮件检测工具检查某个地址是否可以收信。