JAVA的中文編碼問題

JAVA的中文問題比較突出，主要表現在控制皮膚輸出，JSP頁面輸出和資料庫訪問上。本文儘量避開字型問題，而只談編碼。通過本文，你可以瞭解JAVA中文問題的由來，問題的解決方法，其中提了一下用JDBC訪問資料庫的方法。

二、問題描述：
1）在中文W2000中文視窗編譯和執行，用的是國際版的JDK，連線的是中文W2000下的Cp936編碼的SQL SERVER資料庫：

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）出現有亂碼（也就是？）。由於只出現？而沒出現小方框，說明只是編碼有問題，而不是字型問題。

在 編碼中，如果從一種字符集轉換到別一種字符集，比較典型的是從GB2312轉換到ISO8859_1（即ASCII），那麼很多漢字（半個漢字）是無法映 射到西文字元中去的，在這種情形下，系統就把這些字元用？代替。同樣，也存在小字符集無法到大字符集的情況，具體原因這裡就不詳談了。

2）出現了中文環境編譯，中文環境執行時漢字顯示有正確也有不正確的地方，同樣，在西文環境下編譯，在中文環境下執行時也出現類似情況。這是由於自動（預設）或手工（也就new String(bytes

[,encode])和bytes getBytes([encode])）轉碼的結果。

2.1） 在JAVA原始檔-->JAVAC-->Class-->Java-->getBytes()-->new String()-->顯示的過程中，每一步都有編碼的轉換過程，這個過程總是存在的，只是有的時候用預設的引數進行。下面我們一步一步分析為什麼 出現上面的情形。

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();
}
}
}

為了方便起見，在每個轉換的後面加了操作序號，分別為1,2,...,13。

2.3） 需要說明的是，JAVAC是以系統預設編碼讀入原始檔，然後按UNICODE進行編碼的。在JAVA執行的時候，JAVA也是採用UNICODE編碼的， 並且預設輸入和輸出的都是作業系統的預設編碼，也就是說在newString(bytes[,encode])中，系統認為輸入的是編碼為encode的 位元組流，換句話說，如果按encode來翻譯bytes才能得到正確的結果，這個結果最後要在JAVA中儲存，它還是要從這個encode轉換成 Unicode，也就是說有bytes-->encode字元-->Unicode字元的轉換；而在String.getBytes ([encode])中，系統要做一個Unicode字元-->encode字元-->bytes的轉換。

在這個例子中，除那個英文視窗編碼的時候除外，其實情形下預設編碼都是GBK（在本例中，我們暫且把GBK和GB2312等同看待）。

2.4） 由於在未指明在上面的兩個用程式碼實現的轉換中，如果未指定encode，系統將採用預設的編碼（這裡為GBK），我們認為上面的5,6,7和8,9,10 是一樣的，8和9、11和12也是一樣的，所以我們在討論中將只計論1,9,10,12,13。其中的2,3,4只是用於測試，不在我們的討論範圍之內。

2.5）下面我們來跟蹤程式中的“中”字的轉換歷程，我們先說在中文視窗下作的編譯和執行過程，注意在下面的字母下標中，我有意識地使用了一些數字，以表示相同，相異還是相關2.5.1)我們先以上面的13個程式碼段中的的程式碼9為例：

步驟 內容 地點 說明
01： C1 HelloWorld.java C1泛指一個GBK字元
02： U1 JAVAC讀取 U1泛指一個Unicode字元
03： C1 getBytes()第一步 JAVA先和作業系統交流
04： B1,B2 getBytes()第二步 然後返回位元組陣列
05： C1 new String()第一步 JAVA先和作業系統交流
06： U1 new String()第二步 然後返回字元
07： C1 println(String) 能顯示“中”字，內容和原來的相同

2.5.2）然後再以程式碼段10為例，我們注意到只是：

步驟 內容 地點 說明
01： C1 HelloWorld.java C1泛指一個GBK字元
02： U1 JAVAC讀取 U1泛指一個Unicode字元
03： C1 getBytes()第一步 JAVA先和作業系統交流
04： B1,B2 getBytes()第二步 然後返回位元組陣列
05： C3,C4 new String()第一步 JAVA先和作業系統交流，這時解析錯誤
06： U5,U6 new String()第二步 然後返回字元
07： C3,C4 println(String) 由於中字給分成了兩半，在ISO8859_1中剛好也沒有字元

能對映上，所以顯示為“??”。在上面的示例中，“中文”兩個字就顯示為“？？？？”

2.5.3）在完全中文模式下的其它情形類似，我就不多說了

2.6）我們接著看為什麼在西文DOS視窗下編譯出來的類在中文視窗下也出現類似情形，特別是為什麼居然有的情形下還能正確顯示漢字。

2.6.1）我們還是先以程式碼段9為例：

步驟 內容 地點 說明
01： C1C2 HelloWorld.java C1C2分別泛指一個ISO8859_1字元，“中”字被拆開
02： U3U4 JAVAC讀取 U1U2泛指一個Unicode字元
03： C5C6 getBytes()第一步 JAVA先和作業系統交流，這時解析錯誤
04： B5B6B7B8 getBytes()第二步 然後返回位元組陣列
05： C5C6 new String()第一步 JAVA先和作業系統交流
06： U3U4 new String()第二步 然後返回字元
07： C5C6 println(String) 雖然同是兩個字元，但已不是最初的“兩個ISO8859_1字元”，而是“兩個BGK字元”，“中”顯示成了“？？”，而“中文”就顯示成了“？？？？” 。

2.6.2）下面我們以程式碼段12為例，因為它能正確顯示漢字

步驟 內容 地點 說明

01： C1C2 HelloWorld.java C1C2分別泛指一個ISO8859_1字元，“中”字被拆開
02： U3U4 JAVAC讀取 U1U2泛指一個Unicode字元
03： C1C2 getBytes()第一步 JAVA先和作業系統交流（注意還是正確的哦！）
04： B5B6 getBytes()第二步 然後返回位元組陣列（這是很關鍵的一步！）
05： C12 new String()第一步 JAVA先和作業系統交流（這是更關鍵的一步，JAVA已經知道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)
的時候會出現亂碼了呢？

其 實問題就出現在編寫JDBC的的也考慮了編碼問題，它從資料庫讀取資料後，可能自作主張做了一個從GB2312（預設編碼）到Unicode的轉換，我的 這個WebLogic For SQL Server的JDBC Driver就是這樣的，當我讀字串的時候，發出讀到的不是正確的漢字，可恨的是我卻可以直接寫漢字字串，這讓人多少有點難以接受！也就是說，我們不得不 在讀或寫的時候進行轉碼，儘管這個轉碼有的時候不是那麼明顯，這是因為我們使用了預設的編碼進行轉碼。JDBC Driver所做的操作，我們只有進入到原始碼內部才能清楚，不是嗎？