javascript国际化终极方法

    最近本人被如何使用在JSF中使用JAVASCRIPT框架的国际化资源问题一度困扰。国际化问题常常困扰着我们，特别是像我这样在使用jsf的同行们，在这里跟大家探讨一下如何更好实现项目的国际化。
    jsf在发布的时候就已经充分考虑了国际化的实现，其实现方法是将国际化部分从页面中分离出去单独实现，jsf页面最好只保留iso-8859-1编码格式的页面代码，由于存在这样的缺省情况，编辑器不使用其他代码来编辑JSF页面是正确的，只是对于我们这些母语不是西文的中国同行带来了一些不变，所以网上有许多关于如何在页面上直接实现中文支持的方法，多不太理想，也许不知道什么时候又会重新出现不支持的问题。我个人不认为突破jsf原有的国际化方案是明智的选择，既然采用jsf就尽量采用规范的做法，基本不会出问题。
    也许大家对jsf的国际化可能比较熟悉了，这里我简略的说一下。
    国际化缩写为"il8n",jsf使用Java的国际化处理方式：使用ResourceBundle
    首先创建ResourceBundle文件，例如我们的项目需要国际化，创建一个名为"test.bundle1"的国际化资源文件，其实是一组文件，包括一个缺省资源文件以及各个语言版本的资源文件，各国的资源文件由该国文字书写，然后经由工具native2ascii(或者IDE的相关插件)把各个语言资源文件转换为统一的Unicode的编码字串，例如“密码修改”编码输出显式的编码字符串"\u66F4\u6539\u8D26\u6237"，jsf根据客户端的本地格式选配相应的资源文件嵌入页面。
    这些Unicode编码字符串可以被所有通用的浏览器支持，不管你的原始页面使用什么代码写的，混合其中Unicode编码总可以被正确解释，包括在javascript中的Unicode编码文字。
    最近想在客户端直接使用javascripe，以提高项目的用户体验，为此选用了一些框架，例如jquery、dojo等都遇到国际化问题，一直未能解决，致使开发停滞不前。这些框架应该讲国际化还是做得不错的，国际化资源均是UTF-8编码的，在许多情况下没有问题，但是通过jsf容器发布出去就遇到了iso-8859-1编码问题，页面以iso-8859-1的编码读UTF-8的javsscript资源文件肯定是乱码啦。
    找出原因以后，参照jsf国际化的原理处理同样可以将javascript国际化问题完善解决掉。以dojo为例，它的资源文件均是UTF-8的，使用
  

native2ascii -encoding UTF-8 in.js out.js

可以转换单个文件，使用ant脚本可以批量处理
   

<target name="native2ascii">
	   <native2ascii encoding="UTF-8" src="E:\dojo\dojo-release-1.1.0" dest="E:\dojo\native"
	    includes="**/*.js" />
	  </target>

    希望浏览本文的各位仁兄可从中获益。

评论

6 楼 xinxian 2012-11-12  

bs lz，哎……

5 楼 thinkintime 2008-10-14  

看不出终极在哪,LZ以后不要把标题搞得那么大好不好

4 楼 xxqn 2008-09-09  

本文讨论的不是本地化，而是国际化，融合dojo的国际化以及jsf国际化的内容以更加方便使用。

3 楼 mike98 2008-09-04  

老兄，你这是本地化，不是国际化，只能中文用了，英文或其它文字又怎么办呢？

2 楼 xxqn 2008-04-15  

采用dojo 这样的javacript框架，里面有许多器件都是已经国际化了的，拿来使用必然存在国际化问题，我们不可能另外重写一套方案来替代框架提供的国际化方案，这样成本太高了，也不现实。
javacript有其固有的效率问题，其实java的国际化也同样有效率问题，只是Java效率比javascript高许多而已，提供的方案也比较统一规范，所以我们不太感觉性能问题。
dojo在使用中确实还存在着许多问题，我现在也只是正在学习阶段，还不能给出太多评价。不过javascript框架可以充分利用客户端的cpu资源，只要客户端浏览器能够承受就应该没问题，优点是大大减少网络数据传输，减小服务器端的压力，对于大型分布式网络系统应用应该更加有利的。
另外dojo性能应该比ext好。

1 楼 jelly 2008-04-15  

我们的项目没有用js做国际化，而是用java的国际化。js的国际化会不会有效率的问题，使用dojo之后的效率问题好令人头疼啊！