_sql = new String (_sql.getBytes("ISO-8859-1"),"GB2312");
然后插入。

解决方案 »

  1.   

    一,取中文
    用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: [email protected]
    ※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: DHCP159_158.STU] 
    发信人: barebell (小心), 信区: Java
    标 题: Re: ● ● JDBC中文处理:方法与问题
    发信站: BBS 水木清华站 (Tue May 19 22:38:19 1998) WWW-POST现在我们取得的一点小小进展,在转换字符串时不采用default character 
    encoding,而是直接采用“GBK”或“GB2312”,在情况A和B底下,从DB取数据
    都没有问题,但是写中文到DB也采用“GBK”或“GB2312”时,情况B仍是出错的。发信人: mah (chip), 信区: Java
    标 题: 通过jdbc driver获取数据库中文信息揭密
    发信站: BBS 水木清华站 (Tue Aug 11 20:42:16 1998) WWW-POST当我们使用老外公司开发的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
    上也成功