このドキュメントでは、次のトピックについて説明します。
従来のコードページは、特定の言語または共通スクリプトを共有する言語グループをサポートする、特定の順序で並べられた、選択された文字コードのリストです。 コードページには、最大で 256 個の文字コードを含めることができます。 中国語や日本語など、256 文字よりも多い文字セットの場合は、ダブルバイトコード単位処理（DBCS）が使用されます。DBCS コードページは実際にはマルチバイトエンコードであり、1 バイトおよび 2 バイトコードポイントが混在します。
コードページには、同じデータ文字列内に異なる言語を保存できないという固有の短所があります。 Unicode は、この制限をなくすために設計されました。データへのアクセスに使用されるプラットフォーム、プログラム、または言語に依存しない標準エンコードが、すべての文字セットに提供されます。 Unicode では、すべての文字に一意の番号が付けられます。
Unicode 標準によって定義された各コード要素に 1 つの番号が割り当てられます。 これらの番号それぞれは "コードポイント" と呼ばれ、テキスト内で参照されるときは、"U" の後に 16 進形式でリストされます。 例えば、コードポイント "U+0041" は、16 進数 "0041"（10 進数 "65" と同じ）です。 これは、Unicode 標準の文字 "A" を表し、"LATIN CAPITAL LETTER A" という名前です。
Unicode 標準では、同じデータをバイト、ワード、またはダブルワード指向フォーマットで転送することを可能にする 3 つのエンコード形式が定義されています。 "コード単位" は、特定のエンコードで文字を表すことができる最小のビット組み合わせです。 Unicode 標準では、UTF-8 エンコード形式で 8 ビットのコード単位、UTF-16 エンコード形式で 16 ビットのコード単位、UTF-32 エンコード形式で 32 ビットのコード単位が使用されます。 3 つのエンコード形式すべてで同じ共通文字レパートリがエンコードされるため、データを欠落させずに相互に効率的に変換できます。
Natural のコンテキストでは、これらのエンコード形式のうちの UTF-16 および UTF-8 の 2 つが関係します。 Natural では、ランタイム時の Unicode 文字列のコーディングに UTF-16 が使用され、ファイル内の Unicode データのコーディングに UTF-8 が使用されます。 UTF-16 は、エンディアンに依存する 2 バイトエンコードです。使用されるエンディアンフォーマットは、プラットフォームによって異なります。 UTF-8 は 1 バイトエンコードです。
Unicode の詳細については、Unicode Consortium の Web サイト http://www.unicode.org/ を参照してください。
注意:
Unicode コードポイントに関する情報を取得するには、Natural for Windows で使用可能な SYSCP ユーティリティを使用します。
以前のバージョンの Natural では、コードページの文字のみがサポートされていました。 Natural バージョン 4.2（メインフレーム）、6.2（Windows および UNIX）、および 6.3（OpenVMS）から、Unicode がサポートされています。
Unicode のサポートに関して、Natural データフォーマット U が導入されており、固有のステートメント、パラメータ、システム変数などがあります。詳細については、このドキュメントの該当する箇所を参照してください。
現在、既存のデータのほとんどをコードページフォーマットで使用できます。 このデータを Unicode に変換する場合は、正しいコードページを使用する必要があります。 Natural では、次の複数のレベルで正しいコードページを定義できます。
Natural でデフォルトコードページが定義されていない場合は、システムコードページが使用されます。
メインフレームでコードページが定義されていない場合（CP=OFF）、デフォルトコードページは定義されていません。 現在の I/O デバイスのコードページに合わせて Natural セッションを調整するために、CP=AUTO が使用されます。
Natural パラメータ CP が定義されている場合は、デフォルトコードページが使用されます。オペレーティングシステムのコードページは上書きされます。
ソースなどに対して定義されているオブジェクトコードページによって、このオブジェクトのデフォルトコードページは上書きされます。
1 つのアプリケーションで Unicode 文字列とコードページ文字列を使用する場合は、Natural によって、必要に応じて（例えば、データを移動または比較する場合に）暗黙的に変換されます。 明示的な変換は、ステートメント MOVE ENCODED を使用して実行できます。
ほとんどの場合、Unicode のサポートを必要としない既存アプリケーションは、変更なく実行されます。 Windows、UNIX、および OpenVMS プラットフォームでは、既存のソースが異なるコードページでエンコードされる場合に、変更が必要な場合があります。 詳細については、このドキュメントの「既存アプリケーションの移行」を参照してください。
既存アプリケーションを実行し、そのアプリケーションを変更しないで Unicode データもサポートすることはできません。 Natural データフォーマット U をアプリケーションに導入する必要があります。ほとんどの場合、A フォーマット定義を
U フォーマット定義で置き換えるだけでは不十分です。 文字列の特定のメモリレイアウトを前提とするすべてのコード（例えば、英数字から数字フォーマットへの REDEFINE）を変更する必要があります。
Unicode 文字は、変数名、オブジェクト名、およびライブラリ名で使用することはできません。
Unicode ベースのデータは、Adabas および DB2 でサポートされています。
Natural では、Unicode の照合および変換について、International Components for Unicode（ICU）ライブラリが使用されます。 詳細については、http://icu.sourceforge.net/userguide/ を参照してください。 このドキュメントの「ICU ライブラリ」も参照してください。
ICU は IBM によって配布されています。 これは、コードページおよび Unicode のサポート、ソフトウェアの国際化対応（I18N）、およびグローバリゼーション（G11N）のための、十分に考慮された移植可能な C/C++ ライブラリのセットです。すべてのプラットフォームで、アプリケーションに同じ結果をもたらします。 ICU は C/C++ で記述されているため、実行可能な ICU モジュールのサイズは非常に大きく、アセンブラで記述されたコードに比べてパフォーマンスはよくありません。 一方、最初から作り直すのは無意味です。 そのような複雑な問題については、承認済みのツールを使用するほうが意味があるでしょう。 他の多くのソフトウェアベンダも ICU ライブラリを使用しているため、コードページおよび Unicode のサポートに関する Natural の動作がそれらの製品と互換性があることを保証できます。 ICU は、新しい Unicode バージョンのサポートや追加のロケールのサポートのために、IBM によって今後も改善される予定です。
現在使用中の ICU バージョンと Unicode 仕様に関する情報は、SYSCP ユーティリティのメインメニューで入手できます。 Natural for Mainframes の『ユーティリティ』ドキュメントの「SYSCP の起動と終了」を参照してください。
