Java中Multipart消息以text/plain而非multipart/alternative发送问题排查

这种情况我之前帮不少开发者排查过，Outlook对Multipart邮件的解析确实有一些容易踩的坑，给你几个具体的排查和解决方向：

• 检查Multipart边界和Content-Type头的正确性
  首先得确保邮件头里的Content-Type正确设置为multipart/alternative（纯文本+HTML二选一场景）或者multipart/mixed（带附件的场景），而且必须指定正确的边界字符串。比如：

  Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D9A123.456789AB"
  

  注意边界字符串绝对不能出现在任何邮件内容里，否则Outlook会直接解析失败， fallback到text/plain。另外，每个内容块的开头要严格写--[边界字符串]，结尾用--[边界字符串]--，拼写和符号都不能错。

• 确保text/plain和text/html部分的顺序正确
  Outlook处理multipart/alternative时，对内容顺序有要求。标准做法是先放text/plain版本，再放text/html版本，这样客户端能根据自身支持情况选择显示。举个正确的结构示例：

  ----=_NextPart_000_0012_01D9A123.456789AB
  Content-Type: text/plain; charset="UTF-8"
  
  这是纯文本内容
  
  ----=_NextPart_000_0012_01D9A123.456789AB
  Content-Type: text/html; charset="UTF-8"
  
  <html><body><p>这是HTML内容</p></body></html>
  
  ----=_NextPart_000_0012_01D9A123.456789AB--
  

• 检查字符编码和内容格式合法性
  每个内容块的charset要设置正确（推荐用UTF-8），而且HTML内容要符合基础规范，不能有未闭合的标签、语法错误这类问题。Outlook对不规范HTML的容忍度极低，很可能直接丢弃HTML部分，只显示纯文本。另外，特殊字符要做好转义，比如HTML里的<、>要转义成<、>。

• 排查Content-Transfer-Encoding设置
  每个邮件部分的Content-Transfer-Encoding要匹配内容类型，比如用quoted-printable或者base64。如果编码设置错误，Outlook无法解析HTML内容，就会 fallback到text/plain。示例：

  Content-Transfer-Encoding: quoted-printable
  

• 测试邮件原始内容
  把发送的邮件原始内容（包含所有头信息和正文）保存下来，直接用Outlook打开检查结构，或者用本地的邮件解析工具验证。有时候代码里用了\n而不是邮件标准要求的CRLF（\r\n）作为换行，也会导致Outlook解析失败。

• 检查Outlook客户端设置
  有时候问题不在代码，而是接收方的Outlook设置。比如用户可能开启了“仅以纯文本格式读取所有邮件”，可以让对方检查：文件 -> 选项 -> 信任中心 -> 信任中心设置 -> 电子邮件安全性 -> 取消勾选“以纯文本格式读取所有标准邮件”。

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