ASP と ASP.NET のグローバリゼーションの問題

文字セットとコードページ

コンピューターの画面の文字は、一連のバイトだけであることがわかります。 バイト系列は、任意の数の方法で作成および解釈できます。 解釈でバイト配列が作成されたエンコーディングとは異なるエンコーディングを使用する場合、解釈はガベージとして表示されます。 文字セット (文字セット) は、通常ブラウザーで使用されるエンコード形式です。 サーバー側の変換に適した Codepage プロパティは、文字のエンコード方法を指定する変換テーブルにすぎません。

ブラウザーは、現在の文字セットに従ってフォームの投稿データをエンコードします。 現在の文字セットが "windows-1256" の場合、サーバーへのバイト転送も "windows-1256" としてエンコードされます。

ASP が解釈されている場合、Form コレクションと Querystring コレクションは、コードで参照されるまでビルドされません。 それらがビルドされると、現在のコード ページに従って文字列データが Unicode に変換されます。 (既定では、ASP と ASP.NET の両方が Unicode 形式を使用してコンテンツを処理します)。 コレクションを参照する前に正しいコード ページを設定することが非常に重要です。そうしないと、メモリ内の Unicode 表現が正しくなくなります。

コード ページを設定するには、Session.Codepage または Response.Codepage を使用します。 Response.Codepage は、Microsoft インターネット インフォメーション サービス (IIS) 5.1 以降のバージョンでのみ使用できます。 これらのプロパティを に設定する整数値 (文字セットに対応する) については、次の Microsoft Web サイトを参照してください。

文字セット認識
http://msdn2.microsoft.com/en-us/library/Aa752010.aspxたとえば、アラビア語のコード ページを設定するには、次のコードを使用します。

Session.Codepage = 1256

Response.Codepage は現在の応答にのみ影響します。 ただし、Session.Codepage は、現在のユーザーによって行われたすべての応答に影響します。 これらのプロパティのいずれかを使用してコード ページを設定し、Form コレクションと Querystring コレクションをビルドすると、現在のコード ページのこの変更により、Response.Write メソッドはメモリ内の Unicode を現在のコード ページに変換します。 このトピックの詳細については、次の MSDN Web サイトを参照してください。

文字列変換 (ASP) のコード ページの設定 http://msdn2.microsoft.com/en-us/library/ms525789.aspx文字セットとコードページに関連する問題に関する要点は、クライアントの文字セットとサーバーのコードページが一致する必要があるということです。

言語を受け入れる

ASP 開発者がユーザーがブラウザーで設定した言語を知りたい場合、開発者は Request.ServerVariables ("HTTP_ACCEPT_LANGUAGE") 変数を使用して、ユーザーが応答を読み取る言語の一覧 (英語、ドイツ語、インドなど) と、ユーザーがこれらの言語を表示する優先順位を見つけることができます。 ASP.NET では、同様の情報が Request.UserLanguages プロパティに配列として存在します。
ASP コードでこの情報を使用する方法の詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示してください。

229690 ブラウザーの言語設定に従って ASP ロケール ID を設定する方法
 

インターネット エクスプローラーでのマルチバイト文字セットの表示

マルチバイト文字セットを表示できるエンコード形式は Unicode (UTF-8) のみです。 UTF-8 では、キリル文字、インド文字、日本語をすべて同じページに表示できます。 UTF-8 を使用しない場合は、一度に表示できる言語は 1 つだけです。 ブラウザーの文字セットを設定するには、Response.CharSet プロパティを使用します。

ページ上の静的マルチバイト文字

ページに直接格納されているマルチバイト文字を表示するには、最初に特定のエンコードでページを保存する必要があります。 UTF-8 が最適ですが、特定のコード ページ (文字のコード ページと一致) も機能します。

Microsoft Visual InterDev を使用して ASP ファイルを保存しても、Visual InterDev は ANSI 英語または Unicode でのみ保存できるため、ここでは役に立ちません。 Unicode として保存された ASP ページは、ASP ではサポートされていません。

Microsoft Visual Studio .NET では、任意のエンコードでファイルを保存できます。 これを行うには、2 つの方法があります。 既定の方法では、ユーザーの現在のコード ページを使用してファイルを保存します。 エンコードを使用してファイルを保存する追加の方法は次のとおりです
。 [ ファイル ] メニューの [ 名前を付けてファイルを保存] をクリックします。 [ファイルを
名前を付けて保存] ダイアログ ボックスで、[保存] ボタンのドロップダウン矢印を
クリックします。 矢印をクリックすると、オプションは
[エンコードで保存 および 保存] になります。 [エンコードで保存] をクリック
すると、[詳細な保存オプション] ダイアログ ボックスが表示され、コンピューターにインストールされているコード ページの一覧から適用するエンコードの種類を選択できます。


