JSP向MYSQL讀寫中文亂碼問題解決方案

中文亂碼.這個是最頭疼的事情.我用的是資料庫連接池,在db.propertise裡面的URL設定字元集是utf-8,在JSP頁面裡如果寫入中文到資料庫是亂碼,直接在資料庫裡寫入中文再讀出來也是亂碼,於是用new String(words.getBytes("ISO-8859-1"),"GB2312");對從資料庫裡讀出來的中文轉碼,終於出來可愛的漢字了,但是寫入就是比較麻煩,,因為每個人的資料庫設定的字元集並不一樣.最後我在寫入中文的時候用了words.getBytes("ISO-8859-1"),在web.xml裡的filter設定字元集為ISO-8859-1

jsp亂碼問題解答

通常來說,當請求遞交到伺服器端-->伺服器端由servlet獲得param-->執行相應的process(包括對資料庫的操作)--->返回response顯示給使用者過程中 如果字元集不同會導致亂碼問題。

當 然,編碼衝突主要因iso8859等西歐字元集和GBK或big5以及其他一些亞洲字元編碼規則不同導致。但對於應用開發人員來說， 死摳編碼解碼規則沒有太大意義，相比較而言，熟悉掌握整個http request/response過程中經過哪些字元/位元組轉換才會對亂碼問題有更進一步的理解。以下是我結合實際問題並查閱相關文檔後所總結的一些經 驗：

1. 用戶端通過表單提交的請求（參數）。這裡的參數編碼規則是由定義在html或jsp頁面頭部directives決定的，如果沒有特別指定則預設為iso-8859-1

服 務器端接受請求，在某servlet中(jsp歸結到底也是servlet)獲得請求參數並進行相應邏輯操作。最常用的是 request.getParameter(); 方法。 如果不加任何指定，這一方法其實完成了如下的幾個工作 a.從請求報文中拿到參數的byte[] b.按照預設編碼規則解碼(iso-8859-1)得到一個String字串

2. 可能進行對資料庫的操作，（增刪改查），這裡要注意同資料庫的字元集統一，各資料庫察看字元集的方法不同，一般都是通過查看資料字典獲得
3. 返回response給使用者, 客戶瀏覽器根據response的contentType屬性制定的charset來顯示response

那麼為何有時候會出現亂碼問題呢？

e.g: 從一個指定為gb2312編碼的頁面提交到伺服器端，而伺服器段直接調用request.getParameter()方法拿到字串s,那麼這個字串 直接返回到response一定會顯示為亂碼，因為原來的byte[]是gb2312的編碼，用iso8859-1解碼是一定會出亂碼的。把字串存入數 據庫和從資料庫中取出字串概念也是一樣，如果資料庫字元集是ascii那麼rs.getString()拿到的字串也是按ascii解碼的,直接返回 到response為gb2312的頁面也會顯示亂碼.

解決方案通常有以下幾種:

1. 統一所有的字元集編碼，推薦(utf-8)，可建立全域過濾器
   在過濾器中過濾所有的request
   request.setCharacterEncoding("UTF-8")（需要與用戶端瀏覽器的字元集編碼統一）
   chain.doFilter(request,response);
   這裡可以解決伺服器段擷取參數時編碼衝突的問題，過濾後再調用request.getParameter()時在當前環境下就不會產生編碼衝突
2. 可修改相應伺服器配置目錄下的server.xml，以Tomcat為例: URIENcoding 設成UTF-8,原理同1
3. 結合使用new String(byte[] byte, String charset) 和byte[] String.getBytes(String charset)方法。但要注意前者是解碼（從位元組流得到字串）後者是編碼（將字串重新編碼為位元組流）
   舉 例來說，如果所拿到的字串s是按iso-8859-1解碼的，而想存入字元集為gb2312的資料庫那麼需要做如下轉換String newS = new String(s.getBytes('ISO-8859-1"),"gb2312")以保證拿到gb2312碼的字串，這樣就不會出現由於調用資料庫 操作而導致的字元集問題。