開發全球化準備應用程式的最佳實務

本節說明開發全球適用應用程式時應遵循的最佳實務。

全球化最佳實務

1. 請讓你的應用程式內部支援 Unicode。

2. 利用命名空間提供的 System.Globalization 文化感知類別來操作與格式化資料。

   • 排序時，使用 class SortKey 和 class CompareInfo 。
   • 字串比較時，使用類別 CompareInfo 。
   • 請使用DateTimeFormatInfo類來格式化日期和時間。
   • 對於數字格式，請使用 類別 NumberFormatInfo 。
   • 對於格里曆和非格里曆，請使用類別 Calendar 或特定的曆法實作之一。

3. 在適當情況下使用該類別提供的 System.Globalization.CultureInfo 文化屬性設定。 使用該 CultureInfo.CurrentCulture 屬性來處理格式化任務，例如日期與時間或數字格式化。 利用該 CultureInfo.CurrentUICulture 屬性來取得資源。 請注意 CurrentCulture ，和 CurrentUICulture 屬性可以針對每個執行緒設定。

4. 透過命名空間中的編碼類別 System.Text ，讓您的應用程式能夠讀寫多種編碼的資料。 不要假設ASCII資料。 假設國際字元會在使用者可輸入文字的地方提供。 例如，應用程式應接受伺服器名稱、目錄、檔案名稱、使用者名稱及網址中的國際字元。

5. 使用該 UTF8Encoding 類別時，出於安全考量，請使用該類別提供的錯誤偵測功能。 要啟用錯誤偵測功能，請使用建構子建立一個類別實例，該建構子取一個 throwOnInvalidBytes 參數並將該參數的值設為 true。

6. 盡可能將字串視為完整字串，而非一連串獨立字元。 這在排序或搜尋子字串時尤其重要。 這將避免解析合併字元時產生的問題。 你也可以用這個類別來處理文字單位，而不是單一字元 System.Globalization.StringInfo 。

7. 使用命名空間提供的 System.Drawing 類別來顯示文字。

8. 為了在作業系統間保持一致，請不允許使用者設定覆蓋 CultureInfo。 使用 CultureInfo 接受 useUserOverride 參數的建構子，並將其設為 false。

9. 在國際作業系統版本上測試你的應用程式功能，並使用國際資料。

10. 若安全決策基於字串比較或大小寫變更操作結果，則使用不區分文化的字串操作。 此做法確保結果不受 的 CultureInfo.CurrentCulture值影響。 請參閱「使用字串最佳實務」中「使用當前文化的字串比較」章節，示範文化敏感字串比較如何產生不一致的結果。

11. 對於任何用於交換的元素（例如，API 呼叫中的 JSON 文件欄位）或儲存，請使用 CultureInfo，並且應該明確指定一個回傳格式（例如 "O"，"o" 日期時間格式指定符）。 雖然不變文化的格式字串是穩定且不太可能改變，但指定明確的格式字串有助於釐清程式碼的意圖。

    • 關於日期與時間元素，請參考《Noda Time》作者Jon Skeet的建議與觀察，他分享了寶貴的見解。 更多資訊請參見 Jon Skeet： 儲存 UTC 並非萬靈丹。

12. 全球化資料 並不穩定，你應該在撰寫應用程式及其測試時考慮這一點。 它每年會透過所有支援平台的主機作業系統頻道更新好幾次。 這些資料通常不會隨執行時分發。

在地化最佳實務

1. 將所有可本地化的資源移到專門處理資源的 DLL 中。 可在地化資源包括使用者介面元素，如字串、錯誤訊息、對話框、選單及嵌入物件資源。

2. 不要硬編碼字串或使用者介面資源。

3. 不要把無法本地化的資源放進只用資源的 DLL。 這讓翻譯者感到困惑。

4. 不要使用在執行時由串接短語組成的複合字串。 複合字串難以本地化，因為它們通常採用英語語法順序，而這並非適用於所有語言。

5. 避免使用像「空資料夾」這類模糊的結構，因為字串會根據字串組成部分的語法角色被不同翻譯。 例如，「empty」可以是動詞或形容詞，這可能導致義大利語或法語等語言中有不同的翻譯。

6. 避免在應用程式中使用包含文字的圖片和圖示。 它們本地化的成本很高。

7. 在使用者介面中，留出足夠空間讓字串長度可以擴展。 在某些語言中，片語可能比其他語言需要多出50%至75%的空間。

8. 使用 System.Resources.ResourceManager 類別來依文化取得資源。

