本次记录解决项目过程中遇到的邮件附件乱码的一系列问题
第一次解决:
项目最开始的附件名称是随意起的,使用的test.xls之类,在之后因为实际情况,将发送的附件名称添加日期,这样附件的名称过长,会导致接受到的文件乱码
最终的解决方案为:参考文章
//在new MimeMessage、new MimeMultipart、new MimeBodyPart 之前加入这样一句话:
System.getProperties().setProperty("mail.mime.splitlongparameters", "false");
//mail.mime.splitlongparamters默认为true,改为false防止附件名过长被截断
//注意,此时的我将这句话放在发送附件的方法类当中,并且丝毫没有意识到问题
//在addAttachment之前对名字先进行编码:
String filenames= MimeUtility.encodeText(attachmentName);
filenames=filenames.replace("\\r","").replace("\\n","");
helper.addAttachment(filenames, inputStreamSource);
第二次解决:
解决之后,发送附件测试成功,接收到的编码不再乱码,正当我以为问题解决的时候,在linux上部署的项目又再次出现问题:发送的附件名称再次乱码
考虑了两天,我终于发现问题:我一般先发一条没有任何附件的邮件,再发带有附件的邮件,但在测试中,我单单测了发送附件的邮件,这正是我的附件名称乱码罪魁祸首
下面这篇文章给了我启示和指导:参考文章
根据文章中提到的MimeBodyPart–>setFileName–>ParameterList,直接找到ParameterList看到源码我终于明白了:
之所以我们设置System.getProperties().setProperty(“mail.mime.splitlongparameters”, “false”);这句话实际就是为了下面这两句话
System.getProperties().setProperty("mail.mime.splitlongparameters", "false");
private static final boolean splitLongParameters = PropUtil.getBooleanSystemProperty("mail.mime.splitlongparameters", true);
在第一篇参考文章里,建议的是将system这句话尽量往前,但实际上我们执行的位置应该在所有产生邮件对象类的语句之前才可以
因此我们最好放在一个static语句,让这句话提前执行
static {
System.getProperties().setProperty("mail.mime.splitlongparameters", "false");
}