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上也成功。
来源：xiameng
文章来源于领测软件测试网 https://www.ltesting.net/
