次の方法で共有

世界に対応したアプリケーションを開発するためのベスト プラクティス

このセクションでは、世界対応のアプリケーションを開発するときに従うベスト プラクティスについて説明します。

グローバリゼーションのベスト プラクティス

  1. アプリケーションを内部的に Unicode にします。

  2. System.Globalization名前空間によって提供されるカルチャ対応クラスを使用して、データの操作と書式設定を行います。

    • 並べ替えには、 SortKey クラスと CompareInfo クラスを使用します。
    • 文字列比較の場合は、 CompareInfo クラスを使用します。
    • 日付と時刻の書式設定には、 DateTimeFormatInfo クラスを使用します。
    • 数値書式を設定する場合は、 NumberFormatInfo クラスを使用します。
    • グレゴリオ暦と非グレゴリオ暦の場合は、 Calendar クラスまたは特定のカレンダー実装のいずれかを使用します。

  3. 適切な状況で、 System.Globalization.CultureInfo クラスによって提供されるカルチャ プロパティの設定を使用します。 CultureInfo.CurrentCultureプロパティは、日付と時刻や数値の書式設定などのタスクの書式設定に使用します。 リソースを取得するには、 CultureInfo.CurrentUICulture プロパティを使用します。 CurrentCultureプロパティとCurrentUICultureプロパティはスレッドごとに設定できます。

  4. アプリケーションで、 System.Text 名前空間のエンコード クラスを使用して、さまざまなエンコードとの間でデータの読み取りと書き込みを行えるようにします。 ASCII データは想定しないでください。 ユーザーがテキストを入力できる任意の場所に国際文字が指定されるとします。 たとえば、アプリケーションでは、サーバー名、ディレクトリ、ファイル名、ユーザー名、URL の国際文字を受け入れる必要があります。

  5. UTF8Encoding クラスを使用する場合は、セキュリティ上の理由から、このクラスによって提供されるエラー検出機能を使用します。 エラー検出機能を有効にするには、 throwOnInvalidBytes パラメーターを受け取るコンストラクターを使用してクラスのインスタンスを作成し、このパラメーターの値を true に設定します。

  6. 可能な限り、文字列を一連の個々の文字としてではなく、文字列全体として処理します。 これは、部分文字列を並べ替えたり検索したりする場合に特に重要です。 これにより、結合された文字の解析に関連する問題が回避されます。 System.Globalization.StringInfo クラスを使用して、1 文字ではなくテキストの単位を操作することもできます。

  7. System.Drawing名前空間によって提供されるクラスを使用してテキストを表示します。

  8. オペレーティング システム間で一貫性を保つため、ユーザー設定が CultureInfoをオーバーライドできないようにします。 CultureInfo パラメーターを受け取り、useUserOverrideに設定するfalse コンストラクターを使用します。

  9. 国際データを使用して、国際オペレーティング システムのバージョンでアプリケーション機能をテストします。

  10. セキュリティ上の決定が文字列比較または大文字と小文字の変更操作の結果に基づいている場合は、カルチャに依存しない文字列操作を使用します。 この方法では、結果が CultureInfo.CurrentCultureの値の影響を受けないようにします。 カルチャに依存する文字列比較によって一貫性のない結果が生成される方法を示す例については、「文字列を使用するためのベスト プラクティス」の「現在のカルチャを使用する文字列比較」セクションを参照してください。

  11. インターチェンジ (API 呼び出しの JSON ドキュメント内のフィールドなど) またはストレージに使用する要素については、 CultureInfoを使用します。さらに、ラウンドトリップ形式 ( "O"、 "o" 日時書式指定子など) を明示的に指定する必要があります。 インバリアント カルチャの書式指定文字列は安定しており、変更される可能性は低いですが、明示的な書式指定文字列を指定すると、コードの意図を明確にするのに役立ちます。

  12. グローバリゼーション データ は安定していないため、これを念頭に置いてアプリケーションとそのテストを記述する必要があります。 これは、サポートされているすべてのプラットフォーム上のホスト OS チャネルを通じて年に数回更新されます。 通常、このデータはランタイムと共に配布されません。

ローカライズのベスト プラクティス

  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 およびその他のサーバー アプリケーションのグローバリゼーションのベスト プラクティス

ヒント

