1          问题提出

现在很多网站项目开发要求同时支持多国语言，所以在用户界面及程序的设计和开发中需采取国际化策略，以达到代码改动量小、网站部署便利，用户群广泛的目的。

 

2          解决策略

.NET Framework 为开发全球通用的应用程序提供了广泛的支持。在开发全球通用的应用程序时，此过程分为三个步骤：全球化、本地化分析和本地化。

 

2.1          全球化

在这一步中将编写应用程序的可执行代码。一个真正的全球化应用程序应是非特定区域性和非特定语言的。因此，应集中精力创建能够支持适用于所有用户的本地化用户界面和区域数据的应用程序。注意，尽管全球化应用程序具有这种灵活性，但全球化过程本身并不涉及用户界面的翻译。相反，应致力于使创建的应用程序具有对来自应用程序所支持的所有区域性和地区的用户均有效的功能。

 

2.2       本地化分析

本地化分析是一个中间过程，用于验证全球化应用程序是否已准备好进行本地化。如果应用程序的可执行代码已经同应用程序的可本地化资源明显分开，则此应用程序就可以开始进行本地化。公共语言运行库的附属程序集资源模型完全支持这种代码同资源的分离。可执行代码位于应用程序的主程序集中，只有资源位于应用程序的资源文件中。

 

2.3       本地化

本地化是针对应用程序支持的每一个区域性将应用程序的资源翻译为本地化版本的过程。只有在完成了本地化分析步骤，证实了全球化应用程序可以开始进行本地化之后，才应继续到本地化阶段。

可以开始进行本地化的应用程序分为两个概念块：一个是包含所有用户界面元素的块，另一个是包含可执行代码的块。用户界面块仅包含非特定区域性的可本地化用户界面元素，如字符串、错误信息、对话框、菜单、嵌入的对象资源等。代码块仅包含由所有支持的区域性使用的应用程序代码。公共语言运行库支持一个附属程序集资源模型，该模型将应用程序的可执行代码同其资源分开。

要获取应用程序的每个本地化版本，可添加新的附属程序集（包含翻译成适当目标区域性语言的本地化用户界面块）。所有区域性的代码块应保持相同。用户界面块的本地化版本与代码块的组合产生应用程序的本地化版本。

 

3          国际化应用程序时应遵循的最佳做法

 

3.1       全球化最佳做法

1)       在内部使应用程序代码成为 Unicode。

2)       使用 System.Globalization 命名空间提供的区域性识别类来操作和格式化数据。

l         对于排序，使用 SortKey 类和 CompareInfo 类。

l         对于字符串比较，使用 CompareInfo 类。

l         对于日期和时间的格式化，使用 DateTimeFormatInfo 类。

l         对于数字的格式化，使用 NumberFormatInfo 类。

l         对于公历和非公历，使用 Calendar 类或特定 Calendar 实现之一。

3)       在适当的情况使用 System.Globalization.CultureInfo 类提供的区域性属性设置。使用 CultureInfo.CurrentCulture 属性来执行格式化任务，如日期和时间或数字的格式化。使用 CultureInfo.CurrentUICulture 属性检索资源。请注意，CurrentCulture 和 CurrentUICulture 属性可以基于每个线程来设置。

4)       通过使用 System.Text 命名空间中的编码类，使应用程序能够与各种编码相互进行数据读写。不要采用 ASCII 数据。假定在用户可以输入文本的任何位置都将提供国际字符。例如，在服务器名、目录、文件名、用户名和 URL 中接受国际字符。

5)       使用 UTF8Encoding 类时，由于安全原因，建议您使用此类提供的错误检测功能。要打开错误检测功能，请使用带有 throwOnInvalidBytes 参数的构造函数创建该类的实例，并将 throwOnInvalidBytes 的值设置为 true。

6)       尽可能将字符串按整个字符串处理，而不是按一系列个别字符处理。这在排序或搜索子字符串时尤为重要。这可以防止与分析组合字符有关的问题。

7)       使用 System.Drawing 命名空间提供的类来显示文本。

8)       为保持操作系统间的一致性，不要允许用户设置重写 CultureInfo。使用接受 useUserOverride 参数的 CultureInfo 构造函数，并将该参数设置为 false。

9)       在国际操作系统版本上使用国际数据来测试应用程序功能。

10)    如果安全决策基于字符串比较或大小写更改操作的结果，请通过显式指定 CultureInfo.InvariantCulture 属性执行不区分区域性的操作。这种做法确保结果不会受 CultureInfo.CurrentCulture 的值的影响。有关说明不区分区域性的字符串比较如何产生不一致结果的示例，请参见自定义大小写映射和排序规则。

 

3.2       本地化最佳做法

1)       将所有可本地化的资源移动到单独的纯资源 DLL 中。可本地化的资源包括用户界面元素，如字符串、错误信息、对话框、菜单以及嵌入的对象资源。

2)       不要对字符串或用户界面资源进行硬编码。

3)       不要将不可本地化的资源放在纯资源 DLL 中。否则会使翻译人员产生困惑。

4)       不要使用在运行时从串联词组生成的复合字符串。复合字符串难以本地化，因为它们往往采用英语语法顺序，而此顺序并不适用于所有语言。

5)       避免不明确的构造，如“Empty Folder”，因为根据字符串组成部分的语法规则，这些字符串可能产生不同的翻译。例如，“empty”既可以是一个动词，也可以是一个形容词，因此在诸如意大利语或法语等语言中就可能导致不同的翻译。

6)       避免在应用程序中使用包含文本的图像和图标。本地化这些图像和图标的成本是很大的。

7)       允许在用户界面中为字符串长度的扩展保留足够的空间。在某些语言中，词组可能另外需要百分之五十到百分之七十五的空间。

8)       数据库设计时为字符串类型字段的其他语言版本留够长度

9)       使用 System.Resources.ResourceManager 类根据区域性检索资源。

10)    安排进行专业本地化工作（翻译）。

 

3.3       ASP.NET 应用程序的全球化最佳做法

1)       在应用程序中显式设置 CurrentUICulture 和 CurrentCulture 属性。不要依赖于默认设置。

2)       请注意，ASP.NET 应用程序是托管应用程序，因此可以使用与其他托管应用程序相同的类，以根据区域性检索、显示和操作信息。

3)       注意在 ASP.NET 中可以指定以下三种编码类型：

l         requestEncoding 指定从客户端浏览器接收的编码。

l         responseEncoding 指定要发送到客户端浏览器的编码。在大多数情形下，这应与 requestEncoding 是相同的。

l         fileEncoding 指定用于 .aspx、.asmx 和 .asax 文件分析的默认编码。

4)       在 ASP.NET 应用程序中的以下三个位置指定 requestEncoding、responseEncoding、fileEncoding、culture 和 uiCulture 属性的值：

l         在 Web.config 文件的全球化一节中。此文件是 ASP.NET 应用程序的外部文件。有关更多信息，请参见 <globalization> 元素。

l         在页面指令中。请注意，当应用程序在页面中时，文件已经被读取。因此，指定 fileEncoding 和 requestEncoding 为时已晚。只有 uiCulture、Culture 和 responseEncoding 可以在页面指令中指定。

l         在应用程序代码中以编程方式指定。该设置可能随请求的不同而不同。同页面指令一样，到打开应用程序代码时，指定 fileEncoding 和 requestEncoding 为时已晚。只有 uiCulture、Culture 和 responseEncoding 可以在应用程序代码中指定。

5)       请注意，UICulture 可以设置为浏览器接受语言。