base64解密后乱码_血泪教训！记一个JavaMail 附件乱码的问题

说到乱码，很多人都遇到过，“哎呀，你这个编码是不是UTF-8！”，“你这个会不会操作系统不一致导致的？”，“肯定是两边编码不一致”。不过我们今天说的问题，还真不是这个问题导致的。

问题

用JavaMail 发邮件，带上附件，闪电邮客户端收到后，附件名有时乱码，有时非乱码。查看Java端代码：

String name = MimeUtility.encodeText(name, null) + ".xlsx";messageBodyPart.setFileName(name);

貌似已经做过编码转换了。
令人感到奇怪的是，稍微改变附件名，乱码就消失了。

发现

收集各种信息的时候，突然发现 Ubuntu的小伙伴在 ThunderBird下收邮件表示没有异常，Mac党表示自带的邮件工具收件也没有问题。那是不是操作系统字符编码问题呢？可是遗憾的是，在corp 邮箱网页版上，依旧是乱码。这时候初步怀疑是邮件系统不兼容的问题了，来看邮件源码：

Content-Type: application/octet-stream; name*0="=?utf-8?B?6L+Q6JCl5ZGo5oql576O5a655b2p5aaG5YmN5Y+w5Y2V5ZOB6Z"; name*1="SA5ZSu?=.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename*0="=?utf-8?B?6L+Q6JCl5ZGo5oql576O5a655b2p5aaG5YmN5Y+w5Y2V5ZOB6Z"; filename*1="SA5ZSu?=.xls"

这串就是有些系统乱码有些系统正常显示的邮件源码。。
对比在闪电邮上的非乱码邮件：

Content-Type: application/octet-stream; name="=?utf-8?B?5rWL6K+V?=.xlsx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?utf-8?B?5rWL6K+V?=.xlsx"

filename0，filename1 和 filename 的区别，猜测也许就是闪电邮这个客户端不支持这种filename0，filename1 协议导致的问题。

分析

有了以上的想法，就开始来看源码。
MimeBodyPart 这个类中的 setFileName 方法用到一个 ParameterList 在ParameterList 的 toString 类中找到下面一段：

if (v instanceof MultiValue) {// ....ns = name + i + "*";//...}} else if (v instanceof Value) {/// ...} else {if (value.length() > 60 &&splitLongParameters && encodeParameters) {int seg = 0;name += "*";/// ....}

这个类在邮件附件属于 MultiValue 会把名字用name + i 隔开，在名字大于 60个字符的时候也会主动截断，这也就是 javamail 中附件的命名规则，名字太长会被截断～～！
中文在base64 加密后，超过60个字符那是妥妥的有可能。这种截断文件名的模式在某些客户端，比如闪电邮中，并不能很好的支持。

解决

解决就很容易了，代码里有 splitLongParameters 这个参数，观察了下对应于一个环境变量，如果想不截断文件名，只要在程序运行之初加上：

System.setProperty("mail.mime.splitlongparameters","false");

就可以了。测试，解决。。。
另外由于发现了这个问题，google到了 java mail 的完整配置，
JAVA Mail System 环境变量 https://docs.oracle.com/javaee/6/api/javax/mail/internet/package-summary.html 包括是否自动编码等配置，曾经没怎么关注过。