注 保存操作のエンコードは変更されますが、1 回限りです。 次の保存は既定値に戻されます。

既定のコード ページを変更するには、[ファイル] メニューの
[詳細な保存オプション] をクリックします。 [ 詳細な保存オプション] ダイアログ ボックスで、保存操作の既定のエンコードを任意のコード ページに設定できます。

これらの方法は、ファイルをディスクに保存する方法に関連しています。 ただし、既に説明したように ASP の出力を制御するには、Session.CodePage プロパティと Response.CharSet プロパティを設定する必要があります。 IIS 5.1 以降のバージョンでは、Response.CodePage プロパティを使用することもできます。

サーバー上の既定の CODEPAGE

ページの既定のロケールと既定のコード ページは、 のレジストリ設定によって異なります。DEFAULT ユーザー。 国際キーは、レジストリ hive HKEY_USERS\.DEFAULT\Control Panel\Internationalにあります。 また、IIS によって選択されたロケールの動作を変更することもできます。

ログオンしたユーザーに上記のキーまたはシステムの既定値と同じロケールが設定されている場合は、ユーザー設定が優先されます。

例: 既定のロケールの日付形式は 11.1.2004 に設定されていますが、ログオンしているユーザー (同じロケール セット) の日付形式は 2004 年 11 月 1 日です。 2004 年 11 月 1 日の設定は、ASP に対して有効になります。

