情報をインターネットやイントラネット経由で配布する利点の 1 つに、さまざまな国や地域に住むユーザーがアクセスできる国際的な Web サイトを作成できるということがあります。ユーザーは自国語に翻訳されたページを要求し、この言語に対応したブラウザを使用して、ページの内容を読むことができます。
異なる複数の言語で記述されたページを含む Web サイトを作成する場合、ブラウザと Web サーバーの間、または、ASP スクリプトと COM コンポーネントの間で受け渡しされる文字列を変換する必要がある場合があります。Web サイトにあるページがすべて、Web サーバーで使用されている既定の文字セットで書かれている場合は、ASP により自動変換が行われます。しかし、異なる言語を使用するブラウザのために、異なる文字セットを使用してページを作成した場合は、文字列をどのように変換するかを指定する ASP コマンドを使用する必要があります。たとえば、あるサイトに日本語文字セットが含まれるページと、中国語文字セットが含まれるページが混在する場合、特定のページにある文字列を処理する際に、ASP で使用する文字セットを指定しなければなりません。
また、ASP では、通貨、時刻、日付、数字などの表示を、そのロケールの文化的慣習に合わせるためのコマンドも用意されています。文字列変換コマンドと同様に、ロケール コマンドも、スクリプトで Web サーバーとブラウザの既定のロケールが使用されない場合のみ使用します。
国際的な Web サイトを構築するには、さまざまな設計シナリオが考えられます。予算と時間を考慮した上で、これらのシナリオを適宜組み合わせるのが効果的です。考えられる 3 つのシナリオを次に示します。
シナリオ 1 - 各 Web ページの翻訳
Web ページの翻訳をローカライズ業者に依頼する場合、すべてのページを翻訳対象にすることは必ずしも経済的なソリューションではありません。ただし、静的コンテンツの占める割合が大きい場合には、ほかのシナリオよりサーバー プロセスの要求が高速化できます。
シナリオ 2 - データベースに格納したテキスト セグメントの翻訳
Web サイトが比較的小規模であったり、頻繁にコンテンツが更新される場合、テキスト セグメント全体をデータベースに格納することもできます。データベースは、セグメントのコードページによってインデックスが作成されます。SQL は、それぞれのコードページによって文字列を処理します。Access では、Response.BinaryWrite で出力される Unicode 文字列が処理されます。データベースに格納したテキスト セグメントを翻訳する際は、単一のファイルをローカライズ業者に支給します。データベース呼び出しは単純なクエリであるため、ページの送信速度にほとんど影響がありません。
シナリオ 3 - 翻訳ツールの使用
個々のロケールは特定の翻訳ツールで対応していないことがあり、翻訳結果にエラーが出ることもあるため、翻訳したすべてのページに対して校正が必要です。
Windows 2000 での IIS 5.0 のリリース以降、いくつかの変更がなされました。UTF-8 サポートは、日本語などの代理文字を含むマルチバイト系の文字全体に拡張されています。IIS 組み込みオブジェクトは、異なるコードページで使用される文字列を格納および取得できるようになりました。たとえば、フォーム データおよびサーバー変数には、Web サーバーの既定ではないコードページを使用してエンコードした文字列を含めることができます。Ad Rotator や Content Rotator など、IIS 組み込みのコンポーネントでも、各国の文字をサポートしています。最後に、Response オブジェクトのプロパティに CodePage および LCID、メタベース プロパティに AspLCID が新しく加わっています。これに伴って、ページで設定されるコードページとロケールの階層構造も変更されています。詳細については、次のトピックを参照してください。