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