ASP.NET網站國際化政策

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 可以設定為浏覽器接受語言。