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 では、すべてのグリフに対して構成済みのフォームが定義されるわけではありません。 たとえば、circumflex とチルダ ("ỗ") のベトナム語小文字 "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 つのセットを維持できます。 一方のバージョンでは Unicode がサポートされ、もう 1 つはWindowsコード ページで動作します。 このメカニズムを使用すると、変換のすべてのフェーズでコンパイル、ビルド、テストできるアプリケーション ソースを維持しながら、非常に大きなアプリケーションを Windows コード ページから Unicode に変換できます。 詳細については、「 関数プロトタイプの規則」を参照してください。
Unicode 文字と文字列では、コード ページベースの文字と文字列とは異なるデータ型が使用されます。 一連のマクロと名前付け規則に加えて、この区別により、2 種類の文字データが誤って混在する可能性が最小限に抑えられます。 コンパイラの型チェックを容易にして、Unicode 文字列を必要とする関数で Unicode パラメーター値のみが使用されるようにします。
関連トピック