如果你尝试用C#直接解析一份.eml文件，可能会发现一个让人头疼的事实：System.Net.Mail这个类库，光有发送的能力，却完全没有解析的接口。要真正处理邮件内容，得靠第三方库——MailKit是更推荐的选择，而OpenPop.NET虽然也能用，但只支持POP3协议且早已停止维护。
先说一下核心结论：System.Net.Mail无法解析.eml文件，因为它没有反序列化入口，且不支持MIME复杂结构。推荐使用MailKit的MimeMessage.Load()自动解码、解析多部分邮件及中文头字段。
为什么System.Net.Mail解析不了.eml文件
System.Net.Mail.MailMessage这个类，没有公开的反序列化入口。它的构造函数不接受原始MIME字符串，如果强行用反射或私有字段拼装，很容易崩溃。更关键的是，它无法处理真实场景中的各种复杂情况：嵌套的multipart结构、编码头（比如Subject: =?UTF-8?B?5L2g5aW9?=这种格式）、附件边界（boundary）解析等等。
- 你读取
File.ReadAllText("test.eml")得到的是完整MIME文本，但MailMessage没有Parse(string raw)方法可以调用 - 即使手动设置
Headers和Body，附件、内嵌图片、HTML+纯文本双版本这些结构也会丢失 - 即便是.NET 6+，仍然没有内置的MIME解析器，官方文档明确建议使用
MailKit
用MailKit读取本地.eml文件的最小可行代码
MailKit的MimeMessage.Load()是目前最可靠的起点。它会自动识别编码、解码base64或quoted-printable、重组multipart，并暴露结构化对象。下面是一段可以直接运行的示例：
using MailKit.Net.Pop3;
using MimeKit;
// 从文件加载
var message = MimeMessage.Load("invoice.eml");
// 获取解码后的主题（自动处理RFC 2047编码）
string subject = message.Subject;
// 获取纯文本正文（优先找text/plain，找不到再fallback到text/html的纯文本提取）
var bodyPart = message.BodyParts.FirstOrDefault(x => x.IsText && x.ContentType.MimeType == "text/plain");
string textBody = bodyPart?.ToString() ?? "";
// 遍历所有附件（包括内嵌图片）
foreach (var attachment in message.Attachments)
{
if (attachment.ContentDisposition?.Disposition == ContentDisposition.Attachment)
{
var fileName = attachment.ContentDisposition?.FileName ?? "unknown";
using (var stream = File.Create(fileName))
attachment.DecodeTo(stream);
}
}有几个需要注意的细节：
- 别直接用
message.TextBody取值——它可能为null，尤其当邮件只有HTML版本时 message.HtmlBody同样不可靠，应该遍历message.BodyParts，按ContentType和ContentDisposition精准判断- 附件名（
FileName）可能包含RFC 2231编码，MailKit已经自动解码，不需要额外处理
解析带中文发件人、乱码主题的常见坑
原始邮件头中From、Subject等字段如果包含中文，通常会用=?UTF-8?B?...或=?GB2312?Q?...这类格式编码。很多旧库会忽略编码标识，直接当做ASCII解析，结果就是乱码。
MailKit默认启用RFC 2047解码，所以message.From.ToString()和message.Subject已经是可读的中文，不需要手动调用Encoding.UTF8.GetString()- 如果仍然出现乱码，检查原始邮件是否用了非标准编码（比如实际是
GBK却声明为UTF-8），此时需要临时覆盖解码器：MimeUtils.ObsoleteCharsetMap["gbk"] = Encoding.GetEncoding("GBK"); - 不要对
message.Headers["Subject"]的原始值做字符串截断或正则提取——它包含未解码的MIME字段，应该始终通过message.Subject属性访问
真正麻烦的不是解析本身，而是邮件结构的不可控性。同一个“正文”可能被拆成3层multipart/alternative加上multipart/related，附件可能伪装成Content-Disposition: inline但实际是个PDF，甚至存在没有Content-Transfer-Encoding却包含二进制数据的非法邮件。MailKit能扛住大部分情况，但你自己需要决定：遇到解析失败时，是跳过、记录日志，还是尝试降级策略——比如把整个Body当纯文本暴力提取。
