Unicode
Unicode は、世界的な文字エンコード標準です。 システムでは、文字と文字列の操作にのみ Unicode が使用されます。 Unicode のすべての側面の詳細については、「Unicode 標準」を参照してください。
Unicode は、文字データと文字列データを処理するための以前のメカニズムと比較して、ソフトウェアのローカライズを簡素化し、多言語テキスト処理を改善します。 Unicode を使用してアプリケーション内の文字データと文字列データを表すことで、可能なすべての文字コードに対して 1 つのバイナリ ファイルを使用して、グローバル マーケティング用のユニバーサル データ交換機能を有効にすることができます。 Unicode では、次の処理が行われます。
- スクリプトと言語の任意の組み合わせから描画された任意の文字の組み合わせを 1 つのドキュメントに共存できます。
- 各文字のセマンティクスを定義します。
- スクリプトの動作を標準化します。
- 双方向テキスト用の標準アルゴリズムを提供します。
- 他の標準へのクロスマッピングを定義します。
- 1 文字セットの複数のエンコードを定義します。UTF-7、UTF-8、UTF-16、UTF-32 です。 これらのエンコーディング間でのデータの変換はロスレスです。
Unicode では、世界中の言語で使用される多数のスクリプトと、発行に使用される多数の技術記号と特殊文字がサポートされています。 サポートされているスクリプトには、ラテン語、ギリシャ語、キリル語、ヘブライ語、アラビア語、デバナガリ、タイ語、ハン語、ハングル語、ひらがな、カタカナなどがありますが、これらに限定されません。 サポートされている言語には、ドイツ語、フランス語、英語、ギリシャ語、ロシア語、ヘブライ語、アラビア語、ヒンディー語、タイ語、中国語、韓国語、日本語が含まれますが、これらに限定されません。 Unicode は現在、世界中の最新のコンピューターで使用されている文字の大部分を表す可能性があり、さらに完全になるように更新され続けています。
Unicode 対応関数については、「 関数プロトタイプの規則」を参照してください。 これらの関数は UTF-16 (ワイド文字) エンコードを使用します。これは Unicode の最も一般的なエンコードであり、Windows オペレーティング システムのネイティブ Unicode エンコードに使用されます。 各コード値は、8 ビットコード値を使用する文字および文字列データに対する以前の コード ページ アプローチとは対照的に、16 ビット幅です。 16 ビットを使用すると、65,536 文字の直接エンコードが可能になります。 実際、人間の言語を文字起こしするために使用される記号のユニバースはさらに大きく、U+D800 から U+DFFF の範囲の UTF-16 コード ポイントを使用してサロゲート ペアを形成します。これは、補助文字の 32 ビット エンコーディングを構成します。 詳細については、「 サロゲートと補助文字 」を参照してください。
Unicode 文字セットには、U+0308 (" ̈")、結合二角かっこやウムラウトなど、多数の結合文字が含まれています。 Unicode は、多くの場合、同じグリフを ''composed'または ''decomposed' 形式で表すことができます。たとえば、"Ä" の構成済み形式は単一の Unicode コード ポイント "Ä" (U+00C4) ですが、分解された形式は "A" + " ̈" (U+0041 U+0308) です。 Unicode では、すべてのグリフに対して構成済みのフォームが定義されるわけではありません。 たとえば、回旋とチルダ ("ỗ") を含むベトナム語の小文字 "o" は、U+006f U+0302 U+0303 (o + Circumflex + Tilde) で表されます。 文字と関連する問題の組み合わせの詳細については、「 文字列を表す Unicode 正規化の使用」を参照してください。
8 ビット環境と 7 ビット環境との互換性のために、Unicode は UTF-8 と UTF-7 としてそれぞれエンコードすることもできます。 Windows の Unicode 対応関数は UTF-16 を使用しますが、マルチバイト文字セット コード ページとして Windows でサポートされている UTF-8 または UTF-7 でエンコードされたデータを操作することもできます。
新しい Windows アプリケーションでは、内部データ表現として UTF-16 を使用する必要があります。 Windows ではコード ページの広範なサポートも提供され、同じアプリケーションでの混在使用が可能です。 新しい Unicode ベースのアプリケーションでも、コード ページを操作する必要がある場合があります。 その理由については、「 コード ページ」を参照してください。
アプリケーションは MultiByteToWideChar 関数と WideCharToMultiByte 関数を使用して、コード ページと Unicode 文字列に基づいて文字列間で変換できます。 名前は "MultiByte" を参照しますが、これらの関数は 1 バイト文字セット (SBCS)、 2 バイト文字セット (DBCS)、マルチバイト文字セット (MBCS) コード ページでも同様に機能します。
通常、Windows アプリケーションでは内部的に UTF-16 を使用し、別の形式を使用する必要があるインターフェイス上の "シン レイヤー" の一部としてのみ変換する必要があります。 この手法は、データの損失と破損から保護します。 各コード ページは異なる文字をサポートしていますが、Unicode によって提供される文字の全範囲をサポートしている文字はありません。 ほとんどのコード ページでは、異なるサブセットがサポートされ、エンコード方法が異なります。 UTF-8 と UTF-7 のコード ページは例外です。完全な Unicode 文字セットがサポートされているため、これらのエンコードと UTF-16 の間の変換はロスレスです。
あるコード ページで使用されるエンコードから別のコード ページで使用されるエンコードに直接変換されたデータは、異なるコード ページ上の同じデータ値で異なる文字をエンコードできるため、破損の可能性があります。 アプリケーションが可能な限りインターフェイスの近くに変換している場合でも、処理するデータの範囲について慎重に検討する必要があります。
Unicode からコード ページに変換されたデータは、特定のコード ページで特定の Unicode データで使用されるすべての文字を表すことができるわけではないため、データが失われる可能性があります。 したがって、ターゲット コード ページが Unicode 文字列内のすべての文字を表すことができない場合、 WideCharToMultiByte でデータが失われる可能性があることに注意してください。
Unicode を使用するようにコード ページ ベースのレガシ アプリケーションを最新化する場合は、汎用関数と TEXT マクロを使用して、2 つのバージョンのアプリケーションをコンパイルするソースのセットを 1 つ保持できます。 1 つのバージョンでは Unicode がサポートされ、もう 1 つは Windows コード ページで動作します。 このメカニズムを使用すると、変換のすべてのフェーズでコンパイル、ビルド、テストできるアプリケーション ソースを維持しながら、非常に大きなアプリケーションを Windows コード ページから Unicode に変換できます。 詳細については、「 関数プロトタイプの規則」を参照してください。
Unicode 文字と文字列は、コード ページベースの文字と文字列とは異なるデータ型を使用します。 一連のマクロと名前付け規則に加えて、この区別により、2 種類の文字データが誤って混在する可能性が最小限に抑えられます。 コンパイラの型チェックを容易にして、Unicode 文字列を予期する関数で Unicode パラメーター値のみが使用されるようにします。