从汉化到国际化

参考文献：从汉化到国际化
http://www.chedong.com/tech/unicode_java.html

一、Java对输入输出首先有一个“字节流”到“字符流”之间的编码/解码过程，这个设置是根据系统配置决定的，为什么PHP之类的应用很少有字符集问题而Java有很好的国际化机制，却经常出现乱码问题呢？

简单的举例：
有一个包含“你好”这2个中文字的文件实际上是4个字节组成的：C4 E3 BA C3
在英文操作系统中缺省的编码解码方式是缺省编码方式是ISO8859，所以直接从文件中读取的结果是4个的字节，按ISO8859解码后在程序中操作的是4个Java字符，虽然每个JAVA字符是16位Unicode，但每个字符仍是8位字节的映射/u00C4/u00E3/u00BA/u00C3，因此处理的仍是“英文”。而显示过程中，是浏览器将字节流正确的显示成了相应的中文。

而一个Java应用在GBK编码方式的操作系统中，直接从文件中读取4个的字节后，按GBK方式解码后是2个16位的Java字符/u4F60/u597D，每个字都是相应Unicode的CJK区块所对应的中文。

这也就是为什么在php等应用很少出字符集问题的原因：
（１）在服务器端环境缺省一般是英文（ISO8859-1），等于全部处理使用的都是按字节方式处理的。数据输入输出过程中编码方式完全不被改动，因此乱码问题很少出现。
（２）而Java实际上提供了把每个中文直接当成1个“字”而不是2个字节处理的机制，主要的乱码问题往往是输入输出时编码解码方式不一致造成的。而且通过Unicode机制，程序除了实现程序界面根据本地化的适应外，甚至程序处理的内容本身的在不同字符集的操作系统中也是可以通用的，比如：在繁体中文操作系统中编辑的内容，在简体中文操作系统中也能正常的查询。

二、从汉化到国际化

汉化：产品是在中文WINDOWS98中运行，系统缺省字符集是用GBK，则这个应用的web.xml需要设置成：
<web-app character-encoding="GBK">
...
</web-app>

以上2个方法仍然只是让应用更方便地本地化了，而应用本身并不是真正的国际化应用。

设想一下如何设计一个全球的论坛系统：可以让中文和日文的用户都可以方便的浏览发表呢？在数据中间处理阶段应该以那种字符集存储呢？答案很简单：UniCode。以前很多文章都有关于如何设计一个国际化界面的介绍，只是应用的本地化界面输出，但很少提及数据在中间处理过程中如何适应国际化。

国际化：

输入和存储阶段就用UniCode方式进行处理和存储，以方便应用以后的国际化。GOOGLE的设计就是一个非常好的国际化应用榜样，我以GOOGLE搜索引擎的国际化支持为例说明如何实现国际化应用的设计。

GOOGLE用户经常有这样的感觉：

1. 为什么我第一次去GOOGLE，出现的就是中文的界面？
2. 为什么在所有网站中查中文：有时候还会匹配到日文网站的结果？比如：就以"google 秘密"这个查询为例：我们在输入框输入"google 秘密"
   http://www.google.com/search?hl=zh-CN&newwindow=1&q=google+%C3%D8%C3%DC&btnG=Google%CB%D1%CB%F7&lr=

首先我将GOOGLE对查询的处理流程简单的说明如下：

1. 客户端浏览器输入；
2. 查询字符串按客户端系统编码方式（GBK）转换成字节流，并URL Encode后传给GOOGLE；
3. GOOLGE将输入的字符串URL Decode后，按照客户端的系统编码方式将这个字符串（字节串）解码成UniCode
4. 查询过程，完全是基于UniCode的匹配过程，比如对于“中文”这2个字在简体繁体中文和日文里都有，因此无论是何种语言的页面包含这2个字的页面都能匹配上。
5. 结果集输出：将查询结果集的内容（UNICODE）按客户端系统编码方式（GBK）“编码”成的字节流，返回给浏览器

具体说明：

• GOOGLE如何识别出浏览器使用的“界面语言”：GOOGLE获得这个查询字符串的同时，一般会根据hl=zh-CN这个参数，知道了客户端使用的字符集编码方式，如果用户第一次访问：GOOGLE会根据浏览器的发送的请求中包含的Accept language: zh_cn这个头信息来判别，这就是为什么现在很多用户第一次去GOOGLE的时候它就能自动识别出来的原因。这个参数在之后的查询和翻页过程中通过cookie保存，并通过get方式一直传递给GOOGLE（因此你也可以使用使用偏好设置界面语言），从而可靠地识别出客户端的编码方式。
• GOOGLE如何查询：也许从URL上你可以看到：传过去的“秘密”这个查询实际上是%C3%D8%C3%DC=>"秘密"这2个字按GBK（WINDOWS客户端缺省的编码方式）编码方式的4个字节然后再URLEncode后的形式（关于中文编码方式请参考：汉字的编码方式），GOOGLE将查询字符串按这个编码方式解码并转成UniCode，然后用这个UniCode编码方式的字符串进行内部的查询操作。而任何语言的页面都是先转换成UniCode后存储在GOOGLE的数据索引库里的。在UniCode中日文和中文写法一样的字，用的是同样的编码。因此，如果你没有指定语言过滤的话，日文网页的结果就首先被命中了；因此，对于中文客户端的查询：如果相应字符在UniCode中和繁体，日文映射的字一样，就可以匹配到相应的日文网页，繁体中文网页...，GOOGLE的查询结果也首先是UniCode的，最后将UniCode结果按照客户端的编码方式转换成字节流，返回到客户端。

从以上的分析中我们可以看出：UniCode非常漂亮的解决了应用的国际化问题。对于应用前端来说，剩下的工作就是根据本地编码环境进行本地化的过程了。

1. 数据从输入的开始，就全部先转换成UniCode，然后再进行处理，并按照UniCode方式集中存储(UniCode inside)
2. 数据输出过程中，只是在最后输出到客户端的时候，按照客户端的本地化设置将UniCode数据转换成本地字符集，并配以相应语言/字符的界面(Localization outside)

如果应用的开发只是满足于在国内市场自给自足，“汉化”的思路的大量出现是很自然的。但要是把“汉化”比作UCDOS和RichWin的话，那么这种汉化方式迟早要被内核汉化的WIN95淘汰的。毕竟核心级别对国际化的支持才是一个真正简化前端应用设计、通用的解决方案。Microsoft和Sun等国际化大公司的产品从一开始就是为全球市场设计的，因此对国际化的支持一致非常重视。相比之下国内软件行业对相应国际标准显然重视不足，也很少积极地参与相关标准制定。