一、主題：關(guān)于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)小方框，說明只是編碼有問題，而不是字體問題。 在編碼中，如果從一種字符集轉(zhuǎn)換到別一種字符集，比較典型的是從GB2312轉(zhuǎn)換到ISO8859_1（即ASCII），那么很多漢字（半個漢字）是無法映射到西文字符中去的，在這種情形下，系統(tǒng)就把這些字符用？代替。同樣，也存在小字符集無法到大字符集的情況，具體原因這里就不詳談了。?
2）出現(xiàn)了中文環(huán)境編譯，中文環(huán)境運行時漢字顯示有正確也有不正確的地方，同樣，在西文環(huán)境下編譯，在中文環(huán)境下運行時也出現(xiàn)類似情況。這是由于自動（默認(rèn)）或手工（也就new String(bytes[,encode])和bytes getBytes([encode])）轉(zhuǎn)碼的結(jié)果。?
2.1）在JAVA源文件-->JAVAC-->Class-->Java-->getBytes()-->new String()-->顯示的過程中，每一步都有編碼的轉(zhuǎn)換過程，這個過程總是存在的，只是有的時候用默認(rèn)的參數(shù)進行。下面我們一步一步分析為什么出現(xiàn)上面的情形。?
2.2）這里是源代碼：?
HelloWorld.java:?
------------------------?
public class HelloWorld?
{?
??? public static void main(String[] argv)
??? {?
??????? try
??????? {?
??????????? System.out.println("1:"+"中文");
??????????? System.out.println("2:"+"中文".getBytes());
??????????? System.out.println("3:"+"中文".getBytes("GB2312"));?
??????????? System.out.println("4:"+"中文".getBytes("ISO8859_1"));
??????????? System.out.println("5:"+new String("中文".getBytes()));//5?
??????????? System.out.println("6:"+new String("中文".getBytes(),"GB2312"));?
??????????? System.out.println("7:"+new String("中文".getBytes(),"ISO8859_1"));
??????????? System.out.println("8:"+new String("中文".getBytes("GB2312")));//8?
??????????? System.out.println("9:"+new String("中文".getBytes("GB2312"),"GB2312"));
??????????? System.out.println("10:"+new String("中文".getBytes("GB2312"),"ISO8859_1"));
??????????? System.out.println("11:"+new String("中文".getBytes("ISO8859_1")));//11?
??????????? System.out.println("12:"+new String("中文".getBytes("ISO8859_1"),"GB2312"));
??????????? System.out.println("13:"+new String("中文".getBytes("ISO8859_1"),"ISO8859_1"));
??????? }?
??????? catch(Exception e)
??????? {?
??????????? e.printStackTrace();?
??????? }?
? }?
}?
為了方便起見，在每個轉(zhuǎn)換的后面加了操作序號，分別為1,2,...,13。?
2.3）需要說明的是，JAVAC是以系統(tǒng)默認(rèn)編碼讀入源文件，然后按UNICODE進行編碼的。在JAVA運行的時候，JAVA也是采用UNICODE編碼的，并且默認(rèn)輸入和輸出的都是操作系統(tǒng)的默認(rèn)編碼，也就是說在new String(bytes[,encode])中，系統(tǒng)認(rèn)為輸入的是編碼為encode的字節(jié)流，換句話說，如果按encode來翻譯bytes才能得到正確的結(jié)果，這個結(jié)果最后要在JAVA中保存，它還是要從這個encode轉(zhuǎn)換成Unicode，也就是說有bytes-->encode字符-->Unicode字符的轉(zhuǎn)換；而在String.getBytes([encode])中，系統(tǒng)要做一個Unicode字符-->encode字符-->bytes的轉(zhuǎn)換。?
在這個例子中，除那個英文窗口編碼的時候除外，其實情形下默認(rèn)編碼都是GBK（在本例中，我們暫且把GBK和GB2312等同看待）。?
2.4）由于在未指明在上面的兩個用代碼實現(xiàn)的轉(zhuǎn)換中，如果未指定encode，系統(tǒng)將采用默認(rèn)的編碼（這里為GBK），我們認(rèn)為上面的5,6,7和8,9,10是一樣的，8和9、11和12也是一樣的，所以我們在討論中將只討論1,9,10,12,13。其中的2,3,4只是用于測試，不在我們的討論范圍之內(nèi)。?
2.5）下面我們來跟蹤程序中的“中”字的轉(zhuǎn)換歷程，我們先說在中文窗口下作的編譯和運行過程，注意在下面的字母下標(biāo)中，我有意識地使用了一些數(shù)字，以表示相同，相異還是相關(guān)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ù)組（這是很關(guān)鍵的一步！）?
05： C12 new String()第一步 JAVA先和操作系統(tǒng)交流（這是更關(guān)鍵的一步，JAVA已經(jīng)知道B5B6要解析成一個漢字！）?
06： U7 new String()第二步 然后返回字符（真是一個項兩！U7包含了U3U4的信息）?
07： C12 println(String) 這就原來的“中”字，很委屈被JAVAC冤枉了一回，不過被程序員撥亂反正了一下！當(dāng)然，“中文”兩個字都能正確顯示了！?
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（默認(rèn)編碼）到Unicode的轉(zhuǎn)換，我的這個WebLogic For SQL Server的JDBC Driver就是這樣的，當(dāng)我讀字串的時候，發(fā)出讀到的不是正確的漢字，可恨的是我卻可以直接寫漢字字串，這讓人多少有點難以接受！?
也就是說，我們不得不在讀或?qū)懙臅r候進行轉(zhuǎn)碼，盡管這個轉(zhuǎn)碼有的時候不是那么明顯，這是因為我們使用了默認(rèn)的編碼進行轉(zhuǎn)碼。JDBC Driver所做的操作，我們只有進入到源代碼內(nèi)部才能清楚，大家認(rèn)為呢？