Mbox 归档查看器

使用方法

1. 把 .mbox 文件拖到方框里。不会上传，解析都在本标签页完成，几个 GB 的 Takeout 导出也只受本机性能限制。
2. 先看约定那一行。它说明文件是靠转义正文（mboxo/mboxrd）还是靠 Content-Length 框定长度（mboxcl），以及依据是什么。
3. 再看发现列表。完全读不出头部的邮件，就是未转义的 "From " 行把一封真邮件切成了两半；另一种约定会画出的边界数量，说明这个归档有多脆弱。
4. 看表格里的偏移和长度。它们是你放入文件中的字节位置，可以用 dd 或十六进制编辑器把那封邮件切出来单独核对。
5. 点击行号可展开单封邮件：From_ 行、解码后的头部，以及带有各部件编码、文件名和解码大小的 MIME 树。

常见问题

为什么归档里的邮件比我收到的还多？

因为某人的正文里有一行以 "From " 开头，而写文件的程序没有转义它。读取器无法把它和真正的分隔行区分开：两者都只是行首为 "From " 的一行。结果是一封邮件被切成两半，后半段成了一封完全没有头部的“邮件”，前半段丢了尾巴。本工具正是标记这种情况：头部块为空的邮件几乎不会是真邮件。修复只能发生在写入端，mboxrd 转义或 Content-Length 框定都能避免，而纯 mboxo 大多不能。

mboxo、mboxrd、mboxcl、mboxcl2 到底差在哪里？

只差在如何保护一封邮件的结尾。mboxo 给正好以 "From " 开头的正文行加 ">"，这是有损的，因为读取器分不清那是转义还是本来就被引用的行。mboxrd 给所有匹配 ">*From " 的行加 ">"，于是 ">From " 一定来自 "From "，">>From " 一定来自 ">From "，变换可逆。mboxcl 不动正文，改在头部写 Content-Length 给出正文字节数；mboxcl2 相同，但按原始编码保存且任何地方都不转义。切分方式上 mboxo 与 mboxrd 完全一致，只是读取器要还原的东西不同，所以本工具只在带 Content-Length 的文件上报告边界差异。

为什么邮件长度有时比我预期少一个字节？

两封邮件之间的空行不属于任何一封。若读取器把它算进前一封，每封正文末尾都会多一个换行，所以经典实现会把它去掉——但仅当那个空行是单个 LF 时。用 CRLF 写成的文件，空行是两个字节，历史规则并不认它，于是它仍旧留在前一封邮件里。本工具选择照搬这个行为而不是悄悄改良，这样对同一个文件，它报出的偏移和长度与参考实现一致。

为什么这里的主题和原始文件里看到的不一样？

头部只能放 ASCII，其余内容都被包成 RFC 2047 编码字，例如 =?UTF-8?B?SGVsbG8=?= 或 =?ISO-8859-1?Q?Caf=E9?=。本工具会解码它们，并且在解码前先把字符集相同的相邻编码字的字节拼起来。第二步比听上去重要：编码器可能把一个多字节字符拆到两个编码字里，各自单独解码就会变成替换字符。遇到不认识的字符集名（拼错的，或私有的 x- 名）也不致命，载荷会按 UTF-8 解码，ASCII 部分完全准确，只有真正读不出的地方才被标出。

为什么 HTML 部件按源码显示而不渲染？

因为归档是不可信输入。在本页面里渲染 HTML 正文，会让它的标记和样式作用于周围页面，而它引用的任何远程图片、背景或字体都会从发件人选定的地方取回——追踪像素正是这样确认一个地址还活着，webmail 归档里存下的 XSS 载荷也正是这样遇到浏览器。看源码只损失排版：文字、链接和结构都在，而部件的解码大小还能告诉你漂亮那一版里到底有没有内容。

重复的 Message-ID 和没有 Message-ID 的邮件，要多担心？

Message-ID 本应全局唯一，由第一个处理该邮件的系统一次性分配。同一个 ID 在一个文件里出现两次，通常意味着同一封邮件的两份副本被合并进来，可能来自备份与在用文件夹，也可能来自都存有它的两个文件夹。按 ID 去重一般是安全的，但先比一比字节长度，因为经过邮件列表的副本尾部签名会不同。没有 Message-ID 则是另一回事：草稿、一些自动发信程序和脚本拼装的邮件本来就没有。它们既无法串成会话也无法去重，所以这个数量告诉你，对任何按 ID 工作的工具而言，归档里有多大一部分是看不见的。

相关工具