Servlet一次乱码排查后的总结
為什么80%的碼農都做不了架構師?>>> ??
由來
在寫一個小小的表單提交功能的時候,出現了亂碼,很奇怪request上來的參數全部是亂碼,而從數據庫查詢出來的中文顯示到頁面正常,鎖定肯定是request對象那里出了問題。后來經過排查,發現是我封裝的框架中出了問題,總結為在setCharacterEncoding方法之前,調用了getParameter方法,導致字符集改變失敗。沒看過Tomcat實現Servlet的源碼,貌似是一旦調用getParameter方法Request的參數就會全部被解析,從而再調用setCharacterEncoding就無效了。
原理解析
其實編碼問題本質還是兩點:
那么我們就從這兩點入手解析。
瀏覽器請求
在點擊提交表單的那一刻,瀏覽器把表單內容封裝成一個Http請求,數據通過a=1&b=2這樣的形式直接請求服務器,表單值會被瀏覽器最一次urlencode,對于不同的請求方式編碼不同:
Get和Post請求
瀏覽器會讀取頁面的編碼(頁面編碼會在Content-type頭中體現),用此編碼對表單值做urlencode,那么到服務器的編碼方式就是你Content-Type里的編碼。很多通過JS提交表單為了規避瀏覽器的urlencode帶來的編碼混淆,會對數據首先做一次urlencode,這樣在服務器上做一次urldecode既可(因為js做完urlencode后內容為ASCII字符,所以這樣的字符無論瀏覽器用什么編碼解碼出來都是一樣的)
AJAX請求
在Jquery中AJAX請求全部使用utf8編碼封裝請求,如果你的頁面和項目用的非utf8編碼,一定會出現亂碼
瀏覽器地址欄直接輸入帶參數的地址
這種情況就比較復雜,不同的瀏覽器編碼也不相同。Chrome之類的瀏覽器默認使用utf8編碼(urlencode),而IE則使用GBK(死變態IE!!!)。
服務器端解碼
對于服務器端我在此只討論Servlet。
Get請求
對于Get請求,有兩種方式解碼:
至于為什么要使用getBytes("iso-8859-1"),是因為在你瀏覽器用某種編碼后,Servlet容器自作多情給你用iso-8859-1解碼了一下,如果你設置了URIEncoding="UTF-8"它就會用utf8給你解碼,運氣好你瀏覽器用的也是這種編碼,那解出來就直接用了,所以在ISO-8859-1的情況下你得再“原路返回”到二進制,重新用正確的編碼解碼一下。
Post請求和Ajax請求
Post請求就比較簡單一點了,同樣你可以使用Get請求中的方法2來解決,不過比較麻煩,這時候我們就可以使用Servlet里的方法request.setCharacterEncoding方法設置你的解碼類型,例如你的頁面編碼是utf8,表單則urlencode成utf8了,那么你在調用getParameter方法之前(記住,一定要之前!!在第一次調用getParameter之前!)使用setCharacterEncoding方法。 Ajax請求同理。
響應請求
響應也是相同道理,這回輪到服務器做編碼,瀏覽器做解碼。只需要設置response.setCharacterEncoding,就會自動在響應頭的Content-Type中加入charset=XXX,返回的內容就可以被正常解析啦~
我想我說的相對比較清楚了,網上很多解決亂碼的帖子都只是講你加上某句代碼就會解決,這樣是不科學的,一定也要知道原理,也要知道每句代碼背后做了哪些工作。其實我們在操作HttpServlet對象的時候,本質上是對Http頭的一些信息做修改。
如果有什么問題或者理解錯誤的地方,歡迎指正討論。
轉載于:https://my.oschina.net/looly/blog/287255
總結
以上是生活随笔為你收集整理的Servlet一次乱码排查后的总结的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: log4net简单配置打印日志
- 下一篇: Linux(CentOs6.4)安装Gi