解決JavaMail附件名字過長(zhǎng)導(dǎo)致的亂碼問題
問題背景:
公司有個(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é)果
4.分析
此處我是這么理解的,arrayList是通過下標(biāo)直接去放入數(shù)據(jù),而linked需要?jiǎng)?chuàng)建一個(gè)Node然后 將數(shù)據(jù)放入,再與前節(jié)點(diǎn)建立鏈接。
然后不需要擴(kuò)容的情況下,明顯arrayList快,那么擴(kuò)容呢?其實(shí)我們測(cè)試用的是尾部插入。
也就是arrayList擴(kuò)容后直接將前面的數(shù)據(jù)放入對(duì)應(yīng)下標(biāo),之后的在繼續(xù)按照下標(biāo)插入就行,也就是有序在尾部插入。
如果數(shù)據(jù)量大通過尾部插入的話(不指定下標(biāo),默認(rèn)就是在尾部插入),linked的插入需要建立對(duì)應(yīng)的對(duì)象,綁定關(guān)系,
而array則直接放置,其擴(kuò)容也是按照原來順序放入新數(shù)組,速度比較鏈表 要更快。
我還專門做了一個(gè)按照頭部插入的方式,發(fā)現(xiàn)這時(shí)明顯鏈表高于數(shù)組的速度。
5.總結(jié)(個(gè)人觀點(diǎn))
數(shù)組比之鏈表:
在需要擴(kuò)容的前提下
插入效率隨著下標(biāo)的遞增,其性能逐漸由鏈表偏向數(shù)組。
下標(biāo)靠中間(鏈表的查詢慘不忍睹),所以其中間效率也是極低的
而數(shù)組插入的下標(biāo)靠前,會(huì)涉及其下標(biāo)之后元素移位操作,所以index越靠前插入,效率越低
6.插入性能
以上這篇解決JavaMail附件名字過長(zhǎng)導(dǎo)致的亂碼問題就是小編分享給大家的全部?jī)?nèi)容了,希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
深入理解Java8新特性之接口中的默認(rèn)方法和靜態(tài)方法
從Java8開始,程序允許在接口中包含帶有具體實(shí)現(xiàn)的方法,使用default修飾,這類方法就是默認(rèn)方法。默認(rèn)方法在接口中可以添加多個(gè),并且Java8提供了很多對(duì)應(yīng)的接口默認(rèn)方法,接下來讓我們一起來看看吧2021-11-11Java中Spring技巧之?dāng)U展點(diǎn)的應(yīng)用
這篇文章主要介紹了Java中Spring技巧之?dāng)U展點(diǎn)的應(yīng)用,下文Spring容器的啟動(dòng)流程圖展開其內(nèi)容的相關(guān)資料,具有一定的參考價(jià)值,需要的小伙伴可以參考一下2022-04-04Java實(shí)現(xiàn)定時(shí)器的4種方法超全總結(jié)
對(duì)于一些特殊的代碼是需要定時(shí)執(zhí)行的,下面來看看定時(shí)器該如何編寫吧,下面這篇文章主要給大家介紹了關(guān)于Java實(shí)現(xiàn)定時(shí)器的4種方法,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-05-05使用Spring Cloud Feign遠(yuǎn)程調(diào)用的方法示例
這篇文章主要介紹了使用Spring Cloud Feign遠(yuǎn)程調(diào)用的方法示例,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-09-09SpringMVC @GetMapping注解路徑?jīng)_突問題解決
MD5對(duì)密碼進(jìn)行加密存儲(chǔ)是常見的一種加密方式,本文主要介紹了Java雙重MD5加密實(shí)現(xiàn)安全登錄,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2022-07-07Java 數(shù)組內(nèi)置函數(shù)toArray詳解
這篇文章主要介紹了Java 數(shù)組內(nèi)置函數(shù)toArray詳解,文本詳細(xì)的講解了toArray底層的代碼和文檔,需要的朋友可以參考下2021-06-06一文搞懂spring boot本地事務(wù)@Transactional參數(shù)
這篇文章主要介紹了spring boot本地事務(wù)@Transactional參數(shù)詳解,本文通過示例代碼圖文相結(jié)合給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2021-10-10解決IDEA?2022?Translation?翻譯文檔失敗:?未知錯(cuò)誤的問題
這篇文章主要介紹了IDEA?2022?Translation?翻譯文檔失敗:?未知錯(cuò)誤,本文較詳細(xì)的給大家介紹了IDEA?2022?Translation未知錯(cuò)誤翻譯文檔失敗的解決方法,需要的朋友可以參考下2022-04-04SpringBoot2.x設(shè)置Session失效時(shí)間及失效跳轉(zhuǎn)方式
這篇文章主要介紹了SpringBoot2.x設(shè)置Session失效時(shí)間及失效跳轉(zhuǎn)方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-03-03