我的亂碼之路——JSP與MySQL互動的中文亂碼解決方案及總結

js|mysql|互動|解決|中文|中文亂碼
     首先實現了一個StringConvert bean（GBtoISO()和ISOtoGB()兩個方法），解決了與MySQL資料庫互動的時候的部分中文亂碼問題：在JSP程式中讀取MySQL的中文內容，用這兩個方法可以解決亂碼問題。

    但是從JSP寫入到MySQL的中文內容都成了亂碼，並且再讀出來的時候也顯示為“？？”，在這裡應該出現了編碼轉換過程中的字元資訊丟失。鬱悶的是，我在命令列視窗中登陸到MySQL後，執行如“INSERT INTO customerVALUES('字元',...)”這樣的語句時，寫入到資料表中的中文內容又是顯示正常的！！！資料庫使用的字元集是utf8。

     

     碰壁多次，終於發現一條解決問題的路徑：查看MySQL手冊的時候，看到一條這樣的語句：Toallow multiple character sets to be sent from the client, the "UTF-8"encoding should be used, either by configuring "utf8" as the defaultserver character set, or by configuring the JDBC driver to use "UTF-8"through the characterEncoding property.

     

     此外，在查閱《MySQL權威指南》時，發現在查詢語句中可以使用這樣的文法將字串轉換到一個給定的字元集：_charset str。

     其中charset必須是伺服器支援的某個字元集。在本例中，shopdb資料庫使用的預設字元集是utf8，於是開始測試：

     先輸入INSERT INTO　publish Values('8',_gb2312 '高等教育出版社')  寫入後中文變成“？？”

     再試INSERT INTO　publish Values('8',_gbk '高等教育出版社') 結果同上

     INSERT INTO　publish Values('8',_utf8 '高等教育出版社') 這下更乾脆，什麼都沒有！！

     

     　　快瘋了!!沒辦法，用show character set;命令查看MySQL支援的字元集，心想我都試一遍總有一個能成功吧。瀏覽了一下，發現沒有幾個熟悉的字元集，就只剩下一個latin1(ISO-8859-1)比較常見了，不會是它吧，一試之下果然便是。

     INSERT INTO　publish Values('8',_latin1 '高等教育出版社') 輸入中文能夠正確顯示。

     

     　　這下總算找到方法了，把Tomcat下配置的資料庫連接池的url改為＂...characterEncoding=UTF-8＂，然後把寫入資料庫的中文內容用

     String s2 = new String(s1.getBytes("gb2312"),"ISO-8859-1")進行轉碼，其中s1為中文字串．然後再寫入到資料庫一切顯示正常。

     

     　　為解決這個問題查看了n多資料，現作一個總結：由於字元集和字元編碼方式的不同，在OS以及程式之間傳遞資料（尤其是multiple character sets中的資料）時便會產生亂碼以及字元資訊的丟失．解決這個問題的關鍵便是瞭解資料輸出端和接收端使用的字元集和字元編碼方式，如果這兩種編碼方式不同，便需要在資料出口或入口處進行 轉碼。一般的說，在編寫代碼,編譯，以及運行期間都會字元資料的傳遞，因此需要特別小心。

     　在編寫代碼的時候，你可能會使用某種開發工具，例如我正在使用的Eclipse．或許在寫的時候一切正常，可是一旦儲存後再次開啟文檔，所有的中文字元都變成了亂碼。這是因為在編寫的時候，這些字元資料都在記憶體的某個stream中，ok，這沒問題，可是儲存的時候這個stream中的資料會被寫入到硬碟，使用的就是你的開發工具預設的編碼方式，如果很不幸你的開發工具預設編碼方式是ISO-8859-1，中文字元資訊就不能正確地儲存。Eclipse中可以這樣查看並修改預設字元編碼方式：Project->Properties->info，這裡有＂default     encoding for text file＂。如果設定為GBK，那麼編寫代碼並儲存這關就過了。

     　對於JSP程式而言，編寫完代碼後就交給Container，首先它們會被轉成.java檔案，然後編譯成.class才能提交給伺服器執行．這個過程也存在字元編碼問題．java編譯器(javac)使用作業系統的語言環境作為預設的字元編碼方式，JRE(Java Runtime Environment)也是這樣。只有當編譯和運行環境的字元編碼方式與儲存源檔案的編碼方式相同時，中文字元才能正確地顯示。否則就需要在運行時進行轉碼，使它們使用相容的編碼。這裡的設定可以分為幾個層次：作業系統層支援的語言，這是最重要的，因為它會影響ＪＶＭ的預設字元編碼方式，同時對字元的顯示，如字型等有直接影響；J2EE伺服器層，大多數伺服器都可以對字元編碼進行自訂的配置，例如Tomcat就可以通過web.xml中設定javaEncoding參數設定字元編碼，預設是UTF-8．

     IE也可以設定成總是使用UTF-8編碼來發送請求．應用程式層，每個配置在伺服器下的程式都可以設定自己的編碼方式，這個我目前還沒有用到，以後再學習。

     　運行時的轉碼，運行時期，應用程式很可能需要與外部系統進行互動，例如對資料庫進行讀寫，對外部檔案進行讀寫．在這些情況下，應用程式免不了要和外部系統進行資料交換。那麼對於中文字元， 資料出入口的編碼方式就顯得特別重要了。一般外部系統都有自己的字元編碼方式，我的例子中配置的MySQL就是使用的UTF-8編碼。JSP頁面通過設定＂charset=gb2312＂,

    使用gb2312編碼，在它與資料庫互動的時候就需要進行顯式的轉碼才能正確處理中文字元。