(ASP.NET の場合、これは異なる場合があります。 一部のインストールでは、ASPNET ユーザーは、読み込まれたときにHKEY_USERSの下に表示される独自のプロファイルを持っています。 それ以外の場合は、 を使用します。DEFAULT プロファイル。 <%@ %> 宣言で codepage 属性を使用することもできます。 これは、ファイルが別のエンコードで保存され、コードページ 932 (日本語) などの既定値で保存される場合に使用する必要があります。

コードページの問題とフォント変換の問題: どれがどれですか?

疑問符 (?) 文字や、文字が表示されるボックスが表示されることがあります。

ランタイム エンコードの変更

Application_BeginRequest イベントでは、requestEncoding の値を変更し、要求が処理される前に有効にすることができます。 応答の場合、Page_PreRender イベントは、出力のエンコードを変更する最後の機会です。 また、Response.Write は、呼び出すとすぐにこのバッファーに文字を格納するため、Response.Write を使用する前に適切なエンコードが設定されていることを確認してください。

元のデータが Unicode 以外の場合: インターネットエクスプローラーマルチバイト文字セットを解釈する方法

また、必要に応じて、ASP.NET を ASP のように動作させることもできます。 これを行うには、responseEncoding と requestEncoding を windows-1252 (iso-8859-1 よりも完全なエンコード) に設定し、Response.Charset プロパティを使用してテキストを正しく表示する必要があります。 これは、windows-1252 が 1 バイトのエンコード スキームであり、バッファーに追加されたバイトを変更しないために機能します。 したがって、2 バイト文字は一連の単一バイトとして送信されます。 その後、Response.Charset プロパティを使用して、バイトを解釈する方法をエクスプローラーインターネットに伝えることができます。 このシナリオは、COM オブジェクトからの戻り値など、元のデータが Unicode または UTF-8 として格納されていない場合、またはデータが非 N フィールド (varchar など) に Microsoft SQL Serverに格納されている場合に必要になる場合があります。

グローバリゼーションの問題のSQL Serverと ASP.NET

INSERT INTO MusicAlbum (Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'Abida', 4653, 403)
Or:
Dim t As String = "INSERT INTO MusicAlbum(Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'" & TextBox1.Text & "', 4653, 403)"

System.Globalization 名前空間

この名前空間は、.NET Frameworkのグローバリゼーションとローカライズの中核です。 この名前空間で使用されるメイン クラスは CultureInfo クラスです。 日付/時刻形式、数値形式、比較情報、テキスト情報など、カルチャ固有の情報が保持されます。 CultureInfo クラスの詳細については、次の MSDN Web サイトを参照してください。

http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo(vs.71).aspxCultureInfo

ニュートラル カルチャと特定のカルチャ

ニュートラル カルチャは、言語に関連付けられているが、特定の国/地域には関連付けられていないカルチャです。 特定のカルチャは、言語と特定の国/地域の両方に関連付けられています。

例: "DE" (ニュートラル カルチャ) はドイツ語用ですが、"de-AT" (特定のカルチャ) は、オーストリアで話されているドイツ語用です。 ニュートラル カルチャを書式設定に使用することはできません。

.NET Framework クラスの現在のスレッドとカルチャの認識

出力がカルチャに依存すると予想される.NET Framework ライブラリ内のすべてのクラスとメソッドには、次の 2 つの組み込み動作があります。

• 引数を指定しながらカルチャ コードを指定し、出力が指定されたカルチャに基づくようにします。 これは省略可能です。

• これが見逃された場合 (通常はです)、クラスは Thread.CurrentThread.CurrentCulture プロパティにチェックを保持し、それに従って動作するのに十分なインテリジェントです。

このプロパティの値は、次のようなコードで変更できます。

    Dim ci As CultureInfo
        ci = New CultureInfo("de-AT")
        Thread.CurrentThread.CurrentCulture = ci

このコード例では、"de" はドイツ語を表し、"AT" はオーストリアを表します。 そのため、このインスタンスでは DateTime.Now() です。ToString メソッドは、オーストリアのドイツ語で日付と時刻を表現する方法に対応する形式で日付と時刻を返します。

フレームワークでは、CurrentCulture プロパティが常に初期化されることが (次のように) 保証されます。

1. プログラムによって に設定されているもの。

2. プログラマによって明示的に設定されていない場合、プロパティは構成ファイル (<グローバリゼーション> タグ) から選択されます。

3. プロパティが存在しない場合は、Web サーバーが実行されているカルチャです。 これは通常、オペレーティング システムの言語に対応するニュートラル カルチャです。

リソース ファイル

ビルド アクション属性が Visual Studio .NET の ASP.NET プロジェクトに追加された埋め込みリソースに設定されているすべての .resx、.resource ファイル、およびファイルは、マニフェストの一部として自動的にコンパイルされ、アプリケーション アセンブリ内に埋め込まれます。 これは、Visual Studio .NET コマンド プロンプトを使用してリソース ファイル ジェネレーター (RESGEN) ユーティリティを使用して手動で実行することもできます。 詳細については、次の MSDN Web サイトを参照してください。

http://msdn2.microsoft.com/en-us/library/ccec7sz1(vs.71).aspxこれは、グローバリゼーションとは無関係のアプリケーション リソースを管理する必要があるときに適用される一般的な概念です。 ただし、グローバリゼーションを実装する場合は、サテライト アセンブリを使用する必要があります。

サテライト アセンブリ

サテライト アセンブリは、次のことが当てはまることを確認するときに、ASP.NET プロジェクトで使用できます。

1. すべての aspx ファイル内のすべてのユーザー インターフェイス要素には、id 属性と runat=server 属性を装備する必要があります。

2. 個別の .resx ファイルを作成します。 各カルチャは、アプリケーションでサポートする各カルチャに対応している必要があります。

3. これらのファイルすべてに共通の名を決定する必要があります。 'Strings'。

4. 別の .resx ファイルには、次の名前付け規則 commonfirstname という名前を付けます。languagecode-regioncode.resx (例: Strings.de-AT.resx、Strings.en-GB.resx)。

5. 既定のケースで表示するすべての文字列を含むリソース ファイル
   commonfirstname.resx (Strings.resx) が必要です。

6. ユーザーのカルチャを検出するコードを記述し、それに一致するように Thread.CurrentThread.CurrentUICulture プロパティを設定します。

7. ResourceManager クラスを使用してリソースを読み込むコードを記述します。

8. 読み込まれたオブジェクトから文字列を抽出し、ユーザー インターフェイス要素に割り当てるコードを記述します。

これらの手順を実行すると、Visual Studio.NET は Strings.resx をコンパイルし、それをアプリケーション アセンブリ (MyGlobalizationTestProjectName.dll) に埋め込みます。 ただし、他のすべての .resx ファイルでは、実行可能コードを持たないリソース データのみを含む個別の dll ファイルが生成されます。 これらは実際にはサテライト アセンブリと呼ばれます。 また、Visual Studio .NET では、次のようなフォルダー構造にこれらを配置します:MyGlobalizationTestProjectName
|------- bin
|------en-US

MyGlobalizationTestProjectName.resources.dll |------ja-JP

MyGlobalizationTestProjectName.resources.dll |------de-AT
MyGlobalizationTestProjectName.resources.dll

CurrentCulture と CurrentUICulture の違い

System.Globalization 名前空間のクラスのメソッドは Thread.CurrentThread.CurrentCulture プロパティに依存して出力を提供しますが、リソース アセンブリを読み込む ResourceManager クラスは、適切なサテライト アセンブリを読み込む Thread.CurrentThread.CurrentUICulture プロパティによって異なります。 C# コードの例を次に示します。

using System.Globalization;
using System.Threading;
using System.Resources;

//Load resources. 
protected ResourceManager gStrings = new ResourceManager("MyGlobalizationTestProjectName.strings", typeof(MyTestWebFormName).Assembly);

// Get the user's preferred language.
string sLang = Request.UserLanguages[0];
// Set the thread's culture for formatting, comparisons, etc.   
Thread.CurrentThread.CurrentCulture =  CultureInfo.CreateSpecificCulture(sLang);
// Set the thread's UICulture to load resources
// from satellite assembly.
Thread.CurrentThread.CurrentUICulture = new CultureInfo(sLang);

private void Page_Load(object sender, System.EventArgs e) 

{ 

 if (!IsPostBack)  

 {      
// Get strings from resource file and assign to UI elements.
head1.InnerHtml = gStrings.GetString("satellite.head1");
p1.InnerHtml = gStrings.GetString("satellite.p1");
sp1.InnerHtml = gStrings.GetString("satellite.sp1");
sp2.InnerHtml = gStrings.GetString("satellite.sp2");
butOK.Text = gStrings.GetString("satellite.butOK");
butCancel.Value = gStrings.GetString("satellite.butCancel");
   }

 }

ASP.NET がサテライト アセンブリを選択する順序:

スレッドの CurrentUICulture を設定すると、ASP.NET は一致するリソースを次の順序で自動的に選択します。

• 一致するカルチャでサテライト アセンブリが見つかった場合は、そのアセンブリのリソースが使用されます。

• CurrentUICulture に一致するニュートラル カルチャを持つサテライト アセンブリが見つかった場合、そのアセンブリのリソースが使用されます。

• CurrentUICulture に一致するものが見つからない場合は、実行可能アセンブリに格納されているフォールバック リソースが使用されます。

注 これは、より一般的なリソース フォールバック プロセスに基づいています。 詳細については、次の MSDN Web サイトを参照してください。

http://msdn2.microsoft.com/en-us/library/sb6a8618(vs.71).aspx

サテライト アセンブリを手動で作成する:

このサテライト アセンブリの使用は、Visual Studio .NET によってアセンブリ自体が作成される場所です。 ただし、Visual Studio .NET では、既定ではサテライト アセンブリに厳密な名前は付けられません。 これらのオプションを変更する場合は、サテライト アセンブリを手動で作成する必要があります。 詳細については、次の MSDN Web サイトを参照してください。

http://msdn2.microsoft.com/en-us/library/21a15yht(vs.71).aspx .

用語集

ANSI は、アメリカ国立標準研究所を意味します。 このコンテキストでは、特定の言語/文字セットの特定のコード ページを表します。 ほとんどの場合、英語のコードページ (windows-1252) を参照します。

ASCII 1 バイト (または 7 ビット) エンコード スキーム。 0 から 127 の範囲の文字のみが標準化されています。 128 から 255 の範囲は ASCII の拡張機能であり、標準の一部ではありません。 この例は、OEM ASCII グラフの上限範囲と VB ASCII グラフの違いです。

CharSet 設定は、主にインターネット エクスプローラーと、文字データの解釈方法をブラウザーに指示するブラウザーに使用されます。 例: Response.charSet = "iso-8859-1"

Codepage 文字のエンコード方法を指定する変換テーブル (通常はサーバーに使用されます)。

グローバリゼーショングローバリゼーションは、文化、地域、または国/地域や言語のニーズが満たされるようにアプリケーションを設計および作成するプロセスです。 つまり、後でローカライズできるようにアプリケーションを設計することはグローバリゼーションです。

ロケール/カルチャ言語および地域固有の形式/好み (日付と予定表の形式、時刻形式、通貨形式、大文字と小文字の区別、並べ替え、文字列の比較、アドレス形式、電話番号形式、用紙サイズ、測定単位、書き込み方向など)。

LocaleID (LCID) 言語識別子と並べ替え ID を指定する DWORD 値。 これは、日付/時刻などに応じて書式設定する必要がある特定の地域の形式を指定するために使用できます。

ローカライズ性 要求された言語/ロケールのコンテンツを表示するアプリケーションの機能。

ローカリゼーションは、ユーザー インターフェイスを特定の言語やロケールに翻訳するプロセスです。

マルチバイト文字セット 文字が日本語などの 2 バイト以上で構成される文字セット。 UTF-8 もこのカテゴリに該当します。 (Unicode は技術的にはこのカテゴリにありますが、Windows では独自のカテゴリ

があります)。 Unicode 2 バイト エンコード スキーム。 Windows では、Unicode が内部的に使用されます。 Unicode 専用の API は、関数名の末尾に "W" で示されます。 ワイド文字とも呼ばれます。Web アプリケーションから直接使用することはできません。

UTF-8 文字を 1 から 6 バイトで表すことができる文字エンコード。 Windows では、範囲は 1 から 3 バイトです。 WEB アプリケーションの NT4 ではサポートされていません。



ワイド文字セット Unicode のエイリアス。 DBCS (2 バイト文字セット)、UCS-2、UTF-16 とも呼ばれます。

常に、将来の列またはナレッジ ベースで対処するトピックに関するアイデアを自由に送信するには、Ask For It フォームを使用してください。