內(nèi)容: 漢字問題深入談 作者： 一、主題：關于JAVA的中文問題 JAVA的中文問題比較突出，主要表現(xiàn)在控制面板輸出，JSP頁面輸出和數(shù)據(jù)庫訪問上。本文盡量避開字體問題，而只談編碼。通過本文，你可以了解JAVA中文問題的由來，問題的解決方法，其中提了一下用JDBC訪問數(shù)據(jù)庫的方法。 二、問題描述： 1）在中文W2000中文窗口編譯和運行，用的是國際版的JDK，連接的是中文W2000下的Cp936編碼的SQL SERVER數(shù)據(jù)庫： J:exercisedemoencodeHelloWorld>make Created by XCompiler. PhiloSoft All Rights Reserved. Wed May 30 02:54:45 CST 2001 J:exercisedemoencodeHelloWorld>run Created by XRunner. PhiloSoft All Rights Reserved. Wed May 30 02:51:33 CST 2001 中文 [B@7bc8b569 [B@7b08b569 [B@7860b569 中文 中文 ???? 中文 中文 ???? ?? ?? ?? 2）如果在中文W2000的西文窗口（編碼為437）下編譯，用JAVA運行則由于無字體而無法正常顯示，如果象上面一樣在中文W2000的中文窗口運行，輸出為： J:exercisedemoencodeHelloWorld>run Created by XRunner. PhiloSoft All Rights Reserved. Wed May 30 02:51:33 CST 2001 ???? [B@7bc0b66a [B@7b04b66a [B@7818b66a ???? ???? ???? ???? ???? ???? 中文 中文 ???? 三）分析 1）出現(xiàn)有亂碼（也就是？）。由于只出現(xiàn)？而沒出現(xiàn)小方框，說明只是編碼有問題，而不是字體問題。 在編碼中，如果從一種字符集轉換到別一種字符集，比較典型的是從GB2312轉換到ISO8859_1（即ASCII），那么很多漢字（半個漢字）是無法映射到西文字符中去的，在這種情形下，系統(tǒng)就把這些字符用？代替。同樣，也存在小字符集無法到大字符集的情況，具體原因這里就不詳談了。 2）出現(xiàn)了中文環(huán)境編譯，中文環(huán)境運行時漢字顯示有正確也有不正確的地方，同樣，在西文環(huán)境下編譯，在中文環(huán)境下運行時也出現(xiàn)類似情況。這是由于自動（默認）或手工（也就new String(bytes[,encode])和bytes getBytes([encode])）轉碼的結果。 2.1）在JAVA源文件JAVACClassJavagetBytes()new String()顯示的過程中，每一步都有編碼的轉換過程，這個過程總是存在的，只是有的時候用默認的參數(shù)進行。下面我們一步一步分析為什么出現(xiàn)上面的情形。 2.2）這里是源代碼： HelloWorld.java: ------------------------ public class HelloWorld { public static void main(String[] argv){ try{ System.out.println('中文');//1 System.out.println('中文'.getBytes());//2 System.out.println('中文'.getBytes('GB2312'));//3 System.out.println('中文'.getBytes('ISO8859_1'));//4 System.out.println(new String('中文'.getBytes()));//5 System.out.println(new String('中文'.getBytes(),'GB2312'));//6 System.out.println(new String('中文'.getBytes(),'ISO8859_1'));//7 System.out.println(new String('中文'.getBytes('GB2312')));//8 System.out.println(new String('中文'.getBytes('GB2312'),'GB2312'));//9 System.out.println(new String('中文'.getBytes('GB2312'),'ISO8859_1'));//10 System.out.println(new String('中文'.getBytes('ISO8859_1')));//11 System.out.println(new String('中文'.getBytes('ISO8859_1'),'GB2312'));//12 System.out.println(new String('中文'.getBytes('ISO8859_1'),'ISO8859_1'));//13 } catch(Exception e){ e.printStackTrace(); } } } 為了方便起見，在每個轉換的后面加了操作序號，分別為1,2,...,13。 2.3）需要說明的是，JAVAC是以系統(tǒng)默認編碼讀入源文件，然后按UNICODE進行編碼的。在JAVA運行的時候，JAVA也是采用UNICODE編碼的，并且默認輸入和輸出的都是操作系統(tǒng)的默認編碼，也就是說在new String(bytes[,encode])中，系統(tǒng)認為輸入的是編碼為encode的字節(jié)流，換句話說，如果按encode來翻譯bytes才能得到正確的結果，這個結果最后要在JAVA中保存，它還是要從這個encode轉換成Unicode，也就是說有bytesencode字符Unicode字符的轉換；而在String.getBytes([encode])中，系統(tǒng)要做一個Unicode字符encode字符bytes的轉換。 在這個例子中，除那個英文窗口編碼的時候除外，其實情形下默認編碼都是GBK（在本例中，我們暫且把GBK和GB2312等同看待）。 2.4）由于在未指明在上面的兩個用代碼實現(xiàn)的轉換中，如果未指定encode，系統(tǒng)將采用默認的編碼（這里為GBK），我們認為上面的5,6,7和8,9,10是一樣的，8和9、11和12也是一樣的，所以我們在討論中將只討論1,9,10,12,13。其中的2,3,4只是用于測試，不在我們的討論范圍之內(nèi)。 2.5）下面我們來跟蹤程序中的“中字的轉換歷程，我們先說在中文窗口下作的編譯和運行過程，注意在下面的字母下標中，我有意識地使用了一些數(shù)字，以表示相同，相異還是相關2.5.1)我們先以上面的13個代碼段中的的代碼9為例： 步驟 內(nèi)容 地點 說明 01： C1 HelloWorld.java C1泛指一個GBK字符 02： U1 JAVAC讀取 U1泛指一個Unicode字符 03： C1 getBytes()第一步 JAVA先和操作系統(tǒng)交流 04： B1,B2 getBytes()第二步 然后返回字節(jié)數(shù)組 05： C1 new String()第一步 JAVA先和操作系統(tǒng)交流 06： U1 new String()第二步 然后返回字符 07： C1 println(String) 能顯示“中字，內(nèi)容和原來的相同 2.5.2）然后再以代碼段10為例，我們注意到只是： 步驟 內(nèi)容 地點 說明 01： C1 HelloWorld.java C1泛指一個GBK字符 02： U1 JAVAC讀取 U1泛指一個Unicode字符 03： C1 getBytes()第一步 JAVA先和操作系統(tǒng)交流 04： B1,B2 getBytes()第二步 然后返回字節(jié)數(shù)組 05： C3,C4 new String()第一步 JAVA先和操作系統(tǒng)交流，這時解析錯誤 06： U5,U6 new String()第二步 然后返回字符 07： C3,C4 println(String) 由于中字給分成了兩半，在ISO8859_1中剛好也沒有字符 能映射上，所以顯示為“??。在上面的示例中， “中文兩個字就顯示為“？？？？ 2.5.3）在完全中文模式下的其它情形類似，我就不多說了 2.6）我們接著看為什么在西文DOS窗口下編譯出來的類在中文窗口下也出現(xiàn)類似情形，特別是為什么居然有的情形下還能正確顯示漢字。 2.6.1）我們還是先以代碼段9為例： 步驟 內(nèi)容 地點 說明 01： C1C2 HelloWorld.java C1C2分別泛指一個ISO8859_1字符，“中字被拆開 02： U3U4 JAVAC讀取 U1U2泛指一個Unicode字符 03： C5C6 getBytes()第一步 JAVA先和操作系統(tǒng)交流，這時解析錯誤 04： B5B6B7B8 getBytes()第二步 然后返回字節(jié)數(shù)組 05： C5C6 new String()第一步 JAVA先和操作系統(tǒng)交流 06： U3U4 new String()第二步 然后返回字符 07： C5C6 println(String) 雖然同是兩個字符，但已不是最初的“兩個ISO8859_1字 符，而是“兩個BGK字符，“中顯示成了“？？ 而“中文就顯示成了“？？？？ 2.6.2）下面我們以代碼段12為例，因為它能正確顯示漢字 步驟 內(nèi)容 地點 說明 01： C1C2 HelloWorld.java C1C2分別泛指一個ISO8859_1字符，“中字被拆開 02： U3U4 JAVAC讀取 U1U2泛指一個Unicode字符03： C1C2 getBytes()第一步 JAVA先和操作系統(tǒng)交流（注意還是正確的哦！） 04： B5B6 getBytes()第二步 然后返回字節(jié)數(shù)組（這是很關鍵的一步！） 05： C12 new String()第一步 JAVA先和操作系統(tǒng)交流（這是更關鍵的一步，JAVA已經(jīng)知道B5B6要解析成一個漢字?。?06： U7 new String()第二步 然后返回字符（真是一個項兩！U7包含了U3U4的信息） 07： C12 println(String) 這就原來的“中字，很委屈被JAVAC冤枉了一回，不過被程序員撥亂反正了一下！當然，“中文兩個字都能正確顯示了！ 3）那為什么有的時候用JDBC的 new String(Recordset.getBytes(int)[,encode]) Recordset.getSting(int) Recordset.setBytes(String.getBytes([encode])) 和 Recordset.setString(String) 的時候會出現(xiàn)亂碼了呢？ 其實問題就出現(xiàn)在編寫JDBC的的也考慮了編碼問題，它從數(shù)據(jù)庫讀取數(shù)據(jù)后，可能自作主張做了一個從GB2312（默認編碼）到Unicode的轉換，我的這個WebLogic For SQL Server的JDBC Driver就是這樣的，當我讀字串的時候，發(fā)出讀到的不是正確的漢字，可恨的是我卻可以直接寫漢字字串，這讓人多少有點難以接受！ 也就是說，我們不得不在讀或寫的時候進行轉碼，盡管這個轉碼有的時候不是那么明顯，這是因為我們使用了默認的編碼進行轉碼。JDBC Driver所做的操作，我們只有進入到源代碼內(nèi)部才能清楚，不是嗎？ Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd