一聚教程网:一个值得你收藏的教程网站

最新下载

热门教程

Java各种中文乱码问题及解决方案

时间:2017-02-20 编辑:简简单单 来源:一聚教程网

问题的根源

Java的内核和class文件是基于unicode的,这使Java程序具有良好的跨平台性,但也带来了一些中文乱码问题的麻烦。原因主要有两方面,Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。

  首先Java(包括JSP)源文件中很可能包含有中文,而Java和JSP源文件的保存方式是基于字节流的,如果Java和JSP编译成 class文件过程中,使用的编码方式与源文件的编码不一致,就会出现乱码。基于这种乱码,建议在Java文件中尽量不要写中文(注释部分不参与编译,写中文没关系),如果必须写的话,尽量手动带参数-encoding GBK或-encoding gb2312编译;对于JSP,在文件头加上或基本上就能解决这类乱码问题。

问题的种类

即Java程序与其他存储媒介交互时产生的乱码。很多存储媒介,如数据库,文件,流等的存储方式都是基于字节流的,Java程序与这些媒介交互时就会发生字符(char)与字节(byte)之间的转换,具体情况如下:

(1)从页面form提交数据到java程序 byte->char

(2)从java程序到页面显示 char-->byte

(3)从数据库到java程序 byte-->char

(4)从java程序到数据库 char-->byte

(5)从文件到java程序 byte->char

(6)从java程序到文件 char->byte

如果在以上转换过程中使用的编码方式与字节原有的编码不一致,很可能就会出现乱码。

基础――了解字符集

(1)ASCII

    ASCII码是7位编码,编码范围是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯数字和标点符号等字符。其中0x00-0x20和0x7F共33个控制字符。

    只支持ASCII码的系统会忽略每个字节的最高位,只认为低7位是有效位。HZ字符编码就是早期为了在只支持7位ASCII系统中传输中文而设计的编码。早期很多邮件系统也只支持ASCII编码,为了传输中文邮件必须使用BASE64或者其他编码方式。

(2)GB2312

GB2312 是基于区位码设计的,区位码把编码表分为94个区,每个区对应94个位,每个字符的区号和位号组合起来就是该汉字的区位码。区位码一般用10进制数来表示,如1601就表示16区1位,对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。

区位码中01-09区是符号、数字区,16-87区是汉字区,10-15和88-94是未定义的空白区。它将收录的汉字分成两级:第一级是常用汉字计 3755个,置于16-55区,按汉语拼音字母/笔形顺序排列;第二级汉字是次常用汉字计3008个,置于56-87区,按部首/笔画顺序排列。一级汉字 是按照拼音排序的,这个就可以得到某个拼音在一级汉字区位中的范围,很多根据汉字可以得到拼音的程序就是根据这个原理编写的。

GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符,未收录繁体中文汉字和一些生僻字。可以用繁体汉字测试某些系统是不是只支持GB2312编码。

区位码更应该认为是字符集的定义,定义了所收录的字符和字符位置,而GB2312及EUC-CN是实际计算机环境中支持这种字符集的编码。HZ和ISO-2022-CN是对应区位码字符集的另外两种编码,都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像 Unicode和UTF-8。

(3)GBK

GBK 编码是GB2312编码的超集,向下完全兼容GB2312,同时GBK收录了Unicode基本多文种平面中的所有CJK汉字。同 GB2312一样,GBK也支持希腊字母、日文假名字母、俄语字母等字符,但不支持韩语中的表音字符(非汉字字符)。GBK还收录了GB2312不包含的汉字部首符号、竖排标点符号等字符。

GBK编码是中国大陆制订的、等同于UCS的新的中文编码扩展国家标准。GBK工作小组于1995年10月,同年12月完成GBK规范。该编码标准兼容GB2312,共收录汉字21003个、符号883个,并提供1894个造字码位,简、繁体字融于一库。

(4)GB18030

 GB18030编码向下兼容GBK和GB2312,兼容的含义是不仅字符兼容,而且相同字符的编码也相同。GB18030收录了所有Unicode3.1中的字符,包括中国少数民族字符,GBK不支持的韩文字符等等,也可以说是世界大多民族的文字符号都被收录在内。

  GBK和GB2312都是双字节等宽编码,如果算上和ASCII兼容所支持的单字节,也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码,有单字节、双字节和四字节三种方式。

GB18030 的单字节编码范围是0x00-0x7F,完全等同与ASCII;双字节编码的范围和GBK相同,高字节是0x81-0xFE,低字节的编码范围是 0x40-0x7E和0x80-FE;四字节编码中第一、三字节的编码范围是0x81-0xFE,二、四字节是0x30-0x39。

 Windows 中CP936代码页使用0x80来表示欧元符号,而在GB18030编码中没有使用0x80编码位,用其他位置来表示欧元符号。这可以理解为是 GB18030向下兼容性上的一点小问题;也可以理解为0x80是CP936对GBK的扩展,而GB18030只是和GBK兼容良好。

