我们在做一个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上也成功。