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