NET开发多语言版应用程序--编码与本地化

一、简介

         .NET Framework 为开发全球通用的应用程序提供了广泛的支持。在开发全球通用的应用程序时，建议将此过程分为三个步骤：全球化、本地化分析和本地化。
          全球化
          全球化是全球通用应用程序创建过程的第一步。在这一步中将编写应用程序的可执行代码。一个真正的全球化应用程序应是非特定区域性和非特定语言的。
          因此，应集中精力创建能够支持适用于所有用户的本地化用户界面和区域数据的应用程序。
          全球化是设计和开发支持针对多个区域性用户的本地化用户界面和区域数据的应用程序的过程。
          在 .NET Framework 中，CultureInfo 类表示有关特定区域性的信息。这些信息包括书写系统、正在使用的日历、日期和时间格式化约定、数字和货币约定以及排序规则。
          System.Globalization 命名空间包含定义区域性相关信息的类，这些信息包括语言，国家/地区，正在使用的日历，日期、货币和数字的格式模式，以及字符串的排序顺序。使用这些类可以简化开发全球通用应用程序的过程。通过将表示当前区域性的 CultureInfo 对象传递给此命名空间中的方法，可以为当前用户的区域性启动一组正确的规则和数据。
          本地化分析 
          在继续进行本地化之前，应执行中间检查以确定应用程序的 本地化分析.
          如果应用程序可本地化，说明已正确地将应用程序的可执行代码同其资源分开。如果正确地评估了应用程序的可本地化性，在本地化期间就不需要修改应用程序的源代码。
          本地化分析是一个中间过程，用于验证全球化应用程序是否已准备好进行本地化。如果应用程序的可执行代码已经同应用程序的可本地化资源明显分开，则此应用程序就可以开始进行本地化。公共语言运行库的附属程序集资源模型完全支持这种代码同资源的分离。可执行代码位于应用程序的主程序集中，只有资源位于应用程序的资源文件中。有关实现此模型的详细信息
          如果在设计和开发应用程序时考虑了本地化，则此阶段就是保证质量的关口。否则，在此阶段，您将在源代码中发现并修复妨碍本地化的错误。不应到了开始进行本地化时才不能不修改任何源代码。执行本地化分析检查有助于确保本地化过程不会将任何功能上的缺陷引入应用程序。
          本地化 
          生成全球通用的应用程序的最后一步是 本地化，在这一步中，需要针对特定的区域性或地区自定义应用程序。如果已正确执行了全球化和本地化分析这两个步骤，则本地化主要包括用户界面的翻译。
 本地化是针对应用程序支持的每一个区域性将应用程序的资源翻译为本地化版本的过程。只有在完成了本地化分析步骤，证实了全球化应用程序可以开始进行本地化之后，才应继续到本地化阶段。
 可以开始进行本地化的应用程序分为两个概念块：一个是包含所有用户界面元素的块，另一个是包含可执行代码的块。用户界面块仅包含非特定区域性的可本地化用户界面元素，如字符串、错误信息、对话框、菜单、嵌入的对象资源等。代码块仅包含由所有支持的区域性使用的应用程序代码。公共语言运行库支持一个附属程序集资源模型，该模型将应用程序的可执行代码同其资源分开。

二、CultureInfo 类

          CultureInfo 类包含区域性特定的信息，如与特定区域性关联的语言、国家/地区、日历以及区域性约定。
          该类还提供执行区域性特定的操作（如大小写转换、格式化日期和数字以及比较字符串）所需的信息。                  
         示例代码:

