このドキュメントでは、次のトピックについて説明します。
Windows、UNIX、および OpenVMS プラットフォームでは、Natural は内部的に Unicode 対応です。つまり、文字列を含む数多くの構造は、現在 Unicode フォーマットです。例えば、現在 Natural ソースエリアは Unicode フォーマットです。このため、コードページフォーマットでのみ使用できるデータは、内部的に Unicode フォーマットに変換されます。このことは、例えば、Natural ソースや Natural ライブラリ名およびオブジェクト名に適用されます。ただし、コードページから Unicode への変換、およびその逆の変換は、正しいコードページが変換に使用された場合にのみ正常に実行されます。アプリケーションの変更ではなく再カタログのみが実行される場合でも、カタログのためにオブジェクトが Natural ソースエリアにロードされるため、コードページ情報が重要です。すべてのオブジェクトがシステムコードページでコード化されている場合、変更は必要ありません。オブジェクトがシステムコードページでコード化されていない場合は、追加情報について「Windows、UNIX、および OpenVMS プラットフォームでの既存オブジェクトの移行」を参照してください。
Windows では、Natural 出力ウィンドウが Unicode 対応になっています。これは、すべてのフィールドが Unicode フォーマットであることを意味します。コードページ文字列の長さが Unicode 文字列の長さと異なる A フォーマットフィールドの場合、Natural 出力ウィンドウの動作は若干変化します。これは、コードページ文字列の長さが通常 Unicode 文字列の長さの 2 倍のダブルバイトコードページで特に関係します。A フォーマット入力フィールドでは、フィールドに "Unicode-string-length" 文字を入力できるようになりました。フィールドを離れるとき、デフォルトのコードページがダブルバイトコードページの場合、ターゲット A フォーマットフィールドに収まらないすべての文字が削除されます。
ほとんどの場合、内部 Unicode 構造は、より多くのメモリを必要とします。プロファイルパラメータ USIZE
に小さい値を定義している場合は、この値を大きくする必要がある場合があります。
Natural は、コードページ情報を複数のレベルで定義できるように拡張されています。
Natural プロファイルパラメータ CP
は、デフォルトの Natural コードページを定義します。
一部のオブジェクト(Natural ソース、Natural バッチ入力/出力ファイル、タイプ ASCII、圧縮 ASCII、Unformatted、および CSV のワークファイル)に対して、オブジェクト固有のコードページを定義できます。
オブジェクト固有のコードページもデフォルトコードページも定義されていない場合は、Natural によってオペレーティングシステムのコードページが使用されます。
正しいコードページを自動的に識別することはできないため、必要なコードページ情報をユーザーが定義することが重要です。次のような状況が考えられます。
ステータス | 作業 | Action |
---|---|---|
すべてのデータがオペレーティングシステムのコードページで使用可能。 | 作業不要 | 対処不要。 |
すべてのデータを 1 つのコードページで保存。ただし、このコードページはオペレーティングシステムのコードページとは異なる。 | 簡単 | Natural プロファイルパラメータ CP を正しいコードページに設定する必要があります。
|
データは異なるコードページで使用可能。 | ソースとコードページの数に依存 | すべての Natural オブジェクトに正しいコードページを定義する必要があります。 |
1 つのオブジェクト(ソースなど)に異なるコードページが混在。 | 多大 | オブジェクトを UTF-8 フォーマットで再書き込みする必要があります。 |
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 RPC(リモートプロシージャコール)にのみ適用されるコードページの名前を指定するために使用されました。
Natural データのデフォルトコードページを定義する新しい CP
パラメータを使用できます。Natural RPC を使用しており、以前は CP
パラメータを動的に使用していた場合は、このパラメータを CPRPC
に変更する必要があります。
以前のバージョンのパラメータファイルを使用する場合、何も変更する必要はありません。コンフィグレーションユーティリティによって、CP
は CPRPC
に自動的に移行されます。