最近本人被如何使用在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>
希望浏览本文的各位仁兄可从中获益。
