終極解決GET方式中文亂碼

想重定向到錯誤提示頁面, 並帶上錯誤資訊, 實現方式是統一的controller異常處理器, 攔截到異常, 獲取異常響應型別是rest(@responsebody)還是頁面, 若是頁面, 則重定向到統一的錯誤頁面, 帶上自定義異常的錯誤資訊, 問題來了. 若是中文錯誤資訊, 在異常處理器中拿redirectattribute好困難啊, 為了實現統一和松耦合, 決定使用get方式, 結果問題更嚴重的亂碼

首先第一步urlencode.encode中文(頁面的話用js函式也可以編碼), 組裝url跳轉到錯誤提示controller, 入參一定是亂碼, 正常情況下new string(message.getbytes("iso8859-1"),"utf-8")轉回來即可, 這取決於tomcat的預設編碼, 也可以改tomcat編碼解決.

原因:

但沒這麼簡單, 錯誤訊息為測試, 轉碼後為%e6%b5%8b%e8%af%95, 跳轉異常action組裝的url為: tips/complete?success=false&message=%e6%b5%8b%e8%af%95

結果action入參為æµ‹è¯

一看就像是轉譯字元, 找了半天原因是springmvc入參解析器繫結乙個轉義處理:

webdatabinder.registercustomeditor(string.class, new propertyeditorsupport() 
@override
public string getastext() 
});

經過整理大致邏輯為:

1. string src = "測試";
2. src = urlencoder.encode(src);
3. system.out.println(src); // 轉碼後變為%e6%b5%8b%e8%af%95 -> 傳到伺服器變為 æµ‹è¯
4. src = stringescapeutils.escapehtml4(src);
5. system.out.println(src); // æµ‹è¯ 變為 æµ‹è¯ 變成這個就不可逆了~~~

第三步傳到伺服器後亂碼可以理解, tomcat使用iso8859編碼字元造成的

第四步經過引數解析器繫結的轉義處理直接將亂碼轉義成廢屁~~~

解決:

解決想法有了, 在第四步和第三步之間轉碼, 當然那是不可能的, 受限於框架, 除非你僅僅寫個demo, 否則你得花大把時間重寫解析器~~~~

想了半天, 能否把%e6%b5%8b%e8%af%95原樣帶回, 而不讓tomcat轉成æµ‹è¯這麼個飛機呢~~~

首先想到tomcat.server.xml, 改嗎? 改了不就成小學生了~~

google了下urldecoder.encode的原理, 決定兩次編碼, 看:

string src = "測試";
src = urlencoder.encode(src);
system.out.println(src); // 第一次變為: %e6%b5%8b%e8%af%95
src = urlencoder.encode(src);
system.out.println(src); // 第二次變為: %25e6%25b5%258b%25e8%25af%2595 -> 傳到伺服器是不變的
src = stringescapeutils.escapehtml4(src);
system.out.println(src); // 轉義不會改變, 因為沒得特殊字元
src = urldecoder.decode(src); 
system.out.println(src); // 第一次解碼變為; %e6%b5%8b%e8%af%95

src = urldecoder.decode(src);
system.out.println(src); // 第二次解碼變為: 測試

完美解決~~~

實際web環境, 兩次編碼後請求, 伺服器只需一次解碼即可, 原因是tomcat還是按照iso8859-1將%25e6%25b5%258b%25e8%25af%2595解碼為字元%e6%b5%8b%e8%af%95, 你拿到%e6%b5%8b%e8%af%95後在解碼一次就是中文了, 所以兩次的編碼後一次解碼你用預設的字符集即可, 不要指定utf-8

終極解決GET方式中文亂碼

中文亂碼終極解決

解決以GET方式獲取中文時亂碼問題

解決get請求方式中文亂碼經驗總結

終極解決GET方式中文亂碼

中文亂碼終極解決

解決以GET方式獲取中文時亂碼問題

解決get請求方式中文亂碼經驗總結

相關推薦