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 は、多くの場合、同じグリフを ''構成' または '分解' 形式で表すことができます。たとえば、"Ä" の構成形式は単一の 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 を使用しますが、UTF-8 または UTF-7 でエンコードされたデータを操作することもできます。これは、コード ページ マルチバイト文字セットWindows でサポートされています。
新しい 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 パラメーター値のみが使用されるように、コンパイラの型チェックが容易になります。
関連トピック