从汉化到国际化

1、从汉化到国际化内容摘要：Java 对输入输入首先有一个“字节流”到“字符流”之间的编码 / 解码过程，这个设置是根据系统配置决定的，为什么 PHP 之类的应用很少有字符集问题而 Java 有很好的国际化机制， 却经常出现乱码问题呢？简单的举例： 有一个包含“你好”这2 个中文字的文件实际上是 4 个字节组 成的： C4 E3 BA C3 在英文操作系统中缺省的编码解码方式是缺省编码方式是 ISO8859 ，所以直接从文件中读取的结果是 4 个的字节，按 ISO8859 解码后在程序中操作的是 4 个 Java 字符，虽然每 个 JAVA 字符是 16 位 Unicode ，但每个字符仍是 8

2、位字节 的映射 u00C4u00E3u00BAu00C3 ，因此处理的仍是“英 文”。而显示过程中， 是浏览器将字节流正确的显示成了相应 的中文。而一个 Java 应用在 GBK 编码方式的操作系统中， 直接从文 件中读取 4 个的字节后， 按 GBK 方式解码后是 2 个 16 位的 Java 字符 u4F60u597D ，每个字都是相应 Unicode 的 CJK 区块所对应的中文。更多的例子请参考： Java 的中文处理学习笔记这也就是为什么在 php 等应用很少出字符集问题的原因： 在 服务器端环境缺省一般是英文 (ISO8859-1 )，等于全部处理 使用的都是按字节方式处理的。数据

3、输入输出过程中编码方 式完全不被改动，因此乱码问题很少出现。而 Java 实际上 提供了把每个中文直接当成 1个“字”而不是2 个字节处理的 机制，主要的乱码问题往往是输入输出时编码解码方式不一 致造成的。而且通过 Unicode 机制，程序除了实现程序界面 根据本地化的适应外，甚至程序处理的内容本身的在不同字 符集的操作系统中也是可以通用的，比如：在繁体中文操作 系统中编辑的内容，在简体中文操作系统中也能正常的查询。 以下例子可能更说明问题：JAVA 应用的中文问题： 如何通过 GNU/Linux 系统的本地化 设置让 JAVA 应用支持中文Java Web 应用设计中的中文问题：通过 we

4、b.xml 设置解决 URLEncoder.encode() 方法和系统缺省编码方式相关的问题 以 GOOGLE 的搜索引擎为例：说明如何将国际化和本地化 应用到自己的应用设计中 (UniCode inside Localization outsite) 通过 GNU/Linux 系统的本地化设置让 JAVA 应用支持中文 Java 编程技术中汉字问题的分析及解决这篇直到最近还经 常被一些网站转贴的文章中有一个例子说明了很多中国程序员遇到汉字乱码问题的思路：原文如下：GB2312 it （汉化）前不久，我的一位技术上的朋友发信给我说，他终于找 到了 Java Servlet 中文问题的根源。两

5、周以来，他一直为 Java Servlet 的中文问题所困扰，因为每面对一个含有中文 字符的字符串都必须进行强制转换才能够得到正确的结果 (这好象是大家公认的唯一的解决办法) 。后来，他确实不 想如此继续安分下去了，因为这样的事情确实不应该是高级 程序员所要做的工作， 他就找出 Servlet 解码的源代码进行 分析，因为他怀疑问题就出在解码这部分。经过四个小时的 奋斗，他终于找到了问题的根源所在。原来他的怀疑是正确 的， Servlet 的解码部分完全没有考虑双字节， 直接把 %XX 当作一个字符。 (原来 Java Soft 也会犯这幺低级的错误！ ) 如果你对这个问题有兴趣或者遇到了同样

