漢字問題深入談

liquidchen

浏览: 11314 次
性别:
来自: 台北

最近访客更多访客>>

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (7)

社区版块

存档分类

JDBC SQL Server Weblogic SQL DOS

轉載自 http://www.7880.com/Info/Article-538316e0.html
漢字問題深入談

一、主題：關於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編碼的，並且默認輸入和輸出的都是操作系統的默認編碼，也就是說在new String(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所做的操作，我們只有進入到源代碼內部才能清楚，不是嗎？

分享到：