QU:關於字元集的問題，究竟什麼是“ISO 8859-1”，還有其它字元集嗎？有什麼區別？

今天看 java.util.Properties 的Api Doc，發現Properties的load()方法規定讀取的InputStream必須是ISO 8859-1字元集。

而當開啟NodePad，選擇儲存的時候，我也發現在2000以上的系統會出現“編碼”選項，裡面有“ANSI”，“Unicode”，“Unicode big endian”，“UTF-8”這幾種編碼。
能否向我介紹一下這些字元集編碼的知識，以及它們對java.io使用的影響。

_________________________________________________________________________________________

漢字問題深入談
 
一、主題：關於JAVA的中文問題
    JAVA的中文問題比較突出，主要表現在控制台輸出，JSP頁面輸出和資料庫訪問上。
本文盡量避開字型問題，而只談編碼。通過本文，你可以瞭解JAVA中文問題的由來，問題
的解決方案，其中提了一下用JDBC訪問資料庫的方法。
 
二、問題描述：
1）在中文W2000中文視窗編譯和運行，用的是國際版的JDK，串連的是中文W2000下的Cp936
編碼的SQL SERVER資料庫：
 
J:\exercise\demo\encode\HelloWorld>make
   Created by XCompiler. PhiloSoft All Rights Reserved.
   Wed May 30 02:54:45 CST 2001
 
J:\exercise\demo\encode\HelloWorld>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:\exercise\demo\encode\HelloWorld>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("中文".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是以系統預設編碼讀入源檔案，然後按UNICODE進行編碼的。在
JAVA啟動並執行時候，JAVA也是採用UNICODE編碼的，並且預設輸入和輸出的都是作業系統的默
認編碼，也就是說在new String(bytes[,encode])中，系統認為輸入的是編碼為encode的
位元組流，換句話說，如果按encode來翻譯bytes才能得到正確的結果，這個結果最後要在JA
VA中儲存，它還是要從這個encode轉換成Unicode，也就是說有bytes-->encode字元-->Uni
code字元的轉換；而在String.getBytes([encode])中，系統要做一個Unicode字元-->enco
de字元-->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所做的操作，我們只有進入到源代
碼內部才能清楚，不是嗎？