9. 使用 Visual Studio 建立 Windows 表單對話框，並可透過 Windows 表單資源編輯器（Winres.exe）進行本地化。 不要手動寫 Windows 表單對話框。

10. 安排專業的本地化（翻譯）。

11. 欲了解建立與在地化資源的完整說明，請參見 .NET 應用程式中的資源。

ASP.NET 及其他伺服器應用的全球化最佳實務

1. 在你的應用程式中明確設定 CurrentUICulture 和 CurrentCulture 屬性。 不要依賴預設值。

2. 請注意，ASP.NET 應用程式是受管理的應用程式，因此可以使用與其他受管理應用程式相同的類別，根據文化來檢索、顯示及操作資訊。

3. 請注意，你可以在 ASP.NET 中指定以下三種編碼類型：

   • requestEncoding 指定從客戶端瀏覽器接收的編碼。
   • responseEncoding 指定要傳送給用戶端瀏覽器的編碼。 在大多數情況下，此編碼應與 的 requestEncoding編碼相同。
   • fileEncoding 指定了 .aspx、 .asmx 和 .asax 檔案解析的預設編碼方式。

4. 在 ASP.NET 應用程式中，請在以下三個位置指定requestEncoding、responseEncoding、fileEncoding、culture 和uiCulture屬性的值：

   • 在 Web.config 檔案的全球化區段。 此檔案是 ASP.NET 應用程式外部的。 更多資訊請參見 <globalization> 元素。
   • 在頁面指令中。 請注意，當應用程式在頁面中時，該檔案已經被讀取過。 因此，現在指定 fileEncoding 和 requestEncoding 已經太晚了。 在頁面指令中，只能指定uiCulture、culture 和 responseEncoding。
   • 以程式化的方式在應用程式程式碼中進行。 此設定會依需求而異。 與頁面指令相同，當執行到應用程式的程式碼時，已無法指定 fileEncoding 和 requestEncoding。 只有 uiCulture、 culture、 以及 responseEncoding 可以在應用程式碼中指定。

5. 請注意，uiCulture 的值可以設定為瀏覽器接受語言。

6. 對於分散式應用程式，允許零停機更新（例如 Azure 容器應用）或類似情況，你必須為多個應用程式實例使用不同格式規則或其他文化資料的情況做準備，最相關的是時區規則。

   • 如果你的應用程式部署包含資料庫，請記得資料庫會有自己的全球化規則。 在大多數情況下，你應該避免在資料庫中執行任何與全球化相關的功能。
   • 如果你的應用程式部署包含使用客戶端全域化資源的客戶端應用程式或網頁前端，請假設客戶端資源與伺服器可用的資源不同。 考慮只為客戶執行全球化功能。

穩健測試的建議

1. 為了讓相依更明確且測試更容易且可平行化， 你應該考慮 明確將與文化相關的設定（如 CultureInfo 參數）傳給執行格式化的方法，以及 TimeZoneInfo 處理日期和時間的方法。 你在取時間時 也應該 使用 TimeProvider 或類似的類型。

2. 大多數測試中， 你不應該 明確驗證特定格式操作的精確輸出或時區的精確偏移量。 格式與時區資料可能隨時變動，且在同一作業系統的兩個相同實例間（甚至同一機器上可能不同程序）間有所不同。 依賴精確值會讓測試變得脆弱。

   • 驗證某些輸出是否已接收通常就足夠了（例如格式化過程中字串不為空）。
   • 對於某些資料元素和格式，可能會改用驗證資料能否轉換並回復為原輸入值的方法（往返驗證）。 在字段被省略的情況（例如某些日期相關字段的年份）或浮點數輸出被截斷或四捨五入的情況，需特別注意。
   • 如果你有明確要求驗證所有在地化格式輸出， 建議在 測試設定時建立並使用自訂文化。 在大多數簡單情況下，這可以透過實 CultureInfo 例化物件及其建構子 new CultureInfo(..) 並設定 DateTimeFormat and NumberFormat 屬性來完成。 對於較複雜的情況，子類別該型別允許覆蓋其他性質。 這還有額外的潛在好處，例如能透過資源檔案啟用偽本地化。
   • 如果你有明確要求驗證所有日期/時間操作的結果， 建議在 測試設定時建立並使用自訂 TimeZoneInfo 實例。 這還有潛在的額外好處，例如能穩定測試某些邊緣案例（例如DST規則的變更）。

另請參閱

• 全球化與在地化
• .NET 應用程式中的資源