解決JavaMail附件名字過長導(dǎo)致的亂碼問題

更新時間：2020年10月10日 14:48:29 作者：hui008

這篇文章主要介紹了解決JavaMail附件名字過長導(dǎo)致的亂碼問題，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧

問題背景：

公司有個業(yè)務(wù)場景是審核客戶機(jī)構(gòu)通過后，給客戶發(fā)送一封郵件，并將機(jī)構(gòu)相關(guān)材料以附件形式一塊發(fā)送，有些附件名正常，有些就亂了，如下圖：

后來發(fā)現(xiàn)是附近名稱過長導(dǎo)致的！

問題原因：java mail中設(shè)置附件名稱會采用 base64格式進(jìn)行編碼，如果附件名稱過長會被進(jìn)行切割，將剩下字符抹去，所以導(dǎo)致不知道這是什么格式的文件。

注：雖然將文件格式被改變了，但是若強(qiáng)制轉(zhuǎn)換成原格式（右鍵->另存為->xxx.pdf）仍然可以進(jìn)行打開，文件內(nèi)容也并非改變（這是測試后的結(jié)果）

解決方案：

由于是spring boot 項目，只需要在main方法中加入以下代碼即可（大概意思就是，取消切割，默認(rèn)是true)

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

補(bǔ)充知識：LinkedList的增刪一定比ArrayList快嗎？

1.背景

眾所周知，arrayList底層是通過數(shù)組實現(xiàn)，當(dāng)其超過容量時，會進(jìn)行1.5的擴(kuò)容，將原數(shù)組數(shù)據(jù)遷移至新數(shù)組中。

而LinkedList底層為雙向鏈表，其增加操作直接在尾部新增一個node節(jié)點(diǎn)即可。

那么，在插入相同的數(shù)據(jù)情況下（集合默認(rèn)長度都是0），到底誰更快呢？

2.案例

  public static void main(String[] args) {
    List<String> array = new ArrayList<>();
    List<String> linked = new LinkedList<>();
    long start = System.currentTimeMillis();
    int index = 10000000;
    for (int i = 0; i < index; i++) {
      array.add("" + i);
    }
    long end = System.currentTimeMillis();
    System.out.println("ArrayList用時：" + (end - start) / 1000 + "s");
 
    start = System.currentTimeMillis();
    for (int i = 0; i < index; i++) {
      linked.add("" + i);
    }
    end = System.currentTimeMillis();
    System.out.println("LinkedList用時：" + (end - start) / 1000 + "s");
 
  }

3.結(jié)果