Java国际化基础知识

Java国际化基础知识JoeSamShirah,负责人和开发人员,conceptGO2002年6月18日本教程向您介绍了Java编程语言对多语言和多国环境的支持。教程从对国际化原理和概念的一般性讨论开始，然后对Java国际化支持的特定领域做了一个概述。最后几节提供了更具实践性的讨论，这些讨论针对的是任何国际化Java应用程序的基本领域：Unicode与Java字符；语言环境与资源束以及格式化日期、数字和货币。简介国际化同计算机编程有关的国际化是设计和编写应用程序以便可以在全球或多国环境中使用的过程。国际化程序能够支持不同的语言以及不同格式的日期、时间、货币和其它值，而无须软件修改。这通常涉及“软编码”或将文本组件同程序代码分离并且可能涉及可插入代码模块。从业者通常将国际化（internationalization）简写为I18N。原因是internationalization一词开始的I和最后的N之间有18个字母。试着多说、多写“internationalization”一词几次，您就会欣赏这个较短版本的价值。此外，您可能会看到“I18N'ed”作为“国际化的（internationalized）”的缩写形式。虽然这在语法上不准确，在技术上也不正确，但是“I18N'ed”很有用，您将在包括本教程在内的文献里经常看到它。关系数据库管理系统和操作系统可能也对国际化的某些方面提供基本支持，通常使用术语“本地语言支持（NationalLanguageSupport）”或NLS来表示。本地化本地化是设计和编写能够处理特定区域、国家或地区、语言、文化、企业或政治环境的应用程序的过程。从某种意义上说，为特定地区编写的所有应用程序都本地化了，虽然这些应用程序大多数只支持一种语言环境。然而，真正的本地化通常是由访问语言环境、位置、政治或其它特定组件和模块的核心代码，以及将文本翻译成适合于用户的版本来实现的。适当国际化的程序使本地化更为便利，并为本地化提供了基础。与将“internationalization”缩写成“I18N”相同的原因和逻辑，本地化（localization）通常缩写为L10N。可以将处理多个国家或地区（比如说美国、加拿大、墨西哥和巴西）的税收或会计软件包国际化，使得无需对每个国家或地区重复定制显示、报表生成和其它程序。然后本地化该软件包以处理适合于特定国家或地区甚至可能是州或省的不同会计和报表生成过程。I18N存在的理由（I18Nraisond'etre）这一页的标题本身就为国际化提供了一个理由：没有接触过“I18N”或不懂法语（raisond'etre的大致意思是“存在的理由”）的人将搞不清这一节是关于什么的。有时，缺乏知识是一个优点，这可以由人造钻石的成功来证明。然而，如果软件不能被人理解，那么不论开发人员多么陶醉于自己的智慧，它也是无用的。不便或惹人生气的软件用处也不大，不适于销售。最开始时使用ASCII。直至今日，大多数编译器仍要求ASCII输入。随着计算机的发展，需要额外的语言支持已为人们所公认，通常包含ASCII和本地语言的特定于国家或地区的字符集也随操作系统一起提供。即便如此，一般也只支持一种“其它”语言，大多数开发人员都根据他们自己的国家和当地文化来设计程序。由于历史和实际的原因，因特网和Web上的应用程序，通常遵循相同的模式。虽然重点通常在英语语言上，但是很容易找到各种单语言应用程序和网站。另外一个考虑是经济上的；在您的国家之外存在着巨大的市场。随着那些以前贫穷的国家或地区GNP的增长，对计算机的广泛接受以及上网人口的增加，市场正在改变。根据GlobalReach的全球因特网统计信息（GlobalInternetStatistics）页面提供的信息，到2001年12月，大约45%的因特网人口讲英语。接下来是日语，大约占9%，紧随其后的顺序是中文、德语、西班牙语、韩国语、意大利语、法语以及其它语言。假定计算机访问跟踪类似的比例是合理的。虽然从2001年到2005年在线人口预期会翻一翻（在线商业预计从大约1万亿美元增长到6万亿美元），但整体讲英语的比例预期会持续下降到39%左右。其它关注国际化问题的理由可能更接近于自身的利益：您的公司可能在其它国家或地区开设办事处，或者从位于另外一个国家或地区的潜在客户收到一个投标请求（RequestForProposal(RFP)）。Java平台I18N支持概述国际化和Java编程语言和大多数使用其它语言的程序员不同，Java程序员是大量构建在JDK中提供I18N支持的标准代码的受益者。大部分代码最初来自IBM的Taligent子公司（自从合并进IBM以后），代表了许多人年的工作成果，比大多数公司独自在其产品中提供的代码要切实可行得多。这些代码及其远见并不总是完美的；例如，请看一下java.util.Date类中许多弃用的（deprecated）方法。我们中的许多人可能记得太平洋标准时间（PacificStandardTime）显然也是Java世界时间（JavaWorldTime）。然而，即使在“错误的旧时代”，其它语言也没有能与这种内置的功能匹敌的东西，即便有，也很少。这一节的页面简要地讨论了Java平台支持的一般国际化领域。Unicode支持Java语言字符集是Unicode，而且相应地，原始char数据类型的长度是两个字节（16位），以容纳Unicode值。由于大家熟悉的String由char组成，因此String也是基于Unicode的。Unicode本身是这样定义的：值0到127匹配标准ASCII，0到255匹配ISO8859-1(Latin-1)标准。由于这一起始值的一致性，不使用I18N功能或不需要面对I18N问题的程序员可以编写他们的Java程序而无需理解或知道Unicode。然而，考虑到Windows的普遍使用，该平台的程序员应该知道标准ISO8859-1和WindowsLatin-1(cp1252)之间的差异。16位char长度允许0到65535之间的值。提供了Unicode转义以在本地平台不支持实际字符时仍然允许输入。其格式是“\u”后跟0000到FFFF的四个十六进制数字。例如，下面两行代码是等价的：charc1='a';charc2='\u0061';JDK/JRE的1.3版本支持Unicode2.1；1.4版本支持Unicode3.0。更多关于Unicode和称为UniBook的Unicode显示程序的信息，请参阅参考资料中到UnicodeConsortium的链接字符集转换和流输入／输出上一页提到过Java字符集是Unicode，但并不是所有平台都支持Unicode。那么，这个戏法是怎么完成的呢？答案是：所有支持字符的输入和输出流―即java.io.Reader和java.io.Writer层次结构―自动调用在平台的本地编码和Unicode之间执行转换的隐藏代码层。请注意，本地编码是假设的。如果数据不是缺省编码的，您将不得不自己转换数据。幸运的是，java.io.InputStreamReader、java.io.OutputStreamWriter和java.lang.String类具有允许使用受支持的编码的转换规范的方法。您可以在JDK文档（可以从参考资料访问）的Internationalization节中的SupportedEncodings下面找到它们。请注意，JDK1.4现在对泰国语和印地语提供支持。有趣的是，Java对数字的大尾数格式提供保证，而对于char数据类型却不支持这一保证。缺省格式同平台有关。例如，在NT4.0上，系统特性“sun.io.unicode.encoding”被设置成“UnicodeLittle”。如果因为某种原因您想自己指定该格式，那么您可以根据文档来选择UnicodeBig、UnicodeBigUnmarked、UnicodeLittle、UnicodeLittleUnmarked、UTF8或UTF-16。字符分类与Character类除了以标准方式为多种语言定义字符之外，Unicode也为每个字符定义了几个特性。这些特性标识诸如一般类别、双向性、大写、小写以及该字符是数字还是控制字符等事情。在可以从UnicodeConsortium网站上获得的UnicodeData文件中定义了这些特性。JavaCharacter类提供获取这些特性的方法。虽然特定实例是不变的，但是许多方法是静态的，允许实时访问字符的特性。该类有用性的一个示例来自一个典型的ASCII编程算法：许多程序员利用了这样一个事实，如果字符值在0x41和0x5A之间，那么它是大写字母（A-Z）。加上0x20，您就得到小写字母（a-z）。遗憾的是，如果处理的语言包含有超出ASCII范围的字符时，该算法会失效。解决方案是使用Character.isUpperCase()和Character.toLowerCase()，它们在任何情况下都起作用。另外一个示例是Character.isDigit()，它也用于表示ASCII‘0’到‘9’以外的数字的字符语言环境在Java语言中，语言环境（locale）仅仅是一个标识符，而不是一组本地化的属性。java.util.Locale类的一个实例表示一个特定的地理政治区域，使用表示语言、区域以及国家或地区的参数创建。每个与语言环境相关的类都维护着它自己的一组本地化属性，并且确定如何对含有Locale参数的方法请求做出响应。按照以前的陈述，很明显，没有关于程序员可能怎样对含有Locale参数的方法请求做出响应的约束。然而，在Sun的参考Java2平台和其它一致实现中，有一组一致的受支持的本地化实现。更多信息，请参阅JDK文档（可以从参考资料访问）中的Internationalization一节中SupportedLocales。应该注意，该文档将多种语言环境列为“也提供了，却未测试（alsoprovided,butnottested）”。我个人看见这一“未测试”问题出现在JDK1.3.1中的Finnish(fi_FI)语言环境；买主自行当心。AWT/SwingName和Locale属性java.awt.Component类包含Name和Locale属性的读方法和写方法。虽然文档也讨论了Component的构造器及其使用Name参数的子类，但我显然需要倍加小心，因为我以前从未找到它们。Component位于大多数Swing类的层次结构中，它们也自动支持这些属性。Name属性是一个您可以通过编程进行赋值的不可本地化的String。这有助于国际化―听起来可能有些奇怪，但是随着大多数数据根据语言环境改变时，Name提供了一个标识组件的设置锚点。当然，在一个给定的类里，为对象等同性测试对象引用可以达到相同的目的。虽然每种技术都有极好的理由，但我通常在actionPerformed()方法中使用对象等同性测试，如同您在代码示例中看到的那样。文档声明：如果不通过编程设置Name，那么将赋予一个缺省值，但不给出值或模式。在我编写的代码中，如果在调用Component.setName(aName)之前调用了Component.getName()，它将返回null。当然，作为未在文档中记录的行为，结果可能不一致，并且可能会在将来发生改变。因此，当将使用Name属性时，良好的编程实践要求将所有组件的Name属性设置成标准值（也就是“取消设置”），然后适当地设置想要的组件。Locale属性允许组件跟踪它自己的语言环境，即便是应用程序的其余部分正在使用不同的语言环境。在某些情况下，该项技术非常有用，虽然对于具有文本值的Component，可以在将文本发送给Component之前对它执行本地化，而无需设置特定的ComponentLocale。本地化的资源java.util.ResourceBundle是一个为存储和定位由应用程序使用的资源提供机制的抽象类。资源通常是本地化的String，但也可以是任何Java对象。ResourceB