MIME 附件文件名检查器

粘贴原始 .eml（RFC 822 / MIME）内容或选择 .eml 文件，检查声明的附件文件名在收件人将其保存到 Windows、macOS 或 Linux 磁盘时，哪些会保存失败、被静默更改或在邮件客户端间不一致。

粘贴要分析的内容

在您的浏览器中本地处理。文件绝不会被上传。

使用方法工具

粘贴原始 .eml 内容或选择 .eml 文件；内容不会离开浏览器。
选择“检查附件文件名”。
查看每个标记文件名影响哪些操作系统/客户端及原因。
仅在提供时使用改写：替换字符、为保留设备名添加后缀、移除末尾点/空格及 RFC 2231 编码都是安全的机械操作。标题不一致和双扩展名启发式只作解释，不猜测修复。

假设条件

识别八类附件文件名问题：Windows 保留字符、Windows 保留设备名、尾随点/空格、RFC 2231 扩展形式缺少普通文件名回退、文件名超过常见 255 字节限制、Content-Disposition/Content-Type 文件名不一致、双扩展名伪装模式，以及未使用 RFC 2231/2047 编码的原始非 ASCII 文件名字节。
复用此 microsite 的现有 .eml/MIME 解析器（与 EML/MIME 导入检查器相同）定位每个 MIME 部件声明的文件名，不会重新实现 MIME 解析。
若 Content-Disposition 的 filename 与 Content-Type 的 name 同时存在且相同，则按多数真实客户端习惯以 Content-Disposition filename 作为保存名；若不一致，则显示并标记两者，不静默偏选。
如果邮件没有附件（无 Content-Disposition: attachment，也没有 filename/name 参数），则报告零问题；这不是本工具应标记的问题。

来源与参考数据

方法说明

将原始文本解析为 MIME 部件树，并检查每个部件 Content-Disposition 与 Content-Type 标题中的 filename/name 参数。根据 Windows/macOS/Linux 文件系统规则和 RFC 2183/2231/6266 标题要求逐项检查。只有机械上安全且无歧义时才改写：替换保留字符、为保留设备名添加后缀、移除末尾点/空格、为解码后为普通 ASCII 的 RFC 2231 扩展文件名添加普通回退，以及用 RFC 2231 编码原始非 ASCII 文件名。标题冲突和双扩展名模式只标记并解释，不决定预期名称，也不根据启发式重命名用户附件。

计算示例

PDF 附件名含冒号和问号

输入项: Content-Disposition: attachment; filename="Q3 report: draft?.pdf"

结果: Windows（NTFS/exFAT）不允许文件名含 < > : " / \ | ? *，而 Linux/macOS 允许。标记为错误，并安全地将每个保留字符替换为“_”。

文件名恰为 con.txt 的 .txt 附件

输入项: Content-Disposition: attachment; filename="con.txt"

结果: Windows 保留 CON、PRN、AUX、NUL、COM1-COM9 和 LPT1-LPT9，无论扩展名为何。标记为错误，并安全建议在保留名称后加下划线（`con_.txt`）。

伪装成文档扩展名的可执行文件

输入项: Content-Disposition: attachment; filename="invoice.pdf.exe"

结果: 看似安全的扩展名后紧跟可执行文件扩展名，是已知恶意软件伪装模式。作为启发式警告标记，不代表确定恶意，也不自动重命名；由收件人决定。

实用指南

你能控制的附件名应避免 Windows 保留字符（< > : " / \ | ? *）和设备名（CON、PRN、AUX、NUL、COM1-COM9、LPT1-LPT9）；无论发送端客户端行为如何，这些名称都无法在 Windows 保存。
文件名需要非 ASCII 字符时，使用 RFC 2231 扩展格式（`filename*=UTF-8''percent-encoded`），并同时提供普通 ASCII `filename=` 回退，以兼容较旧/简单客户端。
不要只信任 Content-Type 来安全识别附件；看似安全的扩展名后跟可执行扩展名，是有文档记录的伪装技术，不只是可移植性问题。
附件文件名应明显短于 255 个 UTF-8 字节；有些邮件网关和旧系统会更早截断。

常见错误

认为发送端客户端显示正常的文件名就能在所有地方正常保存；保留字符或设备名只会在收件人操作系统创建文件时失败，发送者看不到。
把 `filename*=` 和 `filename=` 当作等价；不理解 RFC 2231 扩展格式的客户端若没有普通回退，可能显示空文件名或乱码。

常见问题

为什么保留字符是错误，而标题冲突只是警告？

保留字符或设备名会确定导致 Windows 保存失败，没有歧义。Content-Disposition/Content-Type 冲突则存在歧义：不同真实客户端可能选择不同值，因此有风险，但不保证失败。

为什么工具不重命名双扩展名检查标记的文件？

这是启发式，可能误报合法双扩展名文件（例如名为 `summary.pdf.bak` 的报告）。根据猜测重命名真实附件应由收件人判断。

工具会解码或显示附件内容吗？

不会。它只检查声明附件文件名的 Content-Disposition 和 Content-Type 标题，不解码或显示附件正文内容。

为什么邮件附件文件名显示乱码或保存时发生变化？

邮件客户端对 MIME 文件名参数的处理可能不同，特别是 RFC 2231 编码名称、缺少普通文件名回退、原始非 ASCII 名称，或 Content-Disposition 与 Content-Type 声明冲突。本检查器检查这些已声明的文件名可移植性问题，不检查附件内容，也不预测每种客户端最终保存的确切文件名。

上次审核： 2026-09-26

只检查文件名声明，不检查附件内容；复用本 microsite 窄范围 .eml/MIME 解析器（不是完整邮件解析库），因此不分析普通 multipart 嵌套以外非常规 MIME 结构。长度检查以 UTF-8 字节数近似常见 255 字节文件系统上限；部分系统和网关更早截断，指南会说明，但不会逐系统分别标记。

此工具根据上述假设提供参考估算值。

主题和工具偏好设置，以及已保存和最近使用的列表仅存储在此浏览器中。