既存アプリケーションの移行

このドキュメントでは、次のトピックについて説明します。


既存アプリケーションへの Unicode の影響

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 オブジェクトに正しいコードページを定義する必要があります。
  • ソース
    影響を受けるオブジェクトが少数のみの場合は、[Properties]ダイアログボックスを使用してコードページを変更します。複数のオブジェクト(ライブラリ全体など)が影響を受ける場合は、FTOUCH ユーティリティを使用してコードページを変更します。

  • バッチファイル
    Natural プロファイルパラメータ CPOBJINCPSYNIN、および CPPRINT を正しいコードページに設定します。

  • ワークファイル
    コンフィグレーションユーティリティでワークファイルの正しいコードページを設定します。

1 つのオブジェクト(ソースなど)に異なるコードページが混在。 多大 オブジェクトを UTF-8 フォーマットで再書き込みする必要があります。

既存アプリケーションへの Unicode サポートの追加

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 フィールドには半分の長さが必要です。

Natural リモートプロシージャコール(RPC)の移行

プロファイルパラメータ CP の名前が CPRPC に変更されました。以前の Natural バージョンでは、CP は、トランスポートプロトコル ACI(EntireX Broker)が使用される場合に、Entire Conversion Service(ECS)によって使用され、Natural RPC(リモートプロシージャコール)にのみ適用されるコードページの名前を指定するために使用されました。

Natural データのデフォルトコードページを定義する新しい CP パラメータを使用できます。Natural RPC を使用しており、以前は CP パラメータを動的に使用していた場合は、このパラメータを CPRPC に変更する必要があります。

以前のバージョンのパラメータファイルを使用する場合、何も変更する必要はありません。コンフィグレーションユーティリティによって、CPCPRPC に自動的に移行されます。