推奨される国際対応アプリケーション開発手順
このセクションでは、推奨される国際対応アプリケーション開発手順について説明します。
推奨されるグローバリゼーション手順
アプリケーションを内部的に Unicode アプリケーションにします。
データの操作と書式指定には、System.Globalization 名前空間のカルチャ認識クラスを使用します。
並べ替えには SortKey クラスと CompareInfo クラスを使用します。
文字列比較には、CompareInfo クラスを使用します。
日付と時刻の書式指定には、DateTimeFormatInfo クラスを使用します。
数値書式指定には、NumberFormatInfo クラスを使用します。
グレゴリオ暦とグレゴリオ暦以外の暦には、Calendar クラスまたは特定のカレンダー実装を使用します。
状況に応じて、System.Globalization.CultureInfo クラスのカルチャ プロパティ設定を使用します。 日付と時刻や数値の書式指定などの書式指定処理には、CultureInfo.CurrentCulture プロパティを使用します。 リソースを取得するには、CultureInfo.CurrentUICulture プロパティを使用します。 CurrentCulture プロパティと CurrentUICulture プロパティはスレッドごとに設定できることに注意してください。
System.Text 名前空間のエンコーディング クラスを使用して、アプリケーションでの各種エンコーディングのデータの読み取り操作と書き込み操作を有効にします。 常に ASCII データが使用されるとは限らないことに注意してください。 どのようなテキスト入力でも、各種の言語の文字が使用される可能性があります。 たとえば、アプリケーションは、サーバー名、ディレクトリ名、ファイル名、ユーザー名、および URL に含まれる各種言語の文字を受け入れる必要があります。
UTF8Encoding クラスを使用する場合は、セキュリティ上の理由から、このクラスに用意されているエラー検出機能を使用してください。 エラー検出機能を有効にするには、throwOnInvalidBytes パラメーターを受け取るコンストラクターを使用してクラスのインスタンスを作成し、このパラメーターの値を true に設定します。
文字列は、できるだけ全体を 1 つのまとまりとして扱い、個々の文字の連続として処理しないようにします。 これは特に部分文字列の並べ替えと検索で重要です。 これにより、組み合わせ文字の解析に関連する問題の発生を防ぐことができます。
System.Drawing 名前空間のクラスを使用してテキストを表示します。
オペレーティング システム間での一貫性を維持するため、ユーザー設定によって CultureInfo がオーバーライドされないようにしてください。 useUserOverride パラメーターを受け取る CultureInfo コンストラクターを使用し、このパラメーターを false に設定してください。
国際対応オペレーティング システムで、国際対応データを使用してアプリケーションの機能をテストします。
文字列比較操作または大文字と小文字の変更操作の結果に基づいてセキュリティ上の決定を行う場合は、アプリケーションで実行する操作がカルチャに依存しないようにします。 こうすることで、CultureInfo.CurrentCulture の値が結果に影響を及ぼすことがなくなります。 カルチャに依存した文字列の比較により矛盾した結果がどのように生成されるかを示す例については、「カスタムの大文字と小文字の対応規則および並べ替え規則」を参照してください。
推奨されるローカリゼーション手順
ローカライズ可能なすべてのリソースをリソース専用 DLL へ移動します。 ローカライズ可能リソースには、文字列、エラー メッセージ、ダイアログ ボックス、メニュー、埋め込みオブジェクト リソースなどのユーザー インターフェイス要素があります。
文字列やユーザー インターフェイス リソースをハードコーディングしないでください。
ローカライズできないリソースをリソース専用 DLL に含めないでください。 ローカライズを行う翻訳者を混乱させる原因となります。
文字列を実行時に連結して使う方法は避けてください。 連結される文字列は、英語の語順に依存することが多く、ほかの言語でのローカライズ作業が困難になります。
"Empty Folder" のように、構成要素の文法的な役割によって複数の翻訳が存在するあいまいな文字列を使用しないでください。 たとえば、"empty" は動詞または形容詞として解釈できるため、イタリア語やフランス語などの言語での翻訳結果が異なることがあります。
アプリケーションではテキストが含まれているイメージやアイコンを使用しないでください。 このようなイメージやアイコンのローカライズには時間と労力がかかります。
ユーザー インターフェイスの文字列は、表示領域に余裕がある程度の長さにしておいてください。 言語によっては、ユーザー インターフェイスが他の言語よりも 50 ～ 75% 長い領域を必要とする場合があります。
カルチャに基づいてリソースを取得するには、System.Resources.ResourceManager クラスを使用します。
Windows フォームのダイアログ ボックスを作成するには、Visual Studio 2010 を使用します。このように作成されたダイアログ ボックスは、Windows フォーム リソース エディター (Winres.exe) を使用してローカライズできます。 Windows フォームのダイアログ ボックスを手動でコーディングしないでください。
専門的なローカライズ (翻訳) 作業を計画してください。
リソースの作成とローカライズの詳細については、「アプリケーションのリソース」を参照してください。
推奨される ASP.NET アプリケーションのグローバライズ手順
CurrentUICulture プロパティおよび CurrentCulture プロパティをアプリケーションで明示的に設定します。 既定値には依存しないでください。
ASP.NET アプリケーションはマネージ アプリケーションであり、カルチャに基づいた情報の取得、表示、および操作では、ほかのマネージ アプリケーションと同じクラスを使用できます。
ASP.NET では次に示す 3 種類のエンコーディングを指定できる点に注意してください。
requestEncoding は、クライアントのブラウザーから受信されたエンコーディングを指定します。
responseEncoding は、クライアント ブラウザーへ送信するエンコーディングを指定します。 ほとんどの場合、このエンコーディングは requestEncoding に指定されたエンコーディングと同一です。
fileEncoding は、.aspx、.asmx、.asax の各ファイルの解析の既定エンコーディングを指定します。
ASP.NET アプリケーション内の次の 3 か所で、requestEncoding、responseEncoding、fileEncoding、culture、uiCulture の各属性の値を指定します。
Web.config ファイルのグローバリゼーション セクション。 Web.config ファイルは、ASP.NET アプリケーションの外部ファイルです。 詳細については、「<globalization> 要素」を参照してください。
ページ ディレクティブ。 アプリケーションがページを処理している時点では、ファイルは既に読み取られています。 そのため、fileEncoding と requestEncoding を指定するには遅すぎます。 ページ ディレクティブでは uiCulture、Culture、および responseEncoding だけを指定できます。
アプリケーション コード (プログラムで指定)。 この設定は、要求ごとに変更できます。 ページ ディレクティブの場合と同様に、アプリケーション コードの処理時点では、fileEncoding と requestEncoding の指定は遅すぎます。 アプリケーション コードでは、uiCulture、Culture、および responseEncoding だけを指定できます。
uiCulture 値には、ブラウザー受け入れ言語を設定できます。 詳細については、「ASP.NET クイック スタート」の Working With Resources サンプルを参照してください。