我的做法,当从数据库中取信息是,在*.jsp上加
<%@ page contentType="text/html;charset=gb2312" %>
就ok了。当要取得页面输入时,如:
String userId      = request.getParameter("userId");
String password    = request.getParameter("password");这时的要做getBytes("ISO8859_1")方法。具体,我做一个bean如ConvertToCh.class  ,  把getBytes("ISO8859_1")封起来,再做个接口,
每次实现接口即可,如:
userId =ConvertToCh.getCh(userId);

解决方案 »

  1.   

    每种编码应该都有特征,(数据库是遗留的,所以不考虑开销问题,只要解决),现在只要求区分8859_1,GBK
      

  2.   

    借花千佛哦
    一、主题:关于JAVA的中文问题 
        JAVA的中文问题比较突出,主要表现在控制面板输出,JSP页面输出和数据库访问上。本文尽量避开字体问题,而只谈编码。通过本文,你可以了解JAVA中文问题的由来,问题的解决方法,其中提了一下用JDBC访问数据库的方法。 二、问题描述: 
    1)在中文W2000中文窗口编译和运行,用的是国际版的JDK,连接的是中文W2000下的Cp936编码的SQL SERVER数据库: J:\exercise\demo\encode\HelloWorld>make 
       Created by XCompiler. PhiloSoft All Rights Reserved. 
       Wed May 30 02:54:45 CST 2001 J:\exercise\demo\encode\HelloWorld>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:\exercise\demo\encode\HelloWorld>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("中文".getBytes());//2 
    System.out.println("中文".getBytes("GB2312"));//3 
    System.out.println("中文".getBytes("ISO8859_1"));//4 System.out.println(new String("中文".getBytes()));//5 
    System.out.println(new String("中文".getBytes(),"GB2312"));//6 
    System.out.println(new String("中文".getBytes(),"ISO8859_1"));//7 System.out.println(new String("中文".getBytes("GB2312")));//8 
    System.out.println(new String("中文".getBytes("GB2312"),"GB2312"));//9 
    System.out.println(new  String("中文".getBytes("GB2312"),"ISO8859_1"));//10 System.out.println(new String("中文".getBytes("ISO8859_1")));//11 
    System.out.println(new  String("中文".getBytes("ISO8859_1"),"GB2312"));//12 
    System.out.println(new  String("中文".getBytes("ISO8859_1"),"ISO8859_1"));//13 

    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所做的操作,我们只有进入到源代码内部才能清楚,不是吗? 
     
    如何在JSP中处理中文 
    yippit 原创 (参与分:16071,专家分:200)   发表:2002-9-18 下午4:45   版本:1.0   阅读:937次 
     如何在JSP中处理中文在一个Web应用中经常需要向服务器传递一些参数,一般通过form向服务器发送一个POST请求。在参数中有可能包含中文信息,如用户信息登记、购物定单中的地址信息等等。参数字符串一般用本地字符集进行编码,如中文采用GB2312或GBK字符集,英文或西欧文字采用ISO8859_1字符集,但在Java程序中一律采用Unicode处理字符串,这就需要有一个编码转换的过程。不幸的是,现有的大部分Java应用服务器都是在英语国家开发出来的,由于缺乏大字符集(中文、日文、韩文等)的应用环境,这些应用服务器在处理HTTP请求参数时都存在一些中文处理的问题,也是最为困扰JSP和Servlet开发者的问题。 产生这一问题的根本原因是在HTTP请求中缺乏足够的信息来指明客户端所使用的字符集。在一个JSP页面中我们可以通过下面的伪指令来指明输出页面所使用的字符集: JSP引擎会将上面的伪指令转换为HTTP应答的
      

  3.   

    存两种字符集?! 为什么不用 UTF-8 呢?
      

  4.   

    callwa(蜜蜂宝宝) 写的不错,但未解决问题情人节快乐
    请继续
      

  5.   

    public String getStr1(String str)
      {
         try
            {
              String temp_p=str;
              byte[] temp_t=temp_p.getBytes("GBK");
              String temp=new String(temp_t,"ISO8859_1");
              return temp;
             }
          catch(Exception e)
             { return "null";}
      }
    在数据库取出的文字 用这个转换一下