6、的烦恼的话，你可 以按照他的步骤对 Servlet.jar 进行修改：找到源代码 HttpUtils 中的 static private String parseName ，在返回前 将 sb( StringBuffer ) 复制成 byte bs ，然后 return new String(bs,”GB2312”) 。作上述修改后就需要自己解码了：HashTable form=HttpUtils .parseQueryString(request.getQueryString()或者 form=HttpUtils.parsePostData( )千万别忘了编译后放到 Servlet.jar

7、里面请问这位“高级”程序员几个问题：如果这是一个商业产品的话， 难道客户需要你 Hacking 过的 Servlet.jar 才运行这个应用吗？ 难道这个产品只能用在中文平台的 GB2312 上吗？如果是日 文应用怎么办，如法 Hacking 吗？ 也许我错了，但我的感觉是犯低级错误的不是 JAVA ： 首先，在 Servlet 层就不应该考虑中文输出的问题，因为， 在 MVC 的设计模式中， Servlet 主要的角色是 Contrallor ， 所以，在这一层中，数据应该最好还是 Unicode 形式，在最 后让 Jsp 或者通过 xslt 做针对客户端浏览器的输出时，再需 要考虑本地字符

8、集编码的问题。作为一个标准的国际化应用， JAVA 应用的缺省编码方式不 应该是在 WEB 应用这一层设置的， 而是 JVM 根据系统缺省 编码方式根据操作系统的环境设置 （locale, 包括字符集，日 期格式等本地化环境 ）改变来实现。如何设置可以让 GNU/Linux 从系统层次就支持中文编码 （让 JVM 缺省的 file.encoding 就按照中文 GB2312 或者 GBK 进 行编码解码）呢？以上这篇文章发表在 2000 年年底， 当时的 GNU/Linux 的内 核是基于 glibc-2.1 开发的，而 GLIBC2.1 对中文的 locale 支 持还有限，因此，在 GNU

9、/Linux 上不能根据 locale 的设置 将系统缺省的编码方式变成 GB2312 ，从而改变 JVM 缺省的 编码方式。关于 GNU/Linux 对 l10n 的支持请看： GNU/Linux 程序员必读：中文化与 GB18030 标准。所以在 redhat6.x 下，无论你怎么设置 locale ，系统缺省的缺省 file.encoding 都是 ISO_8859_1 。在 redhat7.x 系统内核所基于的 glibc-2.2.x 对 l10n 有了更完 整的支持，所以可以通过设置LC_ALL=zh_CN.GB2312;export LC_ALL LANG=zh_CN.GB2312

10、;export LANG 让系统缺省的编码方式变成GB2312。JVM会根据系统的缺省编码方式设置系统的 file.encoding 属性。之后，应用中任 何字节流到字符流的转换， JVM 都会按照这一系统缺省编码 方式进行转换。因此在基于 glibc-2.2 以上的 GNU/Linux 上 是可以通过 locale 的设置来改变系统缺省的编码方式， 从而 改变上层 Java 应用的缺省编码、解码方式的。locale 设置对 JVM file.encoding 的影响可以我通过做过的一 个试验说明： hello_unicode.html由此可见：GNU/Linux 是依靠 GNU 的工具发展起

11、来的：没有 GNU 就 没有 GNU/Linux 。所以 GNU/Linux 对本地化的支持，也是 在核心的 glibc-2.2.x 对中文 locale 有了更好的支持以后才逐 步发展起来的。GNU/Linux 对国际化的支持远远落后于 WINDOWS SOLARIS 等商业操作系统： 2 年甚至更多。通过 web.xml 设置解决 URLEncoder.encode() 方法和系统 缺省编码方式相关的问题在我所理解的范围内， J2SE 1.3 中非常不符合 Java 的国际 化规范的是在使用 URLEncoder 的时候： 比如在中文 WIN98 上运行的应用，使用 URLEncoder.

12、encode(String s)时：比如“中文”这2 个字符直接被 Encoding 的话结果是 %3F%3F=? 。原因很简单，“中文”在ncode()过程中应该先按 GBK编码方式编码成 4 个字节( u00d6u00d0u00ceu00c4 )后再进行 URLEncoding 才是正确的。这个在 J2SE1.4 中也修正了。 方法 encode(String s) 已经不鼓励使用，取而代之的是除了 需要进行 URLEncoding 的字符串外，同时需要指定字符串 编码方式的 encode(String s, String enc) 。这样， URLEncoder 就可以和系统缺省的编码方

13、式无关了。在 J2SE1.3 下一个 WEB 应用如果有这个问题可以通过在WEB-INF/web.xml 中设置 character-encoding 来解决： .比如：产品是在中文 WINDOWS98 中运行，系统缺省字符 集是用 GBK ，则这个应用的 web.xml 需要设置成： .UniCode inside, Localization outsite以上 2 个方法仍然只是让应用更方便地本地化了，而应用本 身并不是真正的国际化应用。设想一下如何设计一个全球的 论坛系统：可以让中文和日文的用户都可以方便的浏览发表 呢？在数据中间处理阶段应该以那种字符集存储呢？答案 很简单： UniCo

14、de 。以前很多文章都有关于如何设计一个国 际化界面的介绍，只是应用的本地化界面输出，但很少提及 数据在中间处理过程中如何适应国际化。输入和存储阶段就用 UniCode 方式进行处理和存储， 以方便 应用以后的国际化。 GOOGLE 的设计就是一个非常好的国 际化应用榜样，我以 GOOGLE 搜索引擎的国际化支持为例 说明如何实现国际化应用的设计。GOOGLE 用户经常有这样的感觉：为什么我第一次去 GOOGLE ，出现的就是中文的界面？ 为什么在所有网站中查中文：有时候还会匹配到日文网站的 结果？比如： 就以 google 秘密 这个查询为例： 我们在输入 框输入 google 秘密 q=g

15、oogle+%C3%D8%C3%DC&btnG=Google%CB%D1% CB%F7&lr=首先我将 GOOGLE 对查询的处理流程简单的说明如下： 客户端浏览器输入； 查询字符串按客户端系统编码方式（ GBK ）转换成字节流， 并 URL Encode 后传给 GOOGLE ；GOOLGE 将输入的字符串 URL Decode 后，按照客户端的 系统编码方式将这个字符串（字节串）解码成 UniCode 查询过程，完全是基于 UniCode 的匹配过程，比如对于“中 文”这2 个字在简体繁体中文和日文里都有， 因此无论是何种 语言的页面包含这 2 个字的页面都能匹配上。 结果集输出：将查询结

16、果集的内容（ UNICODE ）按客户端 系统编码方式（ GBK ）“编码”成的字节流，返回给浏览器 具体说明：GOOGLE 如何识别出浏览器使用的“界面语言”： GOOGLE 获得这个查询字符串的同时，一般会根据 hl=zh-CN 这个参 数，知道了客户端使用的字符集编码方式，如果用户第一次 访问： GOOGLE 会根据浏览器的发送的请求中包含的Accept language: zh_cn 这个头信息来判别，这就是为什么 现在很多用户第一次去 GOOGLE 的时候它就能自动识别出 来的原因。 这个参数在之后的查询和翻页过程中通过 cookie 保存，并通过 get 方式一直传递给 GOOGL

17、E （因此你也可 以使用使用偏好设置界面语言） ，从而可靠地识别出客户端 的编码方式。GOOGLE 如何查询：也许从 URL 上你可以看到：传过去的“秘密”这个查询实际上是C3%D8%C3%DC= 秘密这2 个字按 GBK （WINDOWS 客户端缺省的编码方式）编码方 式的 4 个字节然后再 URLEncode 后的形式（关于中文编码 方式请参考：汉字的编码方式） ，GOOGLE 将查询字符串按 这个编码方式解码并转成 UniCode ，然后用这个 UniCode 编码方式的字符串进行内部的查询操作。而任何语言的页面 都是先转换成 UniCode 后存储在 GOOGLE 的数据索引库里 的。

18、在 UniCode 中日文和中文写法一样的字， 用的是同样的 编码。因此，如果你没有指定语言过滤的话，日文网页的结 果就首先被命中了；因此，对于中文客户端的查询：如果相 应字符在 UniCode 中和繁体， 日文映射的字一样， 就可以匹 配到相应的日文网页， 繁体中文网页 .，GOOGLE 的查询结 果也首先是 UniCode 的，最后将 UniCode 结果按照客户端 的编码方式转换成字节流，返回到客户端。从以上的分析中我们可以看出： UniCode 非常漂亮的解决了 应用的国际化问题。对于应用前端来说，剩下的工作就是根 据本地编码环境进行本地化的过程了。数据从输入的开始，就全部先转换成 UniCode ，然后再进行 处理，并按照 UniCode 方式集中存储 (UniCode