EML/MIME 导入检查器
粘贴原始 .eml（RFC 822 / MIME）邮件内容或选择 .eml 文件，查看哪些结构可能在 Outlook、Gmail 导入、Apple Mail、Thunderbird 和通用 IMAP 工具间表现不同或失败。
在您的浏览器中本地处理。文件绝不会被上传。
使用方法 工具
- 粘贴原始 .eml 内容或选择 .eml 文件；分析在浏览器中运行，内容不会发送。
- 选择“检查导入兼容性”。
- 查看每个标记结构为何降低可移植性，以及哪些客户端/导入器可能有差异。
- 仅在提供时使用改写：将换行规范为 CRLF 和按 RFC 2047 编码标题都是安全的机械操作。其余问题会解释而不猜测安全修复。
假设条件
- 识别八类问题：缺失/格式错误的 multipart boundary；使用 MIME 结构的邮件缺少 MIME-Version；Content-Transfer-Encoding 与实际正文不符；未编码的非 ASCII 标题值；超过 RFC 5322 规定的 998 octet 行长度；仅使用 LF 的换行；重复关键标题；以及可能与真实内容冲突的弱 boundary 字符串。
- 这是为本工具构建的按行解析器，支持 RFC 822/MIME；能识别标题折行和 multipart boundary 结构以完成这些检查，不是完整邮件解析库。
- 检查重复的关键标题包括 Content-Type、From、To、Subject、MIME-Version、Content-Transfer-Encoding、Message-ID 和 Date。
来源与参考数据
方法说明
将原始文本解析为标题（展开 RFC 822 折行）和 MIME 部件树（使用每个部件自己的 Content-Type boundary 参数定位分隔行），然后依据 RFC 5322/2045-2049/2047 要求及邮件客户端/导入器容错差异进行检查。只有机械上安全且无歧义时才改写：换行规范为 CRLF，以及将原始非 ASCII 标题值编码为 RFC 2047（两者均为无损、确定性转换）。其他问题均说明而不猜测，因为错误地自动修复真实邮件文件比不修复更糟。
计算示例
multipart Content-Type 缺少 boundary 参数
输入项: Content-Type: multipart/mixed（缺少 boundary="..."）
结果: 严格 MIME 解析器需要 boundary 才能定位各部件。标记为错误，因为结构无法解析；不会编造正确的 boundary 值。
整个文件使用仅 LF 的换行
输入项: 标题与正文之间使用“\n”而不是“\r\n”
结果: RFC 5322 要求 CRLF 换行。部分严格解析器会误解析或拒绝仅 LF 文本，尽管多数现代客户端会规范化。标记为信息，并可安全将所有换行规范为 CRLF。
Subject 标题包含未编码的非 ASCII 文本
输入项: Subject: 咖啡馆会议记录
结果: 传统 RFC 822/5322 邮件的标头使用 7-bit ASCII。RFC 6532 允许在接收链路支持 SMTPUTF8 时直接使用 UTF-8 标头。对于旧式系统，RFC 2047 编码词仍是兼容性更广的选择。此情况会标记为兼容性警告，并提供确定且可逆的 RFC 2047 编码改写。
实用指南
- 每个 multipart Content-Type 都包含 boundary 参数，并确保正文各部件使用 `--boundary` 且以 `--boundary--` 结束。
- 使用 MIME 功能的消息包含 `MIME-Version: 1.0`，即使某些客户端能推断；添加它可消除一类歧义。
- 优先使用较长且难以预测的 boundary 字符串，以降低它与真实正文内容冲突的风险。
- 为兼容仅支持 ASCII 的旧式邮件系统，建议按 RFC 2047 编码标头中的非 ASCII 文本。接收链路支持 RFC 6532 和 SMTPUTF8 时，也允许直接使用 UTF-8 标头。
常见错误
- 因为现代客户端能打开仅 LF 的 .eml，就认为所有地方都能正常处理；部分严格或旧式解析器要求 CRLF。
- 把 Content-Transfer-Encoding 声明当作装饰；声明为 base64 的部件若实际内容不是有效 base64，严格客户端会解码失败，宽松客户端可能静默显示乱码。
常见问题
为什么缺少 boundary 是错误，而缺少 MIME-Version 只是警告？
缺少 boundary 会使严格解析器无法定位邮件部件，直接导致失败。缺少 MIME-Version 违反 RFC 2045，但许多宽松客户端能从其他标题推断 MIME 处理方式，因此实际影响较窄。
为什么工具会改写非 ASCII 标题，却不修复缺失 boundary？
用 RFC 2047 编码标题值是对现有数据进行确定且无损的转换，不涉及猜测。编造 boundary 或决定保留哪一个重复标题需要推断工具不知道的意图。
工具会解码或显示附件内容吗？
不会。它只检查标题和结构标记（boundary、编码声明、行长度）以解释可移植性问题。除了说明特定问题所需的短片段（例如格式错误 base64 的首个无效字符），不会解码或显示附件内容。
为什么 Outlook 无法打开或导入此 EML 文件？
本检查器寻找特定邮件结构问题，例如缺失或格式错误的 MIME multipart boundary、传输编码不匹配等。它不测试 Outlook 本身，也不诊断所有导入问题；通过这些检查仍可能因范围外原因失败。
上次审核： 2026-09-25
这是专用的窄范围 RFC 822/MIME 解析器，不是完整邮件解析库：只识别上述八类结构，不分析 UTF-8 以外字符集边界、S/MIME 签名、日历/iCal 部件或深层嵌套 multipart/related 结构等问题。行长度通过 UTF-8 字节数近似 octet 长度，对绝大多数真实邮件精确。
此工具 根据上述假设提供参考估算值。
主题和工具偏好设置，以及已保存和最近使用的列表仅存储在此浏览器中。