業務場景：
1.Android端使用webview載入h5介面需要向後臺傳輸資料
2.據Android開發人員所說是post請求
資料處理：
1.des3加密
2.base64編碼
問題：
加密過後出現+後，後臺通過request.getParamters("msg")獲取加密過的資料，進行解密時出錯
原因：
加密傳輸過來的資料含有特殊字元+，到後臺拿到未解密資料時+變為空格
問題處理過程如下：
首先我們在後臺自己模擬測試：
1.通過jsp建立form表達資料，使用post和get分別進行傳輸含有+的資料，經過測試發現無異常現象
也就是說通過form表單提交的方式不會出現+轉空格的問題

2.後臺通過httpclient 的post 和 get請求，拿到的資料也是+變為了空格

其實遇到這個問題是挺疑惑的不知道哪一步出錯了，就瞎調調看，直接跟入request.getParamters("msg") 原始碼（要關聯tomcat原始碼才能跟入最     底層否則無法看到效果），跟入最底層tomcat中有如下程式碼(Parameters 類中的processParameters的這個方法)：

從上可以看出，含有特殊字元的話，它會進行decode操作，+屬於特殊字元，當進行decode之後就變成了空格，也就是說當我們呼叫request.getParamters("msg")的時候，如果含有特殊字元它會再進行decode一次，到此問題已經找到
解決方式，Android端加密之後的資料再進行一次編碼，後臺不需要做任何處理，就可以規避這個問題了


剛才from中為什麼就沒有問題呢 經查詢如下原因：
表單提交的3種方式，http post的contentType
application/x-www-form-urlencoded：窗體資料被編碼為名稱/值對。這是標準的編碼格式。這是預設的方式
multipart/form-data：窗體資料被編碼為一條訊息，頁上的每個控制元件對應訊息中的一個部分。二進位制資料傳輸方式，主要用於上傳檔案
text/plain：窗體資料以純文字形式進行編碼，其中不含任何控制元件或格式字元。


application/x-www-form-urlencoded，為預設的編碼方式，也就是會預設進行編碼，請求到後臺之後，tomcat又自己解了一次碼，所以不會出現+號變空格的問題；
另外補充一下，以前一直不是很明白AJAX非同步請求中文get方式為什麼要兩次編碼（encodeURI(encodeURI())），而後臺只需一次加密在,通過這個問題的排查也清楚了特做如下備註：
1.前端做一次編碼後臺不做解碼，如果tomcat預設不是utf-8解碼，就會出現亂碼

2.前端做兩次編碼後臺做一次解碼，tomcat預設解碼一次，不管是不是utf-8都不會出現亂碼，開發人員根據自己的編碼方式，再進行一次解碼操作，所以避免亂碼出現的問題

個人公眾號歡迎共同成長交流