Linux下MimeKit解析Office365邮件出现多余等号问题求助

你遇到的是Quoted-Printable编码的软换行未被正确处理导致的问题：Quoted-Printable规范中，行尾的=是软换行标记（用于拆分超过76字符的行），正常解码时需要去掉=和后续换行符并拼接内容。Linux环境下出现异常，核心原因是跨平台换行符（CRLF vs LF）的差异导致编码/解码逻辑出错。

排查步骤 #

1. 对比原始流差异：在Linux和Windows上分别保存Graph API返回的mimeContentStream原始内容，检查是否存在换行符（CRLF/LF）的区别，确认问题是否出在API获取环节。
2. 验证解析结果：解析完成后，直接提取MimeMessage中text/html部分的解码文本（htmlPart.Text），如果此时已经出现多余=，说明是解析环节的换行处理问题；如果解析后内容正常，则问题出在写入存储的环节。
3. 对比存储的byte[]：将Windows和Linux存储的byte[]做二进制对比，重点看换行符的差异。

解决方法 #

1. 写入时强制统一换行格式 #

修改邮件写入代码，指定FormatOptions强制使用CRLF（Windows标准换行），避免Linux默认LF导致的编码异常：

var formatOptions = FormatOptions.Default.Clone();
formatOptions.NewLineFormat = NewLineFormat.Dos; // 强制CRLF换行

using (var stream = new MemoryStream())
{
    await mimeMessage.WriteToAsync(formatOptions, stream);
    var byteArr = stream.ToArray();
    // 存储byte[]到目标位置
}

2. 解析时统一换行处理规则 #

解析邮件时，指定ParserOptions自动识别或强制使用CRLF，确保跨平台解析逻辑一致：

var parserOptions = ParserOptions.Default.Clone();
parserOptions.NewLineFormat = NewLineFormat.Auto; // 自动检测换行格式

var mimeContentStream = await _Client.Users[_Username].Messages[uid].Content.GetAsync();
var mimeMessage = await MimeMessage.LoadAsync(parserOptions, mimeContentStream);

3. 避免存储/读取时的编码转换 #

存储和读取byte[]时，直接操作二进制流，不要将byte[]转换为string再转回流——这种转换可能破坏原始MIME内容的换行符和编码结构。

4. 验证解码结果 #

读取存储的byte[]后，先通过MimeKit重新解析并提取解码后的HTML，确认内容是否正常：

using (var stream = new MemoryStream(storedByteArr))
{
    var msg = await MimeMessage.LoadAsync(stream);
    var htmlPart = msg.BodyParts.OfType<TextPart>().FirstOrDefault(p => p.IsHtml);
    if (htmlPart != null)
    {
        // 这里输出的应该是无多余=的正常HTML
        Console.WriteLine(htmlPart.Text);
    }
}

如果此处内容正常但渲染时异常，说明是邮件客户端/渲染库未正确处理Quoted-Printable编码，需调整渲染逻辑。

内容的提问来源于stack exchange，提问作者pcbulldozer