using  System;
using  System.Data;
using  System.Configuration;
using  System.Web;
using  System.Web.Security;
using  System.Web.UI;
using  System.Web.UI.WebControls;
using  System.Web.UI.WebControls.WebParts;
using  System.Web.UI.HtmlControls;
using  System.Globalization;
using  System.Threading;
public   partial   class  _Default : System.Web.UI.Page
... {
    float f = 50.50f;
    protected void Page_Load(object sender, EventArgs e)
    ...{
        //获取服务器所有可用的本地化环境。
        foreach (CultureInfo ci in CultureInfo.GetCultures(CultureTypes.FrameworkCultures))
        ...{
            try
            ...{
                Response.Write(ci.NativeName + ":" + ci.Name + ":" + f.ToString("C", ci.NumberFormat) + "<BR>");
            }
            catch ...{ };
        }
        /**/////显示当前的本地化设置
        //Response.Write(Page.Culture);
        //Response.Write(f.ToString("C"));
        //设置本地的区域性
        //Thread.CurrentThread.CurrentCulture = new CultureInfo("zh-CN");
        if (!Page.IsPostBack)
        ...{
            bindData();
        }

    }
    private void bindData()
    ...{
        ddlCulture.DataSource = CultureInfo.GetCultures(CultureTypes.FrameworkCultures);
        ddlCulture.DataValueField = "Name";
        ddlCulture.DataTextField = "NativeName";
        ddlCulture.DataBind();
    }
    protected void btnChange_Click(object sender, EventArgs e)
    ...{
        if (ddlCulture.SelectedIndex > -1)
        ...{

            CultureInfo ci = new CultureInfo(ddlCulture.SelectedValue);
            txtShow.Text = f.ToString("C", ci.NumberFormat);
        }
    }
}

 

三、区域性

          区域性通常分为三个集合：固定区域性、非特定区域性和特定区域性。 区域性有层次结构，即特定区域性的父级是非特定区域性，而非特定区域性的父级是固定区域性。
          固定区域性:固定区域性不区分区域性。可以使用空字符串 ("") 按名称或者按其标识符来指定固定区域性。
          非特定区域性:与某种语言关联但不与国家/地区关联的区域性
          特定区域性:特定区域性是与某种语言和某个国家/地区关联的区域性
          例如，“fr”是非特定区域性，而“fr-FR”是特定区域性。
          只能为固定区域性或特定区域性创建 DateTimeFormatInfo 或 NumberFormatInfo，而不能为非特定区域性创建它们

四、Unicode编码

          .NET Framework 使用 Unicode UTF-16（Unicode 转换格式，16 位编码形式）来表示字符。在某些情况下，.NET Framework 在内部使用 UTF-8。
         “Unicode 标准”是用于字符和文本的通用字符编码方案。它为世界上的书面语言中使用的每一个字符赋予一个唯一的数值（称为码位）和名称。例如，字符“A”由码位“U+0041”和名称“LATIN CAPITAL LETTER A”表示。有 65,000 个以上的字符有值，并且还有再支持多达一百万个字符的余地。有关更多信息，请参见位于 www.unicode.org 的 Unicode Standard（Unicode 标准）。
         以往，不同区域性的不同语言要求迫使应用程序在内部使用不同的编码方案表示数据。这些不同的编码方案迫使开发人员为操作系统和应用程序创建零碎的基本代码，如用于欧洲语言的单字节版本、用于亚洲语言的双字节版本以及用于中东语言的双向版本。这种零碎的代码库使得难以在不同的区域性之间共享数据，并且对于开发支持多语言用户界面的全球通用应用程序来说尤为困难。
         Unicode 数据编码方案简化了开发全球通用应用程序的过程，因为它允许用单个编码方案来表示世界上使用的所有字符。应用程序开发人员不必再跟踪用于产生特定语言字符的编码方案，并且数据可以在世界上的各系统之间共享而不会受到损坏。

