JDBC中的中文處理

JDBC中的中文處理

我們在做一個JAVA的應用，不可避免地要處理中文。經過艱苦的探索，目前有一些進展，找到了一些解決方法，但仍然面臨著無法解決的問題。在此作一整理，希望對大家有所幫助，同時請各位高手幫忙考慮我們的問題。

背景：
JDK 1.15
VCafe 2.0
JPadPro
SERVER：
NT IIS
Sybase System 10
JDBC: Jconnect
CLIENT：
Browser: Netscape 4.04 + Patch
PWin95 & Pwin98 Beta3

CLASS文件存放在 SERVER，由BROWSER 運行APPLET，APPLET只起調入FRAME類主程序的作用。界面包括Text field, Text Area,List, Choice 等。

一，取中文
用JDBC執行SELECT語句從SERVER取數據（中文）后，將數據用APPEND方法加到TEXT AREA（TA），不能正確顯示。但加到LIST中時，則大部分漢字可正確顯示。

處理：將數據按“ISO-8859-1”格式轉為字節數組，再按系統缺省編碼格式（default character encoding）轉為STRING，即可在TA和LIST中正確顯示。

程序段如下：

dbstr2 = results.getString(1);
//*********************************************************************
// After read result from Database server, Convert the result string.

dbbyte1 = dbstr2.getBytes("iso-8859-1");
dbstr1 = new String(dbbyte1);
//*********************************************************************

二，寫中文到DB
處理方式與以上相逆，先將SQL語句按DEFAULT CHARACTER ENCODING轉為字節數組，再按ISO-8859-1轉為STRING，然后送執行，則中文信息可正確寫入DB。

sqlstmt = tf_input.getText();

//*****************************************************************************
// Before send statement to Database server, Convert sql statement.

dbbyte1 = sqlstmt.getBytes();
sqlstmt = new String(dbbyte1,"iso-8859-1");
//*****************************************************************************

_stmt = _con.createStatement();
_stmt.executeUpdate(sqlstmt);
。。。。。。

問題：
以上方法當本地客戶機上存在CLASSPATH指向JDK的CLASSES。ZIP時（稱為A情況），可正確運行。
但如果客戶機只有Browser，沒有JDK和CLASSPATH時（稱為B情況），則漢字無法正確轉換。

我們的分析：
1,
經過測試，在A情況下，程序運行時系統的default character
encoding = "GBK" or "GB2312".
在B情況下，程序啟動時，Browser 的JAVA CONSOLE中出現如下信息：
can´t find resource for
sun.awt.windows.awtLocalization_zh_CN

然后系統的
default characterencoding = "8859-1".

2,
如果在轉換字符串時不采用default character encoding，而是直接采用“GBK”或“GB2312”，則在A情況下仍然可正常，在B情況下，系統出現錯誤：UnsupportedEncodingException。

3，
在本地客戶機上，我把JDK的CLASSES。ZIP解壓后，放在另一個目錄中，CLASSPATH只包含該目錄。然后逐步刪除目錄中的CLASS文件，一邊運行測試程序，最后發現在一千多個CLASS文件中，只有一個是不可缺少的，該文件是：
sun.io.CharToByteDoubleByte.class
我將該文件拷到SERVER端和其它的類放在一起，并在程序的開頭IMPORT它，仍然在B情況下無法正常。

4，
在A情況下，如果在CLASSPTH中去掉
sun.io.CharToByteDoubleByte.class，則程序運行時，測得default character encoding為“8859-1”，否則為GBK 或GB2312。

5，
分析BROWSER程序NETSCAPE目錄下的文件
/program/java/classes/java40.jar, 發現其中沒有包括
sun.io.CharToByteDoubleByte.class,
不知這是需要升級，還是有其它方法可以解決？ 盼望各位高手指導！Email: sailor@mailserv.stu.edu.cn

現在我們取得的一點小小進展，在轉換字符串時不采用default character
encoding，而是直接采用“GBK”或“GB2312”，在情況A和B底下，從DB取數據
都沒有問題，但是寫中文到DB也采用“GBK”或“GB2312”時，情況B仍是出錯的。


當我們使用老外公司開發的jdbc第四類driver獲取數據庫中文信息時，常會出現亂碼現象
，如????D.
解決辦法1：
使用interface ResultSet的方法getBytes()得到一byte[]，然后由此byte[]數組產生一
新的
String,可獲得正確的漢字，但此方法有一定的局限性，在某些driver上可以實現，如
weblogic公司
開發的fastforward產品。另此種方法不規范，根據sun jdbc的標準varchar和var推薦用
getString()
方法來獲取。
解決辦法2:
使用interface ResultSet的方法getString(),這時我們得到的String一定是亂碼，如何
解決，
String temp = result.getString (s);
if (temp != null) {
byte[] b = temp.getBytes ("8859_1");
temp = new String (b);
此時的temp一定是正確的中文，，，，，，此種方法我在sybase公司開發的jconnect4上實驗成功，在fastforward上也成功。

原文轉自：http://www.kjueaiud.com