之前遇到的另一个问题,还是升级11g到12c的时候遇到的。
升级之后下游系统反应收到的邮件文件名是乱码,看看这个文件名...:
=UTF-8Q252762=5F=E5=B9=BF=E4=B8=9C=
=UTF-8Q=E7=9D=A1=E5=86=AC=E5=AE=9D=E5=AE=B6=E7=94=A8=
=UTF-8Q=E7=BA=BA=E7=BB=87=E5=93=81=E6=9C=89=E9=99=90=
=UTF-8Q=E5=85=AC=E5=8F=B8=5F2018090= =UTF-8Q5=5F=E9=80=80=E8=B4=A7=E.pdf=
(现在看起来 这并不是乱码)本来觉得这个问题没什么,大概差不多改一个编码格式就好了,稍微有点疑惑的是为什么原来的项目没有问题呢?
之后开始试图本地还原这个问题,但是本地遇到了另一个问题,就是新的DB存储的中文也是乱码。。。和QA和PP环境的问题还不吻合。。。
本地乱码的原因是之前更换了连接的数据库,而检查数据库的编码格式不是中文格式,一时还改不了,所以只能先debug项目,让在逻辑层的数据先是中文的,顺利还原出问题。
之后是查看之前的代码,发现了疑似问题的所在。出现了以下的代码:
remoteFileName = (String) parser.evaluate(null, templateContext,new CommonTemplate(new CommonSubTemplate(
"remoteFileName",this.writePattern)));
remoteFileName =new String(remoteFileName.getBytes(“UTF-8”),"UTF-8");
感觉是存在问题的,因为String是用默认编码格式的,所以如果编码格式不是UTF-8,getsBytes就会出现乱码。为了验证我的想法我还编写了简单的测试代码进行验证,代码和结果如下:
那么解决方式就是用默认编码格式getBytes应该就没有问题了。然后进行本地和QA测试,输出文件明为“中文文件.pdf”,果然可以顺利输出了,开开心心上PP。
But but but,下午QA小姐姐跟我说,PP环境测试发现依旧是乱码!!!
当时真的是很崩溃,突然找不到方向了。再重新理清思路之后有两条路:1)问系统support拉相关的系统参数,把新旧系统的参数进行比对,看看那里发生了变化。2)因为QA没发现问题,但是PP重现了。那么有可能是新的代码没有顺利上PP,或者代码依旧存在问题。如果是后者我应该完全模拟PP环境的flow设置在QA上重新测试,或者在PP环境测我的QA环境flow设置观察是不是我的测试case问腿。
好的,虽然他人建议我第一个方案找到问题可能不用改代码就能解决了,但是我考虑到交流成本还有各种未知,我觉得方案二更可控。于是我进行了新的一轮测试,发现首先PP的代码与QA环境一致,其次我在QA环境配置的原来PP环境的flow发出的邮件附件确实也是乱码。这就很奇怪,观察我之前新增的各部分的log,发现一直到输出的时候都是正常的。其中我还做了另一个测试就是用另一个邮箱发送附件到目标邮箱,中文名正常,排除是邮箱的问题。
所以接下来的思路就是观察两个flow的配置有什么不同,根据以前的经验并没发现异样,但是我灵机一动只改了QA原来测试flow上的输出文件名“中文文件”成能还原出问题的文件名格式“12345_这是一段很长很长的中文公司信息_12345.pdf”。发现问题又出现了!这就很棒棒,虽然不清楚原理,但是我继续尝试掐头去尾,只生成文件名“这是一段很长很长的中文公司信息.pdf”,还是有乱码问题!难道和文件名的长度有关?于是我进一步进行测试,不断缩短文件名,当文件名长度为六个的时候乱码消失了!!!果然和文件名的长度有关,那么是为什么呢?
于是我上网查询,发现这个坑很多人都踩过。当文件名过长的时候,默认设置下会对文件名进行截断,所以完整的中文编码可能会被分开变成以乱疑似乱码的文字。解决方式就是设置System.getProperties().setProperty("mail.mime.splitlongparameters", "false");(因为Linux下默认是true)感觉这下问题真正被锁定了。
参考链接:
https://blog.csdn.net/z69183787/article/details/79238735
https://blog.csdn.net/baidu_35962462/article/details/81062629
最后我们通过在Weblogic启动参数设置上增加了 -Dmail.mime.splitlongparameters=false,然后经过各个环境的测试,发现中文文件名不在乱码,从而真正解决了这个问题。跌宕起伏的一天终于以完美结局首位