このドキュメントでは、次のトピックについて説明します。
Windows、UNIX、および OpenVMS プラットフォームでは、Natural は内部的に Unicode 対応です。つまり、文字列を含む数多くの構造は、現在 Unicode フォーマットです。 例えば、現在 Natural ソースエリアは Unicode フォーマットです。 このため、コードページフォーマットでのみ使用できるデータは、内部的に Unicode フォーマットに変換されます。 このことは、例えば、Natural ソースや Natural ライブラリ名およびオブジェクト名に適用されます。 ただし、コードページから Unicode への変換、およびその逆の変換は、正しいコードページが変換に使用された場合にのみ正常に実行されます。 アプリケーションの変更ではなく再カタログのみが実行される場合でも、カタログのためにオブジェクトが Natural ソースエリアにロードされるため、コードページ情報が重要です。 すべてのオブジェクトがシステムコードページでコード化されている場合、変更は必要ありません。 オブジェクトがシステムコードページでコード化されていない場合は、追加情報について「Windows、UNIX、および OpenVMS プラットフォームでの既存オブジェクトの移行」を参照してください。
ほとんどの場合、内部 Unicode 構造は、より多くのメモリを必要とします。 プロファイルパラメータ USIZE に小さい値を定義している場合は、この値を大きくする必要がある場合があります。
既存アプリケーションへの Unicode の影響はありません。 内部構造は変更されておらず、A フォーマットフィールドの変換は強制されません。 つまり、既存の Natural アプリケーションは何もしなくても実行されます。 パラメータ CFICU および CP は "OFF" に設定されている必要があります。 ICU ロードモジュールのいずれか（NATICU、NATICUCV、または NATICUXL）をリンクする必要性も、この場合は重複になります。 潜在的な Unicode フィールドをサポートするために属性が拡張されているため、I/O バッファのみが大幅に増やされています。 CP が "OFF" に設定されると、システム変数 *CODEPAGE はクリアされ、既知の変換テーブル（標準テーブルや代替テーブルなど）の使用は I/O 変換のため継続されます。
Natural は、コードページ情報を複数のレベルで定義できるように拡張されています。
Natural プロファイルパラメータ CP は、デフォルトの Natural コードページを定義します。
一部のオブジェクト（Natural ソース、Natural バッチ入力／出力ファイル、タイプ ASCII、圧縮 ASCII、Unformatted、および CSV のワークファイル）に対して、オブジェクト固有のコードページを定義できます。
オブジェクト固有のコードページもデフォルトコードページも定義されていない場合は、Natural によってオペレーティングシステムのコードページが使用されます。
正しいコードページを自動的に識別することはできないため、必要なコードページ情報をユーザーが定義することが重要です。 次のような状況が考えられます。
| ステータス | 作業 | 対処 |
|---|---|---|
| すべてのデータがオペレーティングシステムのコードページで使用可能。 | 作業不要 | 対処不要。 |
| すべてのデータを 1 つのコードページで保存。ただし、このコードページはオペレーティングシステムのコードページとは異なる。 | 簡単 | Natural プロファイルパラメータ CP を正しいコードページに設定する必要があります。
|
| データは異なるコードページで使用可能。 | ソースとコードページの数に依存 | すべての Natural オブジェクトに正しいコードページを定義する必要があります。 |
| 1 つのオブジェクト（ソースなど）に異なるコードページが混在。 | 多大 | オブジェクトを UTF-8 フォーマットで再書き込みする必要があります。 |
Natural は、コードページ情報を複数のレベルで定義できるように拡張されています。
Natural プロファイルパラメータ CP は、デフォルトの Natural コードページを定義します。
一部のオブジェクト（Natural ソース、Natural バッチ入力／出力ファイル、出力レポート、Adabas ファイル）に対して、オブジェクト固有のコードページを定義できます。
オブジェクト固有のコードページもデフォルトコードページも定義されていない場合（CP=OFF が適用されている場合）、Natural によってデータは変換されません。
正しいコードページを自動的に識別することはできないため、必要なコードページ情報をユーザーが定義することが重要です。 次のような状況が考えられます。
| ステータス | 作業 | 対処 |
|---|---|---|
| すべてのデータがオペレーティングシステムのコードページで使用可能。 | 作業不要 | 対処不要。 |
| すべてのデータを 1 つのコードページで保存。ただし、このコードページはオペレーティングシステムのコードページとは異なる。 | 簡単 | Natural プロファイルパラメータ CP を正しいコードページに設定する必要があります。 このコードページが I/O デバイスによってサポートされていることを確認します。 CP=AUTO によって、Natural は I/O デバイスのコードページを使用して実行されます。
|
| データは異なるコードページで使用可能。 | ソースとコードページの数に依存 | すべての Natural オブジェクトに正しいコードページを定義する必要があります。 |
| 1 つのオブジェクト（ソースなど）に異なるコードページが混在。 | 多大 | オブジェクトを適切なコードページフォーマットで再書き込みする必要があります。 |
以前の Natural バージョンで保存または STOW されたソースには、コードページ情報がありません。 ディレクトリのコードページフィールドは空です。
Natural ソースは Unicode フォーマットで保存されないため、ソースを、セッションに適用されるデフォルトコードページ（システム変数 *CODEPAGE の値）に変換する必要があります。 コードページのサポートが無効の場合（CP=OFF）、ソースのコードページ情報は無視され、変換は実行されません。 英数字定数は、ソースエリアにロードされるときに、デフォルトコードページに合わせて調整される必要があります。
Natural ソースは Unicode フォーマットで保存されないため、英数字定数を、オブジェクトの起動時にデフォルトコードページに合わせて調整する必要があります。 これは、CPAGE コンパイラオプションを使用して実行できます。 CPAGE が "ON" に設定されている場合、追加テーブルがオブジェクト内に生成されます。 このテーブルは Natural ローダーによって使用され、すべての英数字定数がデフォルトコードページ（システム変数 *CODEPAGE の値）に変換されます。 英数字定数の量に応じて、追加テーブルで結果のオブジェクトのサイズが大きくなり、変換によって追加の CPU 時間が消費されます。
従属オブジェクト（プログラムやプログラムによって使用されるローカルデータエリアなど）によって同じコードページが使用されることが重要です。 複数の従属オブジェクトで異なるコードページが使用されている場合、使用されている文字（例えば、"#"）が、使用されているコードページの同じコードポイントにマップされるようにする必要があります。 次のオブジェクトおよびデータには、オブジェクト固有のコードページもデータ固有のコードページも関連付けられていません。
データ定義モジュール（DDM）
Predict ルール
Predict XRef データ
このようなデータをオブジェクト固有のコードページが定義されているオブジェクトで使用する場合、またはこのようなオブジェクトにより生成する場合は、注意が必要です。 アプリケーション自体をコードページ対応にする必要はないが、処理対象のデータに関してアプリケーションをコードページセンシティブにする必要がある場合は、プロファイルパラメータ
SRETAIN を値 "(ON,EXCEPTNEW)" とともに使用することを考慮してください。
U フォーマットに基づく新しいソースコードで既存アプリケーションを拡張することは、簡単です。 （A フォーマットと比較して）U フォーマットについては次のルールを考慮する必要があります。
U 以外のフォーマットへの U の REDEFINE を避ける必要があります。文字が分割される場合があるためです。
U フォーマットは、エンディアンに依存します。 フォーマット B と U 間で移動する場合は、これを考慮する必要があります。
パフォーマンス上の理由から、DEFINE DATA で U を整列します（UNIX および OpenVMS でのパフォーマンスの向上）。
U を A に移動すると文字が失われる場合があることに注意します。
既存フィールドを A フォーマットから U フォーマットに変更する場合は、次のルールを考慮する必要があります。
文字列の特定のエンコードを前提とするコードは、変更する必要があります（B フィールドとの比較など）。
フィールドのすべての REDEFINE ステートメントについて、その有効性をチェックする必要があります。
N への REDEFINE は不可能です。つまり、予期した結果を得られません。
データベースフィールドは Unicode に移行する必要があります（データベースでサポートされている場合）。
フィールドの長さを変更する必要がある場合があります。A フィールドに DBCS 文字が含まれている場合、U フィールドには半分の長さが必要です。
プロファイルパラメータ CP の名前が CPRPC に変更されました。 以前の Natural バージョンでは、CP は、トランスポートプロトコル ACI（EntireX Broker）が使用される場合に、Entire Conversion Service（ECS）によって使用され、Natural リモートプロシージャコールにのみ適用されるコードページの名前を指定するために使用されました。
バージョン 6.2（Windows および UNIX）、バージョン 6.3（OpenVMS）、およびバージョン 4.2（メインフレーム）以降は、Natural データのデフォルトコードページを定義する新しい CP パラメータを使用できます。 Natural RPC を使用しており、以前は CP パラメータを動的に使用していた場合は、このパラメータを CPRPC に変更する必要があります。
以前のバージョンのパラメータファイルを使用する場合、何も変更する必要はありません。コンフィグレーションユーティリティによって、CP は CPRPC に自動的に移行されます。
パラメータ CP は、Natural データのデフォルトコードページの名前を指定するため、またはユーザー端末からコードページ名を自動的に取得するために、ソースモジュール NATCONFG 内のパラメータマクロ NTCPAGE とともに使用されます。