(5)unicode

  每一种语言的不同的编码页,增加了那些需要支持不同语言的软件的复杂度。因而人们制定了一个世界标准,叫做unicode。unicode为每个字符提供 了唯一的特定数值,不论在什么平台上、不论在什么软件中,也不论什么语言。也就是说,它世界上使用的所有字符都列出来,并给每一个字符一个唯一特定数值。
   Unicode的最初目标,是用1个16位的编码来为超过65000字符提供映射。但这还不够,它不能覆盖全部历史上的文字,也不能解决传输的问题,尤其在那些基于网络的应用中。已有的软件必须做大量的工作来程序16位的数据。
  因此,Unicode用一些基本的保留字符制定了三套编码方式。它们分别是UTF-8,UTF-16和UTF-32。正如名字所示,在UTF-8中,字符是 以8位序列来编码的,用一个或几个字节来表示一个字符。这种方式的最大好处,是UTF-8保留了ASCII字符的编码做为它的一部分,例如,在UTF-8 和ASCII中,’A’的编码都是0x41.

UTF-16和UTF-32分别是Unicode的16位和32位编码方式。考虑到最初的目的,通常说的Unicode就是指UTF-16。在讨论Unicode时,搞清楚哪种编码方式非常重要。

(6)UTF-8

    Unicode Transformation Format-8bit,允许含BOM,但通常不含BOM。是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24位(三个字节)来编码。UTF-8包含全世界所有国家需要用到的字符,是国际编码,通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显 示。如,如果是UTF8编码,则在外国人的英文IE上也能显示中文,他们无需下载IE的中文语言支持包。

   GBK的文字编码是用双字节来表示的,即不论中、英文字符均使用双字节来表示,为了区分中文,将其最高位都设定成1。GBK包含全部中文字符,是国家编码,通用性比UTF8差,不过UTF8占用的数据库比GBD大。

   GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换:

    GBK、GB2312--Unicode--UTF8

    UTF8--Unicode--GBK、GB2312

对于一个网站、论坛来说,如果英文字符较多,则建议使用UTF-8节省空间。不过现在很多论坛的插件一般只支持GBK。

解决方法

(1)JSP页面显示乱码

这种乱码的原因是应为没有在页面里指定使用的字符集编码,解决方法:只要在页面开始地方用下面代码指定字符集编码即可

(2)表单提交中文时出现乱码

JSP获取页面参数时一般采用系统默认的编码方式,如果页面参数的编码类型和系统默认的编码类型不一致,很可能就会出现乱码。解决这类乱码问题的基本方法是在页面获取参数之前,强制指定request获取参数的编码方式:request.setCharacterEncoding("GBK")或 request.setCharacterEncoding("gb2312")。

当然,使用下列方式亦可:、

String name = request.getParameter(“name”);

name = new String(name.getBytes(“iso-8859-1”),”gb2312”);

如果在JSP将变量输出到页面时出现了乱码,可以通过设置

response.setContentType("text/html;charset=GBK")

response.setContentType("text/html;charset=gb2312")解决。

(3)数据库连接出现乱码

这种乱码会使你插入数据库的中文变成乱码,或者读出显示时也是乱码,解决方法如下:

  在数据库连接字符串中加入编码字符集

  String Url="jdbc:MySQL://localhost/database? user=root&password=root&useUnicode=true&characterEncoding=GB2312"; 

(4)数据库的显示乱码

第一步:写一个转换字符串的公共类

  

  

public class StringConvert {

    public static String Convert(String s)

    {

       String gb;

       try{

       if(s.equals("") || s == null){

           return "";

       }

       else{

           s   = s.trim();

       gb = new String(s.getBytes("ISO-8859-1"),"GBK");

       return gb;

           }

       }

       catch(Exception e){

       System.err.print("编码转换错误:"+e.getMessage());

       return "";

       }

    }

}

第二步:解决MySQL的中文问题

方法1、

打开MySQL客户端(MySQL command Line Client),设置以下三项:

  

  

        set character_set_client=gbk;

  

          set character_set_results=gbk;

  

          set character_set_connection=gbk;

  

 之后,再将MySQL安装目录下的my.ini文件中的:default-character-set的值设为gbk(注意有两处需要修改)。

 注1:这种方法有个缺陷就是,修改后,在新建表中的乱码消失了,但是在原先的表中却又出现了乱码;解的办法是,先将原先的表中的数据导出,修改后,再重建表,最后再将数据导入。

 注2:有关character_set_client等等的作用,

 可以参见中文手册:http://dev.mysql.com/doc/refman/5.1/zh/charset.html

方法2、

 在安装MySQL的时候稍微留心一下编码的设置,将其设置为GBK一切OK,这样就省去了以后的麻烦。

热门栏目