五、开发全球通用应用程序的最佳做法

          全球化最佳做法
          1、在内部使应用程序代码成为 Unicode。
          2、使用 System.Globalization 命名空间提供的区域性识别类来操作和格式化数据。 
          3、对于排序，使用 SortKey 类和 CompareInfo 类。
          4、对于字符串比较，使用 CompareInfo 类。
          5、对于日期和时间的格式化，使用 DateTimeFormatInfo 类。
          6、对于数字的格式化，使用 NumberFormatInfo 类。
          7、对于公历和非公历，使用 Calendar 类或特定 Calendar 实现之一。
          8、在适当的情况使用 System.Globalization.CultureInfo 类提供的区域性属性设置。使用          CultureInfo.CurrentCulture 属性来执行格式化任务，如日期和时间或数字的格式化。使用 CultureInfo.CurrentUICulture 属性检索资源。请注意，CurrentCulture 和 CurrentUICulture 属性可以基于每个线程来设置。
          9、通过使用 System.Text 命名空间中的编码类，使应用程序能够与各种编码相互进行数据读写。不要采用 ASCII 数据。假定在用户可以输入文本的任何位置都将提供国际字符。例如，在服务器名、目录、文件名、用户名和 URL 中接受国际字符。
          10、使用 UTF8Encoding 类时，由于安全原因，建议您使用此类提供的错误检测功能。要打开错误检测功能，请使用带有 throwOnInvalidBytes 参数的构造函数创建该类的实例，并将 throwOnInvalidBytes 的值设置为 true。 
          11、尽可能将字符串按整个字符串处理，而不是按一系列个别字符处理。这在排序或搜索子字符串时尤为重要。这可以防止与分析组合字符有关的问题。
          12、使用 System.Drawing 命名空间提供的类来显示文本。
          13、为保持操作系统间的一致性，不要允许用户设置重写 CultureInfo。使用接受 useUserOverride 参数的 CultureInfo 构造函数，并将该参数设置为 false。
          14、在国际操作系统版本上使用国际数据来测试应用程序功能。
          15、如果安全决策基于字符串比较或大小写更改操作的结果，请通过显式指定 CultureInfo.InvariantCulture 属性执行不区分区域性的操作。这种做法确保结果不会受 CultureInfo.CurrentCulture 的值的影响。有关说明不区分区域性的字符串比较如何产生不一致结果的示例，请参见自定义大小写映射和排序规则。
          本地化最佳做法
          1、将所有可本地化的资源移动到单独的纯资源 DLL 中。可本地化的资源包括用户界面元素，如字符串、错误信息、对话框、菜单以及嵌入的对象资源。
          2、不要对字符串或用户界面资源进行硬编码。
          3、不要将不可本地化的资源放在纯资源 DLL 中。否则会使翻译人员产生困惑。
          4、不要使用在运行时从串联词组生成的复合字符串。复合字符串难以本地化，因为它们往往采用英语语法顺序，而此顺序并不适用于所有语言。
          5、避免不明确的构造，如“Empty Folder”，因为根据字符串组成部分的语法规则，这些字符串可能产生不同的翻译。例如，“empty”既可以是一个动词，也可以是一个形容词，因此在诸如意大利语或法语等语言中就可能导致不同的翻译。
          6、避免在应用程序中使用包含文本的图像和图标。本地化这些图像和图标的成本是很大的。
          7、允许在用户界面中为字符串长度的扩展保留足够的空间。在某些语言中，词组可能另外需要百分之五十到百分之七十五的空间。
          9、使用 System.Resources.ResourceManager 类根据区域性检索资源。
          10、使用 Microsoft Visual Studio 2005 创建 Windows 窗体对话框，以便可以使用 Windows 窗体资源编辑器 (Winres.exe) 对它们进行本地化。不要对 Windows 窗体对话框进行手动编码。
          11、安排进行专业本地化工作（翻译）。
          12、有关创建和本地化资源的完整说明，请参见应用程序中的资源和使用 .NET Framework SDK 教程的资源和本地化。
          ASP.NET 应用程序的全球化最佳做法
          在应用程序中显式设置 CurrentUICulture 和 CurrentCulture 属性。不要依赖于默认设置。
          请注意，ASP.NET 应用程序是托管应用程序，因此可以使用与其他托管应用程序相同的类，以根据区域性检索、显示和操作信息。
          注意在 ASP.NET 中可以指定以下三种编码类型： 
           requestEncoding 指定从客户端浏览器接收的编码。
           responseEncoding 指定要发送到客户端浏览器的编码。在大多数情形下，这应与 requestEncoding 是相同的。
           fileEncoding 指定用于 .aspx、.asmx 和 .asax 文件分析的默认编码。
          在 ASP.NET 应用程序中的以下三个位置指定 requestEncoding、responseEncoding、fileEncoding、culture 和 uiCulture 属性的值： 
           在 Web.config 文件的全球化一节中。此文件是 ASP.NET 应用程序的外部文件。
           在页面指令中。请注意，当应用程序在页面中时，文件已经被读取。因此，指定 fileEncoding 和 requestEncoding 为时已晚。只有 uiCulture、Culture 和 responseEncoding 可以在页面指令中指定。
           在应用程序代码中以编程方式指定。该设置可能随请求的不同而不同。同页面指令一样，到打开应用程序代码时，指定 fileEncoding 和 requestEncoding 为时已晚。只有 uiCulture、Culture 和 responseEncoding 可以在应用程序代码中指定。