ASP.NET Framework アプリのベスト プラクティスを次に示します。 ASP.NET Core アプリについては、「 ASP.NET Core のグローバリゼーションとローカライズ」を参照してください。

  1. アプリケーションで CurrentUICulture プロパティと CurrentCulture プロパティを明示的に設定します。 既定値に依存しないでください。

  2. ASP.NET アプリケーションはマネージド アプリケーションであるため、カルチャに基づいて情報を取得、表示、および操作するために、他のマネージド アプリケーションと同じクラスを使用できることに注意してください。

  3. ASP.NET では、次の 3 種類のエンコードを指定できます。

    • requestEncoding は、クライアントのブラウザーから受信したエンコードを指定します。
    • responseEncoding は、クライアント ブラウザーに送信するエンコードを指定します。 ほとんどの場合、このエンコードは、 requestEncodingに指定したエンコードと同じである必要があります。
    • fileEncoding では、.aspx、.asmx、および .asax ファイル解析の既定のエンコードを指定します。

  4. ASP.NET アプリケーションの次の 3 つの場所で、 requestEncoding、 responseEncoding、 fileEncoding、 culture、および uiCulture 属性の値を指定します。

    • Web.config ファイルのグローバリゼーション セクション。 このファイルは、ASP.NET アプリケーションの外部にあります。 詳細については、「 <globalization> 要素」を参照してください。
    • ページ ディレクティブ。 アプリケーションがページ内にある場合、ファイルは既に読み取られたことに注意してください。 そのため、fileEncoding と requestEncoding を指定するのは遅すぎます。 ページ ディレクティブで指定できるのは、 uiCulture、 culture、および responseEncoding だけです。
    • アプリケーション コード内でプログラム的に処理します。 この設定は、要求ごとに異なる場合があります。 ページ ディレクティブと同様に、アプリケーションのコードに到達するまでに、 fileEncoding と requestEncodingを指定するには遅すぎます。 アプリケーション コードでは、 uiCulture、 culture、および responseEncoding のみを指定できます。

  5. uiCulture 値はブラウザーの受け入れ言語に設定できることに注意してください。

  6. 配布されるアプリケーションの場合、ダウンタイムのない更新 (Azure Container Apps など) を許可する場合、または同様の場合は、異なる形式規則またはその他のカルチャ データ (最も関連性の高いタイム ゾーン ルール) を持つアプリケーションの複数のインスタンスが存在する可能性がある状況を計画する必要があります。

    • アプリケーションのデプロイにデータベースが含まれている場合は、データベースに独自のグローバリゼーション ルールがあることを覚えておいてください。 ほとんどの場合、データベースでグローバリゼーション関連の関数を実行しないようにする必要があります。
    • アプリケーションのデプロイにクライアント グローバリゼーション リソースを使用するクライアント アプリケーションまたは Web フロントエンドが含まれている場合は、クライアント リソースがサーバーで使用可能なリソースと異なると想定します。 クライアントでグローバリゼーション関数のみを実行することを検討してください。

堅牢なテストに関する推奨事項

  1. 依存関係をより明示的にし、テストを容易かつ並列化できるようにするには、書式設定を実行するメソッドにパラメーターなどのカルチャ関連の設定を明示的に渡し、日付と時刻を操作するメソッドにCultureInfoすることをTimeZoneInfo。 時刻を取得するときは、または同様の型も使用するTimeProvider。

  2. ほとんどのテストでは、特定 の 書式設定操作の正確な出力やタイム ゾーンの正確なオフセットを明示的に検証しないでください。 書式設定とタイム ゾーン データはいつでも変更される可能性があり、それ以外の場合はオペレーティング システムの 2 つの同一インスタンス (および同じコンピューター上のプロセスが異なる可能性があります) 間で異なる場合があります。 正確な値に依存すると、テストが脆弱になります。

    • 一般に、一部の出力が受信されたことを検証するだけで十分です (書式設定時に空でない文字列など)。
    • 一部のデータ要素と形式では、データが入力値に正しく解析されることを検証する方法 (ラウンドトリップ) が代わりに用いられる場合があります。 フィールドが削除された場合 (たとえば、一部の日付関連フィールドの場合は年) や、値が切り捨てられたり丸められたりする場合 (浮動小数点出力など) には注意が必要です。
    • ローカライズされたすべての形式出力を検証するための明示的な要件がある場合は、テストのセットアップ中にカスタム カルチャを作成して使用 することを検討する必要があります 。 ほとんどの単純なケースでは、コンストラクターCultureInfoを使用してnew CultureInfo(..) オブジェクトをインスタンス化し、DateTimeFormatプロパティとNumberFormatプロパティを設定することでこれを行うことができます。 より複雑なケースでは、型をサブクラス化すると、追加のプロパティをオーバーライドできます。 これには、リソース ファイルを使用して 擬似的な割り当てを 有効にするなど、その他の利点が考えられる場合があります。
    • すべての日付/時刻操作の結果を検証するための明示的な要件がある場合は、テストのセットアップ時にカスタム インスタンスを作成して使用TimeZoneInfo。 これには、特定のエッジ ケースの安定したテスト (DST ルールの変更など) を有効にするなど、追加の利点が考えられます。

こちらも参照ください