JSP Servlet 中的汉字编码问题.doc

JSP Servlet 中的汉字编码问题 JSP/Servlet中的汉字编码问题2010-08-11 16：201.问题的起源 每个国家(或区域)都规定了计算机信息交换用的字符编码集，如美国的ASCII，中国的GB2312 -80，日本的JIS等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按 长度分为SBCS(单字节字符集)，DBCS(双字节字符集)两大类。早期的软件(尤其是操作系统)， 为了解决本地字符信息的计算机处理，出现了各种本地化版本(L10N)，为了区分，引进了LANG， Codepage等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版 本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理 内容降低到最少。这也就是所谓的国际化(I18N)。各种语言信息被进一步规范为Locale信息。处理 的底层字符集变成了几乎包含了所有字形的Unicode。 现在大部分具有国际化特征的软件核心字符处理都是以Unicode为基础的，在软件运行时根据当 时的Locale/Lang/Codepage设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中 需要实现Unicode和本地字符集的相互转换，甚或以Unicode为中间的两个不同本地字符集的相互转 换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可 接受的内容。 Java语言内部是用Unicode表示字符的，遵守Unicode V2.0。Java程序无论是从/往文件系统 以字符流读/写文件，还是往URL连接写HTML信息，或从URL连接读取参数值，都会有字符编码的 转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。 从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程 序的实际运行环境不同，Unicode和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范 ，转码时出现的问题时时困扰着程序员和用户。 2.GB2312-80，GBK，GB18030-2000汉字字符集 其实解决JAVA程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需 要了解现有的汉字编码和编码转换。 GB2312-80是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级 汉字，和9区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是 最基本的中文字符集。其编码范围是高位0xa1-0xfe，低位也是0xa1-0xfe；汉字从0xb0a1开始，结 束于0xf7fe； GBK是GB2312-80的扩展，是向上兼容的。它包含了20902个汉字，其编码范围是0x8140- 0xfefe，剔除高位0x80的字位。其所有字符都可以一对一映射到Unicode 2.0，也就是说JAVA实际 上提供了GBK字符集的支持。这是现阶段Windows和其它一些中文操作系统的缺省字符集，但并不是 所有的国际化软件都支持该字符集，感觉是他们并不完全知道GBK是怎么回事。值得注意的是它不是 国家标准，而只是规范。随着GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。 GB18030-2000(GBK2K)在GBK的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。 GBK2K从根本上解决了字位不够，字形不足的问题。它有几个特点： ●它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。 ●编码是变长的，其二字节部分与GBK兼容；四字节部分是扩充的字形、字位，其编码范围是首 字节0x81-0xfe、二字节0x30-0x39、三字节0x81-0xfe、四字节0x30-0x39。 ●它的推广是分阶段的，首先要求实现的是能够完全映射到Unicode 3.0标准的所有字形。 ●它是国家标准，是强制性的。 现在还没有任何一个操作系统或软件实现了GBK2K的支持，这是现阶段和将来汉化的工作内容。 3.JSP/Servlet汉字编码问题及在WAS中的解决办法 3.1常见的encoding问题的现象 网上常出现的JSP/Servlet encoding问题一般都表现在browser或应用程序端，如： ●浏览器中看到的Jsp/Servlet页面中的汉字怎么都成了?? ●浏览器中看到的Servlet页面中的汉字怎么都成了乱码? ●JAVA应用程序界面中的汉字怎么都成了方块? ●Jsp/Servlet页面无法显示GBK汉字。 ●Jsp/Servlet不能接收form提交的汉字。 ●JSP/Servlet数据库读写无法获得正确的内容。 隐藏在这些问题后面的是各种错