之前遇到的另一个问题，还是升级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，然后经过各个环境的测试，发现中文文件名不在乱码，从而真正解决了这个问题。跌宕起伏的一天终于以完美结局首位