開發世界性應用程式的最佳做法

  • 發行項

本章節將說明開發世界性的應用程式的最佳作法。

全球化最佳做法

  1. 請在內部製作您的應用程式 Unicode。

  2. 使用 System.Globalization 命名空間提供的文化特性感知類別來管理和格式化資料。

  3. 在適當情況下使用 System.Globalization.CultureInfo 類別提供的文化特性屬性設定。 使用 CultureInfo.CurrentCulture 屬性來格式化工作，例如日期和時間或數字格式化。 使用 CultureInfo.CurrentUICulture 屬性來擷取資源。 請注意，您可以根據個別執行緒來設定 CurrentCulture 和 CurrentUICulture 屬性。

  4. 啟用您的應用程式使用 System.Text 命名空間中的編碼類別來回讀取和寫入各種編碼方式的資料。 請勿假設 ASCII 資料。 請假設在使用中輸入文字的地方提供國際字元。 例如，應用程式應該會接受在伺服器名稱、目錄、檔名和 URL 中使用國際字元。

  5. 在使用 UTF8Encoding 類別時，基於安全理由，請使用這個類別所提供的錯誤偵測功能。 若要開啟錯誤偵測功能，請使用採用 throwOnInvalidBytes 參數的建構函式，並將此參數的值設定為 true，以建立此類別的執行個體。

  6. 如果可能的話，請將字串當做完整的字串處理，而不是連續的個別字串。 在排序或搜尋子字串時，這點特別重要。 它將可避免發生剖析組合字元的相關問題。 您也可利用 System.Globalization.StringInfo 類別，便無須使用單一字元，而是以單位來使用文字。

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

  8. 為了作業系統的一致性，請勿使用使用者設定來覆寫 CultureInfo。 請使用採用 CultureInfo 參數的 useUserOverride 建構函式，並將此參數設定為 false。

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

  10. 如果安全性決策是根據字串比較或大小寫變更作業的結果而定，則請使用不區分文化特性 (Culture) 的字串作業。 這種作法可以確保結果不會受 CultureInfo.CurrentCulture 的值所影響。 如需示範區分文化特性 (Culture) 的字串比較如何產生不一致結果的範例，請參閱使用字串的最佳做法中的「使用目前文化特性 (Culture) 的字串比較」一節。

  11. 針對用於交換的任何元素 (例如，API 呼叫中 JSON 文件的欄位) 或儲存體，請使用 CultureInfo；此外，您應該明確指定往返格式 (例如 "O"、"o" 日期時間格式指定名稱)。 雖然不因文化特性而異的格式字串穩定且不太可能變更，但指定明確的格式字串有助於釐清程式碼的意圖。

  12. 全球化資料不穩定，撰寫應用程式及其測試時請銘記在心。 它透過所有支援平台上的主機 OS 通道，每年更新數次。 此資料通常不會與執行階段一起散發。

當地語系化最佳做法

  1. 將所有可當地語系化資源移到個別僅含資源的 DLL。 可當地語系化的資源包括使用者介面項目，例如字串、錯誤訊息、對話方塊、功能表和內嵌物件資源。

  2. 請勿將字串或使用者介面資源寫在程式中。

  3. 請勿將不可當地語系化的資源放入僅含資源的 DLL。 這會使翻譯工具混淆。

  4. 請勿使用在執行階段建置和來自連結字詞的複合字串。 複合字串很難進行當地語系化，因為它們通常會使用不適用於所有語言的英文文法順序。

  5. 避免模糊的建構，例如 "Empty Folder"，其中的字串將依據字串元件擔任的文法角色，而進行不同的轉譯。 例如，"empty" 可以是動詞或形容詞，在某些語言中會有不同的轉譯結果，例如義大利文或法文。

  6. 避免在您的應用程式中使用含有文字的影像和圖示。 它們進行當地語系化的成本過高。

  7. 請保留充分的空間，以便在應用程式介面中擴展字串長度。 在某些語言中，字詞所需要的空間可能比在其他語言多百分之 50-75。

  8. 使用 System.Resources.ResourceManager 類別來根據文化特性擷取資源。

  9. 使用 Visual Studio 建立 [Windows Forms] 對話方塊，如此就能使用 Windows Forms 資源編輯器 (Winres.exe) 將對話方塊當地語系化。 請不要以手動方式編碼 Windows Form 對話方塊。

  10. 進行專業當地語系化 (轉譯)。

  11. 如需建立和當地語系化資源的完整描述，請參閱 .NET 應用程式中的資源。

ASP.NET 與其他伺服器應用程式的全球化最佳做法

提示

下列最佳做法適用於 ASP.NET Framework 應用程式。 如需 ASP.NET Core 應用程式，請參閱 ASP.NET Core 中的全球化和當地語系化。

  1. 在應用程式中明確設定 CurrentUICulture 和 CurrentCulture 屬性。 請勿過於依賴預設值。

  2. 請注意，ASP.NET 應用程式是 Managed 應用程式，因此可使用和其他 Managed 應用程式相同的類別，根據文化特性來擷取、顯示和管理資訊。

  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 容器應用程式)，或者同樣地，您必須針對具有不同格式規則或其他文化特性資料的應用程式執行個體進行規劃，其中最相關的是時區規則。

    • 如果您的應用程式部署包含資料庫，則請切記，資料庫會有自己的全球化規則。 在大部分情況下，您應該避免在資料庫執行任何全球化相關功能。
    • 如果應用程式部署包含使用用戶端全球化資源的用戶端應用程式或 Web 前端，請假設用戶端資源與伺服器可用的資源不同。 請考慮僅在用戶端執行全球化功能。

強固測試的建議

  1. 若要讓相依性更明確，並且讓測試更容易且可平行化，您應考慮將文化特性相關設定，例如 CultureInfo 參數，明確傳遞至執行格式化的方法，以及將 TimeZoneInfo 傳遞至處理日期和時間的方法。 擷取時間時，您也應該使用 TimeProvider 或類似的型別。

  2. 針對大部分的測試，您不應該明確驗證特定格式化作業的確切輸出或時區的確切位移。 格式化和時區資料可能隨時變更，而且在作業系統兩個相同執行個體之間可能有所不同 (以及同一部機器上的不同流程可能也不同)。 依賴確切值會使測試變得脆弱。

    • 一般而言，驗證已收到部分輸出就已足夠 (例如，格式化時的非空白字串)。
    • 針對部分資料元素和格式，也可以採用驗證資料剖析是否為輸入值的方式 (往返)。 如果欄位已卸除 (例如，某些日期相關欄位的年份) 或是值已截斷或四捨五入 (例如浮點輸出)，則必須小心。
    • 如果您有明確需求，必須驗證所有本地化格式輸出，則您應考慮在測試設定期間建立和使用自訂文化特性。 在大部分的簡單案例中，使用其建構函式 new CultureInfo(..) 具現化 CultureInfo 物件，並設定 DateTimeFormat 和 NumberFormat 屬性即可完成。 對於更複雜的案例，將型別子類別化可覆寫其他屬性。 這個方法還有其他潛在優點，例如使用資源檔案啟用偽本地化。
    • 如果您有明確需求，必須驗證所有日期/時間作業的結果，則您應考慮在測試設定期間建立和使用自訂 TimeZoneInfo 執行個體。 這個方法還有其他潛在優點，例如啟用特定邊緣案例 (例如 DST 規則變更) 的穩定測試。

另請參閱