1、资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。中文编码的处理每个国家 ( 或区域 ) 都规定了计算机信息交换用的字符编码集 , 如美国的扩展 ASCII 码 , 中国的 GB2312-80, 日本的 JIS 等 , 作为该国家 / 区域内信息处理的基础 , 有着统一编码的重要作用。字符编码集按长度分为 SBCS( 单字节字符集 ) , DBCS( 双字节字符集 ) 两大类。早期的软件 ( 特别是操作系统 ) , 为了解决本地字符信息的计算机处理 , 出现了各种本地化版本 ( L10N) , 为了区分 , 引进了 LANG, Codepage 等概念。可是由于各个本地字符集代码范
2、围重叠 , 相互间信息交换困难 ; 软件各个本地化版本独立维护成本较高。 因此有必要将本地化工作中的共性抽取出来 , 作一致处理 , 将特别的本地化处理内容降低到最少。 这也就是所谓的国际化 ( I18N) 。各种语言信息被进一步规范为 Locale 信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode 。现在大部分具有国际化特征的软件核心字符处理都是以 Unicode 为基础的 , 在软件运行时根据当时的 Locale/Lang/Codepage 设置确定相应的本地字符编码设置 , 并依此处理本地字符。在处理过程中需要实现 Unicode 和本地字符集的相互转换 , 甚或以 Un
3、icode 为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸 , 任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。Java 语言内部是用 Unicode表示字符的 ,遵守 Unicode V2.0 。Java 程序无论是从 / 往文件系统以字符流读/ 写文件 ,还是往 URL 连接写 HTML 信息 ,或从URL 连接读取参数值 ,都会有字符编码的转换。 这样做虽然增加了编程的复杂度,容易引起混淆 ,但却是符合国际化的思想的。从理论上来说 ,这些根据字符集设置而进行的字符转换不应该产生太多问题。而资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除
4、。事实是由于应用程序的实际运行环境不同, Unicode和各个本地字符集的补充、完善 ,以及系统或应用程序实现的不规范,转码时出现的问题时时困扰着程序员和用户。2. GB2312-80, GBK, GB18030-汉字字符集及 Encoding其实解决 JAVA 程序中的汉字编码问题的方法往往很简单,但理解其背后的原因 ,定位问题 ,还需要了解现有的汉字编码和编码转换。GB2312-80 是在国内计算机汉字信息技术发展初始阶段制定的,其中包含了大部分常见的一、二级汉字 ,和 9区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集,这也是最基本的中文字符集。 其编码范围是高位0
5、xa1 0xfe,低 位也 是0xa1-0xfe;汉字从0xb0a1 开始 ,结 束于0xf7fe;GBK 是 GB2312-80 的扩展 , 是向上兼容的。它包含了 20902 个汉字 , 其编码范围是 0x8140-0xfefe, 剔除高位 0x80 的字位。其所有字符都能够一对一映射到 Unicode 2.0, 也就是说 JAVA 实际上提供了 GBK 字符集的支持。这是现阶段 Windows 和其它一些中文操作系统的缺省字符集 , 但并不是所有的国际化软件都支持该字符集 , 感觉是她们并不完全知道 GBK 是怎么回事。值得注意的是它不是国家标准 , 而只是规范。随着 GB18030-
6、国标的发布 , 它将在不久的将来完成它的历史使命。GB18030- (GBK2K) 在 GBK 的基础上进一步扩展了汉字 , 增加了藏、 蒙等少数民族的字形。GBK2K从根本上解决了字位不够 , 字形不足的问题。它有几个特点 ,它并没有确定所有的字形,只是规定了编码范围 ,留待以后扩充。资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。编码是变长的 , 其二字节部分与 GBK 兼容 ; 四字节部分是扩充的字形、 字位 , 其编码范围是首字节 0x81-0xfe 、 二字节 0x30-0x39 、 三字节 0x81-0xfe 、 四字节 0x30-0x39 。它的推广是分阶段的 ,首
7、先要求实现的是能够完全映射到Unicode 3.0标准的所有字形。它是国家标准 ,是强制性的。现在还没有任何一个操作系统或软件实现了GBK2K 的支持 ,这是现阶段和将来汉化的工作内容。Unicode 的介绍 .就免了吧。JAVA 支持的 encoding 中与中文编程相关的有 : ( 有几个在 JDK 文档中未列出 )ASCII 7-bit,同 ascii7ISO8859-1 8-bit,同 8859_1,ISO-8859-1,ISO_8859-1,latin1.GB2312-80 同 gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381, 1383, Cp
8、1383,ISO2022CN,ISO2022CN_GB.GBK (注意大小写 ), 同 MS936UTF8 UTF-8GB18030 (现在只有 IBM JDK1.3.? 有支持 ),同 Cp1392,1392JAVA 语言采用 Unicode 处理字符 . 但从另一个角度来说 , 在 java 程序中也能够采用非 Unicode 的转码 , 重要的是保证程序入口和出口的汉字信息不失真。 如完全采用 ISO-8859-1 来处理汉字也能达到正确的结果。 网络上流行的许多解决方法 ,都属于这种类型。为了不致引起混淆,本文不对这种方法作讨论。3. 中文转码时 ? 、 乱码的由来资料内容仅供您学习参
9、考，如有不当或者侵权，请联系改正或者删除。两个方向转换都有可能得到错误的结果:Unicode-Byte,如果目标代码集不存在对应的代码,则得到的结果是 0x3f.如 :u00d6u00ecu00e9u0046u00bbu00f9.getBytes(GBK)的结果是? F?, Hex值3fa8aca8a6463fa8b4是.仔细看一下上面的结果 , 你会发现 u00ec 被转换为 0xa8ac, u00e9 被转换为 xa8a6. 它的实际有效位变长了 ! 这是因为 GB2312符号区中的一些符号被映射到一些公共的符号编码 , 由于这些符号出现在ISO-8859-1 或其它一些 SBCS字符集中
10、 , 故它们在 Unicode 中编码比较靠前 ,有一些其有效位只有 8 位,和汉字的编码重叠 ( 其实这种映射只是编码的映射, 在显示时仔细不是一样的。Unicode 中 的 符 号 是 单 字 节 宽 , 汉 字 中 的 符 号 是 双 字 节 宽 ) .在Unicodeu00a0-u00ff之间这样的符号有 20 个。了解这个特征非常重要 !由此就不难理解为什么 JAVA编程中 , 汉字编码的错误结果中常常会出现一些乱码( 其实是符号字符 ), 而不全是 ? 字符 , 就比如上面的例子。Byte-Unicode,如果 Byte标识的字符在源代码集不存在,则得到的结果是0xfffd.如 :
11、Byteba=(byte)0x81,(byte)0x40,(byte)0xb0,(byte)0xa1;newString(ba,gb2312);结果是 ? 啊, hex值是 ufffdu554a. 0x8140是 GBK字符 ,表没有对应的值 ,取ufffd. (请注意 :在显示该 uniCode 时,本地字符 ,因此也适用上一种情况 ,显示为一个 ?.)按 GB2312转换因为没有对应的实际编程中 , JSP/Servlet 程序得到错误的汉字信息 , 往往是这两个过程的叠加 , 有时甚至是两个过程叠加后重复作用的结果 .资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。4. J
12、SP/Servlet汉字编码问题及在WAS 中的解决办法4.1常见的 encoding问题的现象网上常出现的 JSP/Servlet encoding问题一般都表现在browser或应用程序端 , 如:浏览器中看到的Jsp/Servlet页面中的汉字怎么都成了? ?浏览器中看到的Servlet页面中的汉字怎么都成了乱码?JAVA 应用程序界面中的汉字怎么都成了方块?Jsp/Servlet页面无法显示 GBK 汉字。JSP 页面中内嵌在 , 等 Tag 包含的 JAVA code 中的中文成了乱码 ,但页面的其它汉字是正确。Jsp/Servlet不能接收 form 提交的汉字。JSP/Servl
13、et数据库读写无法获得正确的内容。隐藏在这些问题后面的是各种错误的字符转换和处理( 除第3 个外 , 是因为Java font设置错误引起的 ) 。解决类似的字符encoding问题 , 需要了解Jsp/Servlet的运行过程 , 检查可能出现问题的各个点。4.2 JSP/Servlet web编程时的encoding问题运行于Java 应用服务器的程如下图所示 :其中有字符编码转换的地方有JSP/Servlet:为Browser提供HTML 内容 ,其过JSP编译。Java应用服务器将根据JVM的file.encoding值读取JSP源文件 ,编译生成JAVA源文件 ,再根据file.en
14、coding值写回文件系统。如果当前系统语言支持GBK,那么这时候不会出现encoding问题。如果是英文的系统,如LANG 是en_US的Linux, AIX或Solaris,则要将JVM的file.encoding资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。值置成GBK 。 系统 语言如果是file.encoding,将 file.encodingGB2312, 则根据 需要 ,确定要不要 设置设为 GBK 能够解决潜在的GBK 字符乱码问题Java 需要被编译为.class才能在 JVMfile.encoding问题。从这里开始servlet中执行 ,和 jsp这个过程
15、存在与的运行就类似了a. 同样的,只不过Servlet 的编译不是自动进行的。 对于 JSP程序 , 对产生的 JAVA 中间文件的编译是自动进行的 ( 在程序中直接调用 sun.tools.javac.Main 类 ). 因此如果在这一步出现问题的话 , 也要检查 encoding 和 OS的语言环境 , 或者将内嵌在 JSP JAVACode 中的静态汉字转为 Unicode, 要么静态文本输出不要放在 JAVA code 中。 对于 Servlet, javac 编译时手工指定 -encoding 参数就能够了。Servlet需要将HTML 页面内容转换为browser可接受的encod
16、ing内容发送出去。依赖于各JAVA App Server的实现方式,有的将查询Browser的accept-charset和 accept-language参数或以其它猜的方式确定encoding值 , 有的则不论。因此采用固定 encoding 可能是最好的解决方法。对于中文网页 , 可 在 JSP 或 Servlet 中 设 置 contentType=text/html; charset=GB2312; 如果页面中有 GBK字符 , 则设置为 contentType=text/html; charset=GBK, 由于 IE 和 Netscape 对 GBK的支持程度不一样 , 作这种
17、设置时需要测试一下。因为 16 位 JAVA char 在网络传送时高 8 位会被丢弃 , 也为了确保 Servlet 页面中的汉字 ( 包括内嵌的和 servlet 运行过程中得到的 ) 是期望的内码 , 能够用PrintWriterout=res.getWriter()取代ServletOutputStreamout=res.getOutputStream(). PrinterWriter将根据contentType中指定的charset作 转 换(ContentType需 在 此 之 前 指 定!);也 能 够 用资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。Output
18、StreamWriter封装 ServletOutputStream类并用 write(String)输出汉字字符串。对于 JSP, JAVA Application Server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。这是解释 URL 字符 encoding问题。如果经过 get/post方式从 browser返回的参数值中包含汉字信息 , servlet将无法得到正确的值。SUN的 J2SDK 中,HttpUtils.parseName在解析参数时根本没有考虑browser的语言设置 ,而是将得到的值按 byte方式解析。这是网上讨论得最多的 encoding问题。因为这是设计
19、缺陷 , 只 能以 bin方式 重新 解析 得到 的字 符 串 ;或者 以 hackHttpUtils类的方式解决。参考文章2均有介绍 ,不过最好将其中的中文encoding GB2312、 CP1381都改为 GBK, 否则遇到 GBK 汉字时 ,还是会有问题。ServletAPI2.3提供一个新的函数HttpServeletRequest.setCharacterEncoding用于在调用request.getParameter( ”param_name”)前指定应用程序希望的encoding,这将有助于彻底解决这个问题。4.3 IBM Websphere Application Server中的解决方法WebSphere Application Server 对标准的 Servlet API 2.x 作了扩展 , 提供较好的多语言支持。运行在中文的操作系统中 , 能够不作任何设置就能够很好地处理汉字。下面的说明只是对 WAS是运行在英文的系统中 , 或者需要有 GBK支持时有效。上述zh-cnc,d情况 , WAS等均被映射为都要查询Browser的语言设置 ,在缺省状况下, zh,JAVA encoding CP1381(注意 : CP1381只是等同于
