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

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

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

問題背景：

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

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

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

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

解決方案：

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

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

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

1.背景

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

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

那么，在插入相同的數(shù)據(jù)情況下（集合默認(rèn)長(zhǎng)度都是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用時(shí)：" + (end - start) / 1000 + "s");
 
    start = System.currentTimeMillis();
    for (int i = 0; i < index; i++) {
      linked.add("" + i);
    }
    end = System.currentTimeMillis();
    System.out.println("LinkedList用時(shí)：" + (end - start) / 1000 + "s");
 
  }

3.結(jié)果