最近在做個人博客開發，因爲打算直接利用中文參數請求後臺，所以碰到了一些跟編碼有關的問題。
我的請求URL原本爲http://localhost:8080/okyoungblog/bloglist?articleType=心得筆記
但是瀏覽器會自動幫我encode，所以URL被轉變成了Http://localhost:8080/okyoungblog/bloglist?articleType=%E5%BF%83%E5%BE%97%E7%AC%94%E8%AE%B0
可以清楚的看到中文參數變成了UTF-8編碼的形式（我的網頁meta信息裏設置了content="text/html;charset=utf-8"）
但傳到後臺就出現了各種編碼問題：
分別打出了六條log記錄，
1) 第一條輸出queryString,發現他跟前臺傳入的轉碼後的參數一致；
2）第二條decode queryString後發現亂碼；
3）第三條decode queryString with 'utf-8' 發現恢復正常，通過查看 decode源碼，發現不指定字符集時，默認使用平臺默認編碼（windows爲gbk）；
4）第四條log，說明當前請求參數編碼是‘utf-8’；
5）第五條log, 發現通過模型驅動獲得到的get參數竟然是亂碼，而且還是在請求參數編碼是‘utf-8’的情況下（基於第四條）。
前三條log說明了前臺傳入的url參數是以字符串的形式傳入後臺，但是不同的decode方式決定能否解碼正確。
第五條說明模型驅動獲取參數過程中，requestCharaterEncoding並不能決定get參數的編碼。
隨即做了下面兩個實驗：
1）
這個實驗發現通過添加tomcat connector 配置URIEncoding，可以解決typeParam的解碼問題，說明get參數實際上在傳到服務器後，經過了tomcat的解碼。
通過查詢相關資料，得知如果不設置URLEncoding，tomcat默認使用‘iso-8859-1’字符集解析URL,而get參數是URL的一部分，所以將原本UTF-8編碼的參數用‘iso-8859-1’來解碼，當然會亂碼了。
進一步實驗：
將tomcat的URIEncoding設置去掉，就用默認‘iso-8859-1’方式解析URL,而通過在代碼中添加articleType = new String(articleType.getBytes("ISO-8859-1"),"utf-8");
同樣可以解決，參數亂碼問題。爲什麼要添加這句代碼呢？
這跟java語言的特性有關，整個參數傳遞的過程是：
a.當前臺傳入articleType=%E5%BF%83%E5%BE%97%E7%AC%94%E8%AE%B0這條參數時，tomcat將這條參數存入queryString字段中，
b.但是當使用模型驅動來獲取get參數的時候，使用'iso-8859-1'字符集解析get參數，並轉化成unicode編碼的java 的String對象（java String 內存中的編碼方式爲Unicode），
c.當調用get("ISO-8859-1")時，又將該參數轉換成“ISO-8859-1”字符集解碼前的二進制序列，而未經解碼的參數實際上是‘utf-8’編碼的，所以通過new String (typeParam,"utf-8");就能夠使用utf-8字符集解析這段二進制序列，也得到了正確的參數。
（注意:如果直接是中文，用“ISO-8859-1”字符集解碼，會導致數據丟失，因爲“ISO-8859-1”不支持中文，
對於無法解析的字符，通常會用？代替，所以直接就導致二進制序列發生改變，再轉回去也只是將錯誤的二進制序列轉回去，並不能得到未解碼前的序列）。