使用 Ajax 实现本地化后的客户端消息验证（1）简介及关键字

look_w

简介在构建一个能影响全球用户的 Web 应用程序时，有两点需要考虑。第一点是需要呈现本地化后的页面内容，第二点是验证用户输入以及本地化后的验证消息显示。
使用资源包（特定于本地语言环境的属性文件）在服务器端构建此页面的本地化版本很容易。同样地，也可以使用服务器端验证来显示本地化后的验证消息。对于国际化而言，有很多具备良好支持的现成框架可用，比如                Jakarta Struts、Spring、Tapestry 和 Freemarker。不过，在几乎所有的这类框架内，都缺少对在客户端验证本地化消息的现成支持。
如果验证是在客户端进行的，将很难显示本地化后的验证消息。通过在构建页面时提前处理整个页面（包括静态内容和必要的 JavaScript 验证消息）或从特定于本地语言环境的资源包解析出消息键，可以显示这些消息。不过，上述方式具有一个暗含的限制：整个 JavaScript 验证逻辑都应在 JavaServer Page (JSP) 本身内编写以便基于 Java™ 的消息键解析逻辑可被重用。不要忘记，JavaScript                通常都是由页面设计人员编写的，而这些设计人员并不一定同时也掌握 Java 的开发技术。混合 Java 代码和 JavaScript 可能会让 Web 应用程序的开发和维护复杂化。
联合使用 Ajax 和资源包是另一种可以简化工作的方式。它让您能将此验证                JavaScript 移到另一个文件，而不是 JSP。并且，只对需要的消息键进行解析，而不是像使用预先构造的本地化版本方法一样，对所有消息键进行解析。
本文描述了如何联合使用 Ajax 和资源包来简化本地化后的客户端验证消息处理。我将侧重于使用 Ajax 的强大功能，而不会涉及现成框架的复杂性。本文所介绍的方式非常适合于需要快速响应的 Web 2.0 应用程序，比如动态跟踪用户动作。
在本文中，我不会过多涉及 JSP 页面内静态 HTML 内容的本地化。本文所侧重的是联合使用 Ajax                 和资源包来实现本地化后的客户端验证消息处理。不过，用来在服务器端解析消息键的 Java 实用工具也可用于本地化 JSP 页面内的静态 HTML 内容。
关键字国际化（Internationalization）— 指一种应用程序设计过程，使应用程序不需要进行重大修改就可适用于各种语言和地区。有时，国际化这一术语常被缩写为 i18n，因为在首字母 “i” 和最后一个字母                “n” 之间共有 18 个字母。
本地化（Localization）— 针对某个特定地区或语言调整软件的过程，添加特定于本地语言环境的组件和经过翻译的文本。本地化这一术语常被缩写为 l10n，这是因为在字母 “l” 和 “n” 之间共有 10 个字母。本地化的首要任务是翻译用户界面元素和文档。本地化所涉及的不仅是互换语言，而且还会涉及更改相关元素，比如数字、日期、货币等的显示。其他类型的数据（比如声音和图像）若对文化敏感，可能也都需要进行本地化。应用程序的国际化越好，越容易针对特定的语言和字符编码模式对其进行本地化。
Ajax 是一种技术，用来创建更好、更快且更为交互的 Web 应用程序。借助 Ajax，JavaScript 代码可使用 XMLHttpRequest 对象与服务器直接通信。有了此对象，JavaScript 代码可以在不重新装载页面的情况下与 Web 服务器进行数据交换。