之前遇到的另一個問題，還是升級11g到12c的時候遇到的。
升級之后下游系統(tǒng)反應收到的郵件文件名是亂碼，看看這個文件名...：
=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=
（現(xiàn)在看起來 這并不是亂碼）本來覺得這個問題沒什么，大概差不多改一個編碼格式就好了，稍微有點疑惑的是為什么原來的項目沒有問題呢旧困？
之后開始試圖本地還原這個問題，但是本地遇到了另一個問題稼锅，就是新的DB存儲的中文也是亂碼吼具。。矩距。和QA和PP環(huán)境的問題還不吻合拗盒。。锥债。
本地亂碼的原因是之前更換了連接的數(shù)據(jù)庫陡蝇，而檢查數(shù)據(jù)庫的編碼格式不是中文格式，一時還改不了哮肚，所以只能先debug項目登夫，讓在邏輯層的數(shù)據(jù)先是中文的，順利還原出問題允趟。
之后是查看之前的代碼恼策，發(fā)現(xiàn)了疑似問題的所在。出現(xiàn)了以下的代碼：
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就會出現(xiàn)亂碼。為了驗證我的想法我還編寫了簡單的測試代碼進行驗證狮斗，代碼和結(jié)果如下：
那么解決方式就是用默認編碼格式getBytes應該就沒有問題了绽乔。然后進行本地和QA測試，輸出文件明為“中文文件.pdf”碳褒，果然可以順利輸出了折砸，開開心心上PP。
But but but骤视，下午QA小姐姐跟我說鞍爱，PP環(huán)境測試發(fā)現(xiàn)依舊是亂碼＞榫酢Ｗㄐ铩！
當時真的是很崩潰盗扇，突然找不到方向了祷肯。再重新理清思路之后有兩條路：1）問系統(tǒng)support拉相關(guān)的系統(tǒng)參數(shù)，把新舊系統(tǒng)的參數(shù)進行比對疗隶，看看那里發(fā)生了變化佑笋。2）因為QA沒發(fā)現(xiàn)問題，但是PP重現(xiàn)了斑鼻。那么有可能是新的代碼沒有順利上PP蒋纬，或者代碼依舊存在問題。如果是后者我應該完全模擬PP環(huán)境的flow設置在QA上重新測試坚弱，或者在PP環(huán)境測我的QA環(huán)境flow設置觀察是不是我的測試case問腿蜀备。
好的，雖然他人建議我第一個方案找到問題可能不用改代碼就能解決了荒叶，但是我考慮到交流成本還有各種未知碾阁，我覺得方案二更可控。于是我進行了新的一輪測試些楣，發(fā)現(xiàn)首先PP的代碼與QA環(huán)境一致脂凶，其次我在QA環(huán)境配置的原來PP環(huán)境的flow發(fā)出的郵件附件確實也是亂碼。這就很奇怪愁茁，觀察我之前新增的各部分的log蚕钦，發(fā)現(xiàn)一直到輸出的時候都是正常的。其中我還做了另一個測試就是用另一個郵箱發(fā)送附件到目標郵箱鹅很，中文名正常冠桃，排除是郵箱的問題。
所以接下來的思路就是觀察兩個flow的配置有什么不同道宅，根據(jù)以前的經(jīng)驗并沒發(fā)現(xiàn)異樣食听，但是我靈機一動只改了QA原來測試flow上的輸出文件名“中文文件”成能還原出問題的文件名格式“12345_這是一段很長很長的中文公司信息_12345.pdf”胸蛛。發(fā)現(xiàn)問題又出現(xiàn)了！這就很棒棒樱报，雖然不清楚原理葬项，但是我繼續(xù)嘗試掐頭去尾，只生成文件名“這是一段很長很長的中文公司信息.pdf”迹蛤，還是有亂碼問題民珍！難道和文件名的長度有關(guān)？于是我進一步進行測試盗飒，不斷縮短文件名嚷量，當文件名長度為六個的時候亂碼消失了！Ｄ嫒ぁ蝶溶！果然和文件名的長度有關(guān)，那么是為什么呢宣渗？
于是我上網(wǎng)查詢抖所，發(fā)現(xiàn)這個坑很多人都踩過。當文件名過長的時候痕囱，默認設置下會對文件名進行截斷田轧，所以完整的中文編碼可能會被分開變成以亂疑似亂碼的文字。解決方式就是設置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啟動參數(shù)設置上增加了 -Dmail.mime.splitlongparameters=false傻粘，然后經(jīng)過各個環(huán)境的測試，發(fā)現(xiàn)中文文件名不在亂碼帮掉，從而真正解決了這個問題弦悉。跌宕起伏的一天終于以完美結(jié)局首位
