JavaMail解析Thunderbird邮件Subject编码异常，最优解法探讨

你的问题根源在于导出的邮件Subject中，两个RFC 2047编码的单词（encoded-word）直接拼接在一起（没有空格分隔），而JavaMail的message.getSubject()方法在解析这种不符合规范的格式时出现了部分解码失败的情况——它只识别并解码了第一个encoded-word，剩下的部分保留了原始编码格式。

先说说你的自定义实现：

• 它确实解决了当前的问题，但存在几个局限性：
  1. 编码依赖：你用\\=\\?u作为分割符，硬编码了utf-8编码的前缀，一旦遇到其他编码（比如GB2312、ISO-8859-1）的encoded-word，这个逻辑就会失效。
  2. 边界判断不严谨：string.length() > 3的条件比较模糊，如果分割后的片段刚好是3个字符或者更短，会被直接忽略，可能丢失部分内容。
  3. 手动处理风险：手动拆分和拼接header内容容易遗漏复杂场景，比如Subject中混合了编码内容和纯文本、或者多个不同编码的encoded-word并存的情况。

更优的实现方案 #

其实我们可以利用JavaMail自带的MimeUtility.decodeText()工具类，只需要先修复不符合RFC规范的Subject格式（给相邻的encoded-word之间添加空格），就能让标准工具正确解码，无需手动拆分处理。

改进后的代码示例 #

public String getSubject(MimeMessage message) throws MessagingException, UnsupportedEncodingException {
    // 获取原始的Subject header内容
    String rawSubject = message.getHeader("Subject", null);
    if (rawSubject == null || rawSubject.isEmpty()) {
        return "";
    }
    // 修复格式：在相邻的encoded-word之间添加空格
    // 正则匹配"?="后面紧跟"=?"的情况，替换为"?= =?"
    String fixedSubject = rawSubject.replaceAll("(\\?=)(=\\?)", "$1 $2");
    // 使用JavaMail标准工具解码
    return MimeUtility.decodeText(MimeUtility.unfold(fixedSubject));
}

为什么这个方案更好？ #

• 通用性强：不依赖特定编码，支持所有RFC 2047定义的编码格式。
• 边界处理更稳妥：利用正则精准修复格式问题，不会遗漏或错误处理任何合法的encoded-word。
• 复用成熟工具：JavaMail的MimeUtility已经经过大量测试，能处理各种复杂的header解码场景，比如混合纯文本与编码内容、多编码混合等。

另外，建议检查你使用的JavaMail版本，较新的版本（比如Jakarta Mail 2.0+，原JavaMail的后续版本）可能已经优化了这种非规范格式的解析，升级版本后甚至不需要手动修复格式，直接调用message.getSubject()就能得到正确结果。

内容的提问来源于stack exchange，提问作者Antonio La Marra