首先實現了一個StringConvert bean（GBtoISO()和ISOtoGB()兩個方法），解決了與MySQL
數據庫交互的時候的部分中文亂碼問題：在JSP
程序中讀取MySQL的中文內容，用這兩個方法可以解決亂碼問題。
????
但是從JSP寫入到MySQL的中文內容都成了亂碼，并且再讀出來的時候也顯示為“？？”，在這里應該出現了編碼轉換過程中的字符信息丟失。郁悶的是，我
在命令行窗口中登陸到MySQL后，執行如“INSERT INTO customer
VALUES('字符',...)”這樣的語句時，寫入到數據表中的中文內容又是顯示正常的！！！數據庫使用的字符集是utf8。
??? ?
???? 碰壁多次，終于發現一條解決問題的路徑：查看MySQL手冊的時候，看到一條這樣的語句：To
allow multiple character sets to be sent from the client, the "UTF-8"
encoding should be used, either by configuring "utf8" as the default
server 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編碼，在它與數據庫交互的時候就需要進行顯式的轉碼才能正確處理中文字符。