コード ページ

  • [アーティクル]

現在記述されているほとんどのアプリケーションでは、UTF-16 エンコードを使用して、主に Unicode として文字データを処理します。 ただし、多くのレガシ アプリケーションでは、コード ページに基づいて文字セットが引き続き使用されます。 新しいアプリケーションでも、多くの場合、次のいずれかの理由でコード ページを操作する必要があります。

  • レガシ アプリケーションと通信するため。
  • 古いメールサーバーやニュースサーバーと通信するため、Unicode が常にサポートされていない可能性があります。
  • レガシの目的で Windows コンソールと通信するため。 (コンソールでは Unicode がサポートされていますが、一部の従来のコマンド ライン アプリケーション ツールではサポートされていない場合があります)。

Note

新しい Windows アプリケーションでは、さまざまなコード ページの不整合を回避し、ローカライズを容易にするために Unicode を使用する必要があります。

 

各コード ページは、コード ページ識別子 (1252 など) で表され、Unicode および文字セット API 関数によって処理されます。 サポートされているコード ページ識別子の一覧については、「 コード ページ識別子」を参照してください。 Microsoft Go グローバル デベロッパー センター の "コード ページ" リファレンスには、多くのコード ページの完全な説明が記載されています。

一般的に "ANSI コード ページ" と呼ばれる Windows コード ページは、ASCII 以外の値 (127 より大きい値) が国際文字を表すコード ページです。 これらのコード ページは Windows Me でネイティブに使用され、Windows NT以降でも使用できます。

Note

もともと、英語やその他の西ヨーロッパ言語で一般的に使用されるコード ページである Windows コード ページ 1252 は、米国国立標準協会 (ANSI) の草案に基づいていました。 そのドラフトは最終的に ISO 8859-1 になりましたが、標準が最終版になる前に Windows コード ページ 1252 が実装され、ISO 8859-1 とまったく同じではありません。

 

多くの Windows API 関数には、"A" (ANSI) と "W" (ワイド、Unicode) のバージョンがあります。 "A" バージョンは Windows コード ページに基づいてテキストを処理し、"W" バージョンでは Unicode テキストを処理します。 「 文字列の Windows データ型 」と 「関数プロトタイプの規則」を参照してください。

Windows コード ページは、"アクティブなコード ページ" または "システムアクティブ コード ページ" とも呼ばれます。 Windows オペレーティング システムには、常に現在アクティブな Windows コード ページが 1 つ存在します。 すべての ANSI バージョンの API 関数では、現在アクティブなコード ページが使用されます。

オリジナル機器メーカー (OEM) のコード ページは、ASCII 以外の値が線画と句読点文字を表すコード ページです。 これらのコード ページは、もともと MS-DOS に使用されていましたが、コンソール アプリケーションでも使用されています。 また、「ファイル名で使用される文字セット」で説明されているように、FAT12、FAT16、FAT32 ファイル システムの拡張されていない ファイル名にも使用されます。 英語の通常の OEM コード ページは、コード ページ 437 です。

Windows コード ページと OEM コード ページの両方で、コード値0x00 0x7F 7 ビット ASCII 文字セットに対応します。 コード値0x00 0x19と0x7Fは常に標準化された制御文字を表し、標準化された表示可能な文字を表す0x7Eを通じて0x20します。 残りのコードで表される文字は、0xff 0x80文字セットによって異なります。 各文字セットには、通常、言語または言語のグループ用にカスタマイズされたさまざまな特殊文字が含まれています。 Windows コード ページ 1252 と OEM コード ページ 437 は、通常、米国で使用されます。

Windows および OEM コード ページに加えて、アプリケーションでは非ネイティブ コード ページを使用できます。 例としては、EBCDIC コード ページと Macintosh コード ページがあります。

Unicode (UTF-7 と UTF-8) の 2 つのエンコードがコード ページとして実装されています。 他のコード ページと同様に、各ページは数値識別子によって認識され、同じ Unicode および文字セット API 関数の多くで処理できます。

コード・ページには、 1 バイト文字セット (SBCS) ページまたは 2 バイト文字セット (DBCS) ページのいずれかを指定できます。 SBCS ページでは、各バイトは 1 つの文字を直接エンコードするため、256 文字 (制御文字、文字、数字、句読点、記号など) を正確に表すことができるようにします。 DBCS コード ページは、日本語や中国語などの言語に使用されます。 このようなコード ページでは、一部の文字には、特定のバイト値 (常に 127 より大きい値) が "リード バイト" として機能する 2 バイト エンコードがあります。 リード バイトは、独自の権限で文字をエンコードする代わりに、"証跡バイト" と組み合わせて文字にのみマップできます。

一部のレガシ プロトコルでは、SBCS コード ページと DBCS コード ページを使用する必要があります。 各 SBCS/DBCS コード ページは異なる文字をサポートしていますが、Unicode で提供される文字の完全な幅をサポートするコード ページはありません。 各 SBCS/DBCS コード ページでは、異なるエンコードされた異なるサブセットがサポートされています。

Note

ある SBCS または DBCS コード ページから別の SBCS コード ページに変換されたデータは、異なるコード ページ上の同じデータ値で異なる文字をエンコードできるため、破損の可能性があります。 Unicode から SBCS または DBCS に変換されたデータは、特定のコード ページでその特定の Unicode データで使用されるすべての文字を表すことができるわけではないため、データが失われる可能性があります。

 

アプリケーションでは、SBCS および DBCS コード ページに加えて、DBCS の場合と同様のアプローチを使用するマルチバイト文字セット コード ページ 52936、54936、51949、5022x を使用できます。 ただし、マルチバイト文字セットのコード ページは、一部の文字の 2 バイト エンコードを超えています。 UTF-7 と UTF-8 では、同様の方法を使用して、それぞれ 7 ビットバイトと 8 ビット バイトに基づいて Unicode をエンコードします。 詳細については、「 Unicode」を参照してください。

いくつかの Unicode および文字セット関数を使用すると、アプリケーションでコード ページを処理できます。 アプリケーションは 、GetCPInfo 関数と GetCPInfoEx 関数を使用して、コード ページに関する情報を取得できます。 この情報には、変換された文字列の文字にコード ページに対応するエントリがない場合に使用される既定の文字が含まれます。

アプリケーションでは、 MultiByteToWideChar 関数と WideCharToMultiByte 関数を使用して、Windows コード ページと Unicode 文字列に基づいて文字列間で変換できます。 名前は "MultiByte" を参照しますが、これらの関数は SBCS、DBCS、マルチバイト文字セットのコード ページでも同様に機能します。

Note

指定されたコード ページが Unicode 文字列内のすべての文字を表すことができない場合、WideCharToMultiByte は一部のデータを失う可能性があります。

 

アプリケーションは、標準の C ランタイム ライブラリ関数を使用して、Windows コード ページと OEM コード ページの間で変換できます。 ただし、これらの関数を使用すると、各コード ページで表すことができる文字が正確に一致しないため、データ損失のリスクがあります。

アプリケーションでは 、GetACP 関数を呼び出すこともできます。 この関数は、現在の Windows (ANSI) コード ページの識別子を取得します。

文字セット