网上就 JSP/Servlet 中 DBCS 字符编码问题有许多优秀的文章和讨论本文对它们作一些整理并结合 IBM WebSphere Application Server （WAS）的解决方法作一些说明希望它不是多余的
内容
问题的起源
GBGBKGB 汉字字符集及 Encoding
中文转码时′?′乱码的由来
JSP/Servlet 汉字编码问题及在 WAS 中的解决办法
结束语
参考文章
问题的起源
每个国家（或区域）都规定了计算机信息交换用的字符编码集如美国的扩展 ASCII码 中国的 GB日本的 JIS 等作为该国家/区域内信息处理的基础有着统一编码的重要作用字符编码集按长度分为 SBCS（单字节字符集）DBCS（双字节字符集）两大类早期的软件（尤其是操作系统）为了解决本地字符信息的计算机处理出现了各种本地化版本（LN）为了区分引进了 LANG Codepage 等概念但是由于各个本地字符集代码范围重叠相互间信息交换困难软件各个本地化版本独立维护成本较高因此有必要将本地化工作中的共性抽取出来作一致处理将特别的本地化处理内容降低到最少这也就是所谓的国际化（IN）各种语言信息被进一步规范为 Locale 信息处理的底层字符集变成了几乎包含了所有字形的 Unicode
现在大部分具有国际化特征的软件核心字符处理都是以 Unicode 为基础的在软件运行时根据当时的 Locale/Lang/Codepage 设置确定相应的本地字符编码设置并依此处理本地字符在处理过程中需要实现 Unicode 和本地字符集的相互转换甚或以 Unicode 为中间的两个不同本地字符集的相互转换这种方式在网络环境下被进一步延伸任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容
Java 语言内部是用 Unicode 表示字符的遵守 Unicode VJava 程序无论是从/往文件系统以字符流读/写文件还是往 URL 连接写 HTML 信息或从 URL 连接读取参数值都会有字符编码的转换这样做虽然增加了编程的复杂度容易引起混淆但却是符合国际化的思想的
从理论上来说这些根据字符集设置而进行的字符转换不应该产生太多问题而事实是由于应用程序的实际运行环境不同Unicode 和各个本地字符集的补充完善以及系统或应用程序实现的不规范转码时出现的问题时时困扰着程序员和用户
GBGBKGB 汉字字符集及 Encoding
其实解决 JAVA 程序中的汉字编码问题的方法往往很简单但理解其背后的原因定位问题还需要了解现有的汉字编码和编码转换
GB 是在国内计算机汉字信息技术发展初始阶段制定的其中包含了大部分常用的一二级汉字和 区的符号该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集这也是最基本的中文字符集其编码范围是高位xa－xfe低位也是 xaxfe汉字从 xba 开始结束于 xffe
GBK 是 GB 的扩展是向上兼容的它包含了 个汉字其编码范围是 xxfefe剔除高位 x 的字位其所有字符都可以一对一映射到 Unicode 也就是说 JAVA 实际上提供了 GBK 字符集的支持这是现阶段 Windows 和其它一些中文操作系统的缺省字符集但并不是所有的国际化软件都支持该字符集感觉是他们并不完全知道 GBK 是怎么回事值得注意的是它不是国家标准而只是规范随着 GB国标的发布它将在不久的将来完成它的历史使命
GB(GBKK) 在 GBK 的基础上进一步扩展了汉字增加了藏蒙等少数民族的字形GBKK 从根本上解决了字位不够字形不足的问题它有几个特点
它并没有确定所有的字形只是规定了编码范围留待以后扩充
编码是变长的其二字节部分与 GBK 兼容四字节部分是扩充的字形字位其编码范围是首字节 xxfe二字节xx三字节 xxfe四字节xx
它的推广是分阶段的首先要求实现的是能够完全映射到 Unicode 标准的所有字形
它是国家标准是强制性的
现在还没有任何一个操作系统或软件实现了 GBKK 的支持这是现阶段和将来汉化的工作内容
Unicode 的介绍就免了吧
JAVA 支持的encoding中与中文编程相关的有(有几个在JDK文档中未列出)
ASCII bit 同 ascii
