若想明白jsp开发过程中为什么会产生中文乱码,我们先来看看unicode编码。
Unicode (统一码)顾名思义是一个将世界上各种文字统一在一起的东东。由美国各大电脑厂商组成的Unicode策进会来推动。目的,推广一个世界通用的编码体制,惊世界上所有常用的文字都涵盖进去,从而减少个电脑商开发国外市场遇到的问题。
为了将成千上万的文字统统收集到一个共同的编码机制下,在兼顾经济的原则下,不管是东方还是西方文字,每个字在Unicode中一律以两个Bytes来表示,这样至少有2的16次方65536种不同的组合,足以应付目前绝大多数场合的需要。
基本上,计算机只是处理数字。它们指定一个数字,来储存字母或其他字符。在创造Unicode之前,有数百种指定这些数字的编码系统。没有一个编码可以包含足够的字符:例如,单单欧州共同体就需要好几种不同的编码来包括所有的语言。即使是单一种语言,例如英语,也没有哪一个编码可以适用于所有的字母,标点符号,和常用的技术符号。
这些编码系统也会互相冲突。也就是说,两种编码可能使用相同的数字代表两个不同的字符,或使用不同的数字代表相同的字符。任何一台特定的计算机(特别是服务器)都需要支持许多不同的编码,但是,不论什么时候数据通过不同的编码或平台之间,那些数据总会有损坏的危险。
Unicode给每个字符提供了一个唯一的数字,不论是什么平台,不论是什么程序,不论什么语言。Unicode标准已经被这些工业界的领导们所采用,例如:Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys和其它许多公司。最新的标准都需要Unicode,例如XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML等等,并且,Unicode是实现ISO/IEC 10646的正规方式。许多操作系统,所有最新的浏览器和许多其他产品都支持它。Unicode标准的出现和支持它工具的存在,是近来全球软件技术最重要的发展趋势。
将Unicode与客户服务器或多层应用程序和网站结合,比使用传统字符集节省费用。Unicode使单一软件产品或单一网站能够贯穿多个平台,语言和国家,而不需要重建。它可将数据传输到许多不同的系统,而无损坏。
在与Unicode相关的各技术文件中,经常会看到ISO 10646和UCS这两个名词。
ISO是位于瑞士的国际标准局的缩写。
UCS为ISO颁布的第10646号标准 Universal Character Set,就是世界通用字符集。
UCS通用字符集采用4个Bytes来编码,将世界上所有的官用和商用编码大小通吃,一网打尽。Unicode自1991年便和ISO的UCS小组密切配合,让Unicode和ISO 10646保持一致。因此Unicode 自2.0版开始,便和 ISO 10646-1使用相同的编码。
康熙字典中的汉字有4万7千,如果再加上里面没有的简体字,和不同写法的日文字,那么 Unicode6万多的分配空间,光用来分配汉字就显得捉禁见昼,更别说什么泰文,阿拉伯等其他文字了。针对这个问题Unicode和UCS采用了[中日韩文整合](CJK Unification)的解决方案,把中日韩笔画详尽的汉字用同一个单码表示。
经过[中日韩文整合]的Unicode称为统汉字Unihan。
完整的Unicode4.0版可由http://www.unicode.org/Public/UNIDATA/Unihan.txt 下载。UTF (Unicode/UCS Transformation Format),Unicode推荐使用UTF-8和UTF-16两种格式其中8和16指的是Bits数而不是Bytes数。
UTF-16基本就是Unicode双字节的实现,加上一个应付未来需要的扩充编码机制(很少用)
UTF-8 是一种不等幅的编码方式,英数字(Ascii字码)保持原状,完全不受影响(因此不需要做转换),而其他汉字资料须透过程序来转换,会[变胖],因为每个字需要额外一个或两个Bytes来编码。
UCS字符集中,有UCS-2和UCS-4等编码方式其中的2和4指的是bytes数,对应UTF-8和UTF-16.
UCS-2基本和Unicode双byte 编码差不多
UCS-4四 byte编码表示一个字,在每个 UCS-2前面加上两个空白的Byte,便可得到对应的 UCS-4。Unicode的空间分配:
以下Unicode区位码均以16进制表示
Unicode的前256个字符和ISO-8859-1(西欧字母)完全相同,其中前半段就是Ascii(u+0000到u+00FF)。每个ISO-8859-1码前面补上一个空byte(0x00)后才是相应的Unicode码。
和我们切身相关的Unihan主要分布在u+3400到u+F9FFF之间,GB2312和BIG5主要分布在u+4E00到U+9FFF之间。UTF-8的编码原理和特性:
知道了西欧字符和汉字在Unicode中的位置后,来看看UTF-8U+0000~U+007E 1 _ _ _ _ _ _ _ (7bits)
U+0080~U+07FF 1 1 0_ _ _ _ _ 1 0_ _ _ _ _ _ (11bits)
U+0800~U+FFFF 1 1 1 0 _ _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _ (16bits)
看一看Unicode三种格式提出自由的bits(下划线空位)是否足以用来代表区位中各Unicode码,刚好够用。
那么当程序处理UTF-8编码文件时,如何得知一个字符的疆界落在哪里?还有到底他是以三种形式那一中出现呢?
每个以UTF-8编码的字符,不管是以一、二、三个bytes出现,第一个byte前端都清楚地标示了该字符的byte总数。如110种有两个1,代表这种字符是以第二种方式出现,由两个bytes组成。而1110有三个1,表示这种字符一点种方式出现,由三个字节组成。
每个多重byte的UTF-8编码有一个共同的通性,即其中的第二个第三个byte, 一律以10两个bits开头。由于其中的最高位总设成1,可以很容易和那些在UTF-8中只用一个Byte的ASCII字元区分开来,方便侦错。
因为上述设计特点,UTF-8和Unicode之间,可以很容易做双向自由转换,而不会丢失任何资料。
Unicode (统一码)顾名思义是一个将世界上各种文字统一在一起的东东。由美国各大电脑厂商组成的Unicode策进会来推动。目的,推广一个世界通用的编码体制,惊世界上所有常用的文字都涵盖进去,从而减少个电脑商开发国外市场遇到的问题。
为了将成千上万的文字统统收集到一个共同的编码机制下,在兼顾经济的原则下,不管是东方还是西方文字,每个字在Unicode中一律以两个Bytes来表示,这样至少有2的16次方65536种不同的组合,足以应付目前绝大多数场合的需要。
基本上,计算机只是处理数字。它们指定一个数字,来储存字母或其他字符。在创造Unicode之前,有数百种指定这些数字的编码系统。没有一个编码可以包含足够的字符:例如,单单欧州共同体就需要好几种不同的编码来包括所有的语言。即使是单一种语言,例如英语,也没有哪一个编码可以适用于所有的字母,标点符号,和常用的技术符号。
这些编码系统也会互相冲突。也就是说,两种编码可能使用相同的数字代表两个不同的字符,或使用不同的数字代表相同的字符。任何一台特定的计算机(特别是服务器)都需要支持许多不同的编码,但是,不论什么时候数据通过不同的编码或平台之间,那些数据总会有损坏的危险。
Unicode给每个字符提供了一个唯一的数字,不论是什么平台,不论是什么程序,不论什么语言。Unicode标准已经被这些工业界的领导们所采用,例如:Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys和其它许多公司。最新的标准都需要Unicode,例如XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML等等,并且,Unicode是实现ISO/IEC 10646的正规方式。许多操作系统,所有最新的浏览器和许多其他产品都支持它。Unicode标准的出现和支持它工具的存在,是近来全球软件技术最重要的发展趋势。
将Unicode与客户服务器或多层应用程序和网站结合,比使用传统字符集节省费用。Unicode使单一软件产品或单一网站能够贯穿多个平台,语言和国家,而不需要重建。它可将数据传输到许多不同的系统,而无损坏。
在与Unicode相关的各技术文件中,经常会看到ISO 10646和UCS这两个名词。
ISO是位于瑞士的国际标准局的缩写。
UCS为ISO颁布的第10646号标准 Universal Character Set,就是世界通用字符集。
UCS通用字符集采用4个Bytes来编码,将世界上所有的官用和商用编码大小通吃,一网打尽。Unicode自1991年便和ISO的UCS小组密切配合,让Unicode和ISO 10646保持一致。因此Unicode 自2.0版开始,便和 ISO 10646-1使用相同的编码。
康熙字典中的汉字有4万7千,如果再加上里面没有的简体字,和不同写法的日文字,那么 Unicode6万多的分配空间,光用来分配汉字就显得捉禁见昼,更别说什么泰文,阿拉伯等其他文字了。针对这个问题Unicode和UCS采用了[中日韩文整合](CJK Unification)的解决方案,把中日韩笔画详尽的汉字用同一个单码表示。
经过[中日韩文整合]的Unicode称为统汉字Unihan。
完整的Unicode4.0版可由http://www.unicode.org/Public/UNIDATA/Unihan.txt 下载。UTF (Unicode/UCS Transformation Format),Unicode推荐使用UTF-8和UTF-16两种格式其中8和16指的是Bits数而不是Bytes数。
UTF-16基本就是Unicode双字节的实现,加上一个应付未来需要的扩充编码机制(很少用)
UTF-8 是一种不等幅的编码方式,英数字(Ascii字码)保持原状,完全不受影响(因此不需要做转换),而其他汉字资料须透过程序来转换,会[变胖],因为每个字需要额外一个或两个Bytes来编码。
UCS字符集中,有UCS-2和UCS-4等编码方式其中的2和4指的是bytes数,对应UTF-8和UTF-16.
UCS-2基本和Unicode双byte 编码差不多
UCS-4四 byte编码表示一个字,在每个 UCS-2前面加上两个空白的Byte,便可得到对应的 UCS-4。Unicode的空间分配:
以下Unicode区位码均以16进制表示
Unicode的前256个字符和ISO-8859-1(西欧字母)完全相同,其中前半段就是Ascii(u+0000到u+00FF)。每个ISO-8859-1码前面补上一个空byte(0x00)后才是相应的Unicode码。
和我们切身相关的Unihan主要分布在u+3400到u+F9FFF之间,GB2312和BIG5主要分布在u+4E00到U+9FFF之间。UTF-8的编码原理和特性:
知道了西欧字符和汉字在Unicode中的位置后,来看看UTF-8U+0000~U+007E 1 _ _ _ _ _ _ _ (7bits)
U+0080~U+07FF 1 1 0_ _ _ _ _ 1 0_ _ _ _ _ _ (11bits)
U+0800~U+FFFF 1 1 1 0 _ _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _ (16bits)
看一看Unicode三种格式提出自由的bits(下划线空位)是否足以用来代表区位中各Unicode码,刚好够用。
那么当程序处理UTF-8编码文件时,如何得知一个字符的疆界落在哪里?还有到底他是以三种形式那一中出现呢?
每个以UTF-8编码的字符,不管是以一、二、三个bytes出现,第一个byte前端都清楚地标示了该字符的byte总数。如110种有两个1,代表这种字符是以第二种方式出现,由两个bytes组成。而1110有三个1,表示这种字符一点种方式出现,由三个字节组成。
每个多重byte的UTF-8编码有一个共同的通性,即其中的第二个第三个byte, 一律以10两个bits开头。由于其中的最高位总设成1,可以很容易和那些在UTF-8中只用一个Byte的ASCII字元区分开来,方便侦错。
因为上述设计特点,UTF-8和Unicode之间,可以很容易做双向自由转换,而不会丢失任何资料。
由于操作系统和使用环境不一样,产生乱码的方式也不一样,但是如果掌握了上面的Unicode 编码原理,自己仔细分析一下,很多问题便可迎刃而解。
下面看看几个常见的例子。
1. 如果一些网站服务器例如Tomcat 如果遇到中文乱码问题,可以修改conf目录下的server.xml
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100" debug="0"connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="GBK"/>
URIENcoding 设成GBK或GB2312
2. 表单中或传递字符串:本来输入的汉字是正常的,但是提交后再显示出来是乱码,因为提交的一般是 ISO8859编码,所以显示的时候要转成GB2312编码:String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");
//rs为待转换的字符串
然后使用S字符串的值就可以了
3. 有的服务器端的语言环境如果设成简体中文的也可以解决此类问题
4. 插入数据库中的字符是乱码
看看数据库中支持的是何种编码方式,用类似2中的方式作一下转换即可。
5. 总之,用jsp开发,碰到乱码,你得分析是读的时候发生乱码,还是写的时候发生乱码,用2中的转换,基本就能解决问题,有些时候写的时候做一次转换,例如:
String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");
//读的时候在转换回来
String S=new String(rs.getString("news").getBytes("ISO8859_1"),"GB2312");
或者把ISO8859-1和GB2312 的位置换一下,自己多试试,就能找到解决问题的办法。希望大家讨论下可行否,多给提点意见!
本文转:http://www.itpub.net/336395.html
---------------------------------------------------怎么转?
我想把linux下的mysql建的数据库全转成UTF-8
gb2312包含的字符集太少了
建议不要用
3.2. new String(charset)这是java字符串处理的另一个标准函数,和上一个函数的作用相反,将字节数组按照charset编码进行组合识别,最后转换为unicode存储。参考上述getBytes的例子,"gbk" 和"utf8"都可以得出正确的结果"4e2d 6587",但iso8859-1最后变成了"003f 003f"(两个问号)。因为utf8可以用来表示/编码所有字符,所以new String( str.getBytes( "utf8" ), "utf8" ) === str,即完全可逆。3.3. setCharacterEncoding()该函数用来设置http请求或者相应的编码。对于request,是指提交内容的编码,指定后可以通过getParameter()则直接获得正确的字符串,如果不指定,则默认使用iso8859-1编码,需要进一步处理。参见下述"表单输入"。值得注意的是在执行setCharacterEncoding()之前,不能执行任何getParameter()。java doc上说明:This method must be called prior to reading request parameters or reading input using getReader()。而且,该指定只对POST方法有效,对GET方法无效。分析原因,应该是在执行第一个getParameter()的时候,java将会按照编码分析所有的提交内容,而后续的getParameter()不再进行分析,所以setCharacterEncoding()无效。而对于GET方法提交表单是,提交的内容在URL中,一开始就已经按照编码分析所有的提交内容,setCharacterEncoding()自然就无效。对于response,则是指定输出内容的编码,同时,该设置会传递给浏览器,告诉浏览器输出内容所采用的编码。3.4. 处理过程下面分析两个有代表性的例子,说明java对编码有关问题的处理方法。3.4.1. 表单输入User input *(gbk:d6d0 cec4) browser *(gbk:d6d0 cec4) web server iso8859-1(00d6 00d 000ce 00c4) class,需要在class中进行处理:getbytes("iso8859-1")为d6 d0 ce c4,new String("gbk")为d6d0 cec4,内存中以unicode编码则为4e2d 6587。l 用户输入的编码方式和页面指定的编码有关,也和用户的操作系统有关,所以是不确定的,上例以gbk为例。l 从browser到web server,可以在表单中指定提交内容时使用的字符集,否则会使用页面指定的编码。而如果在url中直接用?的方式输入参数,则其编码往往是操作系统本身的编码,因为这时和页面无关。上述仍旧以gbk编码为例。
。一般不必不使用该设置,浏览器会直接使用网页的编码。
4. 系统软件下面讨论几个相关的系统软件。4.1. mysql数据库很明显,要支持多语言,应该将数据库的编码设置成utf或者unicode,而utf更适合与存储。但是,如果中文数据中包含的英文字母很少,其实unicode更为适合。数据库的编码可以通过mysql的配置文件设置,例如default-character-set=utf8。还可以在数据库链接URL中设置,例如: useUnicode=true&characterEncoding=UTF-8。注意这两者应该保持一致,在新的sql版本里,在数据库链接URL里可以不进行设置,但也不能是错误的设置。4.2. apacheappache和编码有关的配置在httpd.conf中,例如AddDefaultCharset UTF-8。如前所述,该功能会将所有静态页面的编码设置为UTF-8,最好关闭该功能。另外,apache还有单独的模块来处理网页响应头,其中也可能对编码进行设置。4.3. linux默认编码这里所说的linux默认编码,是指运行时的环境变量。两个重要的环境变量是LC_ALL和LANG,默认编码会影响到java URLEncode的行为,下面有描述。建议都设置为"zh_CN.UTF-8"。4.4. 其它为了支持中文文件名,linux在加载磁盘时应该指定字符集,例如:mount /dev/hda5 /mnt/hda5/ -t ntfs -o iocharset=gb2312。另外,如前所述,使用GET方法提交的信息不支持request.setCharacterEncoding(),但可以通过tomcat的配置文件指定字符集,在tomcat的server.xml文件中,形如:。这种方法将统一设置所有请求,而不能针对具体页面进行设置,也不一定和browser使用的编码相同,所以有时候并不是所期望的。5. URL地址URL地址中含有中文字符是很麻烦的,前面描述过使用GET方法提交表单的情况,使用GET方法时,参数就是包含在URL中。5.1. URL编码
byte lByte=b[i++];//to fast operation, ++ now, ready for the following for(;;)if(lByte>=0) continue;//>=0 is normal asciiif(lByte<(byte)0xc0 || lByte>(byte)0xfd) return false;int lCount=lByte>(byte)0xfc?5:lByte>(byte)0xf8?4:lByte>(byte)0xf0?3:lByte>(byte)0xe0?2:1;if(i+lCount>lLen) return false;for(int j=0;j=(byte)0xc0) return false;}return true;}相应地,一个使用上述方法的例子如下:public static String getUrlParam(String aStr,String aDefaultCharset)throws UnsupportedEncodingException{if(aStr==null) return null;byte[] lBytes=aStr.getBytes("ISO-8859-1");return new String(lBytes,StringUtil.isValidUtf8(lBytes)?"utf8":aDefaultCharset);}不过,该方法也存在缺陷,如下两方面:l 没有包括对用户默认编码的识别,这可以根据请求信息的语言来判断,但不一定正确,因为我们有时候也会输入一些韩文,或者其他文字。l 可能会错误判断UTF-8字符,一个例子是"学习"两个字,其GBK编码是" xd1xa7xcfxb0",如果使用上述isValidUtf8方法判断,将返回true。可以考虑使用更严格的判断方法,不过估计效果不大。有一个例子可以证明google也遇到了上述问题,而且也采用了和上述相似的处理方法,比如,如果在地址栏中输入"http://www.google.com/search?hl=zh-CN&newwindow=1&q=学习",google将无法正确识别,而其他汉字一般能够正常识别。