このドキュメントでは、次のトピックについて説明します。
Windows、UNIX、および OpenVMS プラットフォームでは、Natural は内部的に Unicode 対応です。 つまり、文字列を含む数多くの構造は、現在 Unicode フォーマットです。 例えば、現在 Natural ソースエリアは Unicode フォーマットです。 このため、Natural コードを書き込むとき、およびカタログするときに、Natural I/O および Natural 開発環境でランタイム時に Unicode データを処理できます。
最初のバージョンには、いくつかの例外があります。Natural ダイアログ（エディタおよびランタイム）は Unicode 対応ではありません。 これらのモジュールは、後のバージョンでは Unicode 対応される予定です。
Natural は内部的に Unicode 対応ですが、既存のすべてのデータには、現在はコードページフォーマットがあります。 結果として、Natural バージョン 6.2 以降で使用された場合、このようなデータはすべてコードページフォーマットから Unicode フォーマットに変換されます。 例えば、ソースがプログラムエディタで開かれた場合、コードページファイルフォーマットから Unicode ソースエリアフォーマットへの変換が実行されます。 U フォーマットを使用しない場合でも、このことには利点があります。インストールされているシステムコードページに関係なく、すべての言語固有の文字が表示されます。 ただし、正しいコードページ情報を定義するのはユーザーの責任です。 詳細については、「既存アプリケーションの移行」を参照してください。
Natural オブジェクトをカタログするとき、U 接頭辞を使用して定義されていないすべての定数は、対応するソースのコードページに変換されます。 ソースが UTF-8 フォーマットの場合、これらの定数はデフォルトコードページに変換されます。
注意:
ほとんどの場合、Unicode データには、コードページデータよりも多くのメモリスペースが必要です。 そのため、Natural バージョン 6.2 以降では、Natural パラメータ USIZE を増やす必要がある場合があります。
Unicode は、ローカルな Natural for Windows 環境で完全にサポートされます。
エディタは Unicode 対応であり、使用できるすべての文字を入力できます。 ソースを保存するとき、Natural では最初にソースを元のコードページに変換しようとします。 このコードページにない文字がソースに含まれているために失敗した場合、その後の処理はパラメータ
SUTF8 の設定によって異なります。 SUTF8 が "ON" の場合、ソースは UTF-8 フォーマットで保存されます。 SUTF8 が "OFF" の場合、ユーザーは、ソースを元のコードページで保存するか、現在の保存をキャンセルするかを確認されます。 ソースを元のコードページで保存することをユーザーが決定した場合、見つからない文字は置換文字で置き換えられます。 また、［名前をつけて保存］ダイアログボックスで、コードページを明示的に選択できます。
プログラムエディタは、Unicode 双方向アルゴリズムをサポートするために拡張されています。
出力ウィンドウも、Unicode 対応です。 文字がキーボードで入力される場合、A フォーマットフィールドは、デフォルトコードページで使用可能な文字のみを受け入れます。
完全な Unicode サポートは、SPoD および Natural Web I/O インターフェイスでのみ利用できます。 SPoD は、Natural ソースへの Unicode 入力に必要です。ローカルな Natural for Windows 環境について前述した内容と同じことが適用されます。 Natural Web I/O インターフェイスは、Natural アプリケーションからの Unicode I/O に必要です。
Natural が端末エミュレーションを経由して使用される場合、すべての出力は Unicode からデフォルトコードページに変換されてから表示されます。 デフォルトコードページで使用できない文字は、デフォルトコードページの置換文字で置き換えられます。 同様の場合の入力は、デフォルトコードページに基づいてのみ可能です。
注意:
UTF-8 フォーマットの Natural ソースは、Natural for UNIX または Natural for OpenVMS ネイティブエディタを使用して開くことができません。
Natural ランタイム環境は、Unicode サポートに対応しています。 Unicode 文字は、デフォルトコードページ（システム変数 *CODEPAGE の値）に変換されてから、端末に表示されます。 デフォルトコードページに同等の文字がない Unicode 文字は、置換文字によって置き換えられます。
SPoD での Natural Web I/O インターフェイスでは、Unicode 文字は端末エミュレーションによって完全にサポートされています。 この場合、U フォーマットフィールドが表示され、Unicode として正しく入力できます。 デフォルトコードページの同等の文字に変換されません。
Natural Web I/O インターフェイスは、NDV サーバーコンフィグレーションパラメータ TERMINAL_EMULATION=WEBIO によってアクティブになります。 システム変数 *DEVICE には、"BROWSER" が含まれています。
Natural コンパイラ、エディタ、および Natural システムファイルでは、Unicode でエンコードされたオブジェクトソースはサポートされません。 オブジェクトソース内にコード化された Unicode 定数はデフォルトコードページに保存され、カタログ化オブジェクトに Unicode コードポイントが含まれます。 デフォルトコードページに同等の文字がない Unicode 定数を定義する唯一の方法は、16 進定義（UH）を使用することです。
コードページ変換および Unicode サポートでは、ICU ライブラリが提供する機能が使用されます。 この機能を提供する ICU モジュールのサイズは、使用する ICU 機能に応じて、3～12 MB です。 コードページ変換と Unicode サポートがどちらも必要ない場合は、これらのモジュールを Natural ニュークリアスにリンクする必要はありません。 柔軟性を高めるために、Natural セッションの初期化中に、これらのモジュールを Natural ニュークリアスに動的にリンクすることもできます。 ICU 機能を使用することで、必要な Natural スレッドサイズは、最大 200 KB のストレージ分増加します。
以下では次のトピックについて説明します。
Natural で Unicode およびコードページのサポートを有効にするには、ICU ライブラリモジュールをリンクする必要があります。 Natural には、次に示すように、さまざまな目的のための ICU ライブラリのさまざまな実装があります。
NATICU
この実装を使用する対象は、ほとんどのヨーロッパの国と北米および南米の国です。 英語、ドイツ語、フランス語、およびスペイン語の地域用に、コードページおよびロケール ID が削減されています。 サポート言語が削減されているため、サイズは比較的小さくなっています。
このモジュールのもう一つの特徴は、照合サービスです。 照合サービスは、Unicode 文字列を比較するために使用されます。 照合サービスでは、アルファベット順が言語によって異なることが考慮されています。 世界の言語と表記体系および使用されるさまざまな順序に対応することは、大きな課題です。 ただし、ICU 照合サービスには、ロケールを区別して文字列を比較するすぐれた方法があります。 例えば、文字 "Ä" は、ドイツ語ロケールでは "A" と "B" の間にソートされ、スウェーデン語ロケールでは "Z" の後にソートされます。 リトアニア語では、文字 "y" は "i" と "k" の間にソートされます。 照合サービスの ICU 実装は、Unicode Collation Algorithm に従っており、ISO 14651 に準拠します。 アルゴリズムは、専門家によって複数の照合で設計および確認されているため、堅牢で包括的です。
NATICU は、次の表のコードページおよびロケールを提供します。
NATICUCV
この実装は NATICU と同じですが、照合サービスはありません。照合サービスは、ICU 内で非常に大きなパッケージであるためです。 NATICUCV を使用する場合、ロケールに依存する照合サービスの比較の代わりに、Unicode 文字列に対してバイナリ比較が実行されます。 すべての Unicode データが同じコードページから発生しており、正規化されている場合に、このモジュールを使用できます。
NATICUCV は、次の表のコードページおよびロケールを提供します。
NATICUXL
この実装を使用する対象は、NATICU の削減されたコードページおよびロケール ID に含まれない、世界のすべての地域です。
NATICUXL には、現在サポートされている ICU バージョンによって提供される、すべてのコードページおよびロケール ID が含まれています。 サポートされるコードページおよびロケール ID の概要については、ICU のホームページ（http://demo.icu-project.org/icu-bin/convexp）を参照してください。
NATICU がデフォルトであり、Natural ニュークリアスにリンクされています。 NATICU は、セッションの初期化中に NATICUCV または NATICUXL で置き換えることができます。必要なモジュールをセッションパラメータ RCA（RCA=NATICUCV または RCA=NATICUXL）によってロードします。
NATICU および NATICUCV は、次のコードページおよびロケールを提供します。
| コードページ | ロケール |
|---|---|
|
IBM037 |
de_DE |
パラメータ CFICU および CP を使用して、特定の目的に合わせて Natural を調整できます。
| 設定 | 説明 |
|---|---|
CFICU=OFF、CP=OFF |
互換モード。 Unicode およびコードページのサポートを使用しない既存のアプリケーションを実行するため。 レガシー変換テーブルが I/O 変換に使用されます。 前のバージョンと比較して、リソースの消費（CPU 時間およびバッファ使用率）に大きな増加はありません。 このモードでは、ICU が Natural ニュークリアスにリンクされている必要はありません。 |
CFICU=ON、CP=OFF |
Unicode およびコードページの変換（MOVE ENCODED）を使用するが、デフォルトコードページのサポートを使用しない新規アプリケーション用。 したがって、システム変数 *CODEPAGE は空です。 U フォーマット変数は使用できますが、MOVE A TO U などは使用できません。これにはデフォルトコードページ情報が必要であるためです。 使用できるデフォルトコードページがないことを示すエラー NAT3411 が発行されます。
|
CFICU=ON, CP=value* |
完全な Unicode およびコードページのサポートを使用する新規アプリケーション用。 |
CFICU=OFF, CP=value* |
この組み合わせは可能ですが、無意味です。コードページのサポートには、変換のために ICU サービスが必要であるためです。 したがって、この場合は CFICU=ON が強制され、セッション初期化メッセージが発行されます。
|
* valueは "OFF" 以外の任意の値です。
パラメータ CFICU とそのサブパラメータについては、『パラメータリファレンス』で詳細に説明されています。 一部のサブパラメータは、パフォーマンスに影響します。
Unicode 文字列の比較に照合サービスが使用される場合、両方の文字列は正規化されているかどうかチェックされます。 チェック自体に多くの CPU 時間が消費されます。 文字列がすでに正規化されていることが確実な場合は、チェックをオフ（COLNORM=OFF）に切り替えることができます。
Unicode では、同じ文字を 1 つのコードポイントとして、または 2 つ以上のコードポイントの組み合わせとして表すことができます。 例えば、ドイツ語の文字 "ä" は、"U+00E4" か、コードポイント "U+0061" および "U+0308" の組み合わせで表すことができます。 Unicode から例えば IBM01140 への変換では、組み合わされた文字は 1 つのコードポイントとして処理され、"a" とそれに続く置換文字が生成されます。これは、コードポイント "U+0308" がターゲットコードページで表現されないためです。 CNVNORM=ON では、実際の変換の直前に正規化が実行されます。 正規化では、追加の CPU 時間および一時ストレージが消費されます。 MOVE ステートメント（MOVE NORMALIZED 以外）に結合文字が含まれないことが確実な場合は、CNVNORM を "OFF" に設定してパフォーマンスを向上させる必要があります。 可能なすべての組み合わせが、1 つのコードの Unicode コードポイントで表されます。
Unicode からコードページへの変換、およびその逆の変換のパフォーマンスは高くはありません。 その理由は、ICU 実装が C++ で記述されていることと、世界中のほぼすべての Unicode、コードページ、および言語を対象としていることです。
ただし、変換を速くするために、変換テーブルによって一部のコードページを Unicode に（およびその逆に）マップできます。 アクセラレータテーブルは、CPOPT サブパラメータによってアクティブになります。 "ON" に設定した場合は、Natural によって、セッションの初期化中に ICU 変換機能を使用して、2 つのアクセラレータテーブルが自動的に作成されます。 サイズが 512 バイトの最初のテーブルは、コードページから Unicode への変換に使用され、サイズが
65535 バイトのもう一つのテーブルは、Unicode からコードページへの変換に使用されます。 Natural セッション中、すべての変換は ICU の呼び出しではなく、アクセラレータテーブルによって実行されます。 アクセラレータテーブルは、デフォルトコードページ（*CODEPAGE）に対してのみ提供されます。 （例えば、MOVE ENCODED ステートメントの）一時的なコードページでは、モジュール NATCPTAB がリンクされていない場合、アクセラレータテーブルは使用されません。 このモジュールがリンクされている場合は、ICU データベースに基づく最大 30 個のアクセラレータテーブルが、パフォーマンスを向上させるために使用されます。
Natural ソースは、保存前は Unicode または UTF-8 に変換されないので、以前の Natural バージョンによって読み取ることができます。 Natural バージョン 4.2（以降）のソースの追加コードページ情報は、ソースのヘッダーに保存されます。 ソースが以前の Natural バージョンによってアクセスされた場合、ヘッダーのコードページ情報は無視されるだけです。
コンパイラオプション CPAGE によって、作成時に使用されたコードページとは異なるコードページで実行可能なオブジェクトが作成されます。 つまり、作成時のコードページでコード化されたオブジェクトのすべての英数字定数は、ランタイム時にアクティブなコードページに変換される必要があります。
Natural オブジェクトローダーが英数字定数を検出して変換できるように、コンパイラによって追加のテーブルが作成されます。 このことにより、使用される英数字定数の数に応じて、生成されるオブジェクトのサイズが大きくなります。 ランタイム時の変換では、追加の
CPU 時間が消費されます。 デフォルトコードページ（システム変数 *CODEPAGE の値）が作成時のコードページと同じ場合、またはセッションにデフォルトコードページがない場合（CP=OFF）は、変換は行われません。 パラメータ CPCVERR の設定とは関係なく、変換エラーは無視されます。 コンパイラオプション CPAGE が "OFF" に設定されている場合は、ランタイム時に変換は行われず、英数字定数はそのまま処理されます。
次のサンプルプログラムは、コードページ IBM01141（German）でカタログされ、デフォルトコードページ IBM01140（us）で実行されます。 文字 "Ä"、"Ö"、および "Ü" は両方のコードページで定義されていますが、コードポイントは異なります。
例 1 - CPAGE=OFF：
OPTIONS CPAGE=OFF WRITE *CODEPAGE 'ÄÖÜ' END
コードページ IBM01140（us）を使用した出力：
Page 1
IBM01140 ¢\!
例 2 - CPAGE=ON：
OPTIONS CPAGE=ON WRITE *CODEPAGE 'ÄÖÜ' END
コードページ IBM01140（us）を使用した出力：
Page 1 IBM01140 ÄÖÜ
メインフレーム上の Natural ソースは、Unicode フォーマットではなく、現在の Natural セッションのデフォルトコードページで保存されています。 コードページの名前は、ソースのディレクトリに保存されています。 したがって、以前の Natural バージョンと比較して、ソースのサイズは変わりません。 しかし、ソースのコードページが Natural セッションのデフォルトコードページと同じかどうか、エディタによるチェックが必要です。 コードページが異なる場合は、ソースをデフォルトコードページに変換する必要がありますが、変換エラーが発生する可能性があります。 デフォルトコードページでマップされないソースの文字がある場合、エディタにウィンドウが表示され、失敗した文字を手動で変換できます。 例えば、コード IBM01140 で作成されたソースに、次の行が含まれています。
WRITE '100 €'
このソースをコードページ IBM037 で実行されている Natural で再度編集した場合、文字 "€" がコードページ IBM037 でマップされないため、変換エラーが発生します。
変換は、ソースがロードされるときではなく、エディタが開始されるときに行われることに注意してください。
コードページ名の最も一般的な標準は、IANA 名です。 そのため、システム変数 *CODEPAGE には、デフォルトコードページの IANA 名が含まれています。 IBM の場合、コードページはその Coded Character Set ID（CCSID）で修飾されています。 Siemens の場合、Coded Character Set
Name（CCSN）が最も一般的です。 現在、Adabas では Entire Conversion Service 定義（ADAECS）が使用されています。 マクロ NTCPAGE を使用すると、これらの異なる名前を明確な IANA 名に割り当てることができます。 NTCPAGE は、Natural コンフィグレーションファイル（NATCONFG）の一部です。
CP パラメータは、Natural コンフィグレーションファイルに定義されている値のみを受け入れます。 CP パラメータで入力されるのが IANA 名か、CCSID/CCSN か、エイリアス名かは重要でありません。 エイリアス名には、より意味のある名前をコードページに割り当てるために使用するユーザー定義名が可能です。 いずれの場合にも、*CODEPAGE には、選択されたコードページの IANA 名が含まれます。
また、コードページに対してプレースホルダ文字を定義できます。 これにより、そのコードページのデフォルトの置換文字が上書きされます。デフォルトの置換文字は、通常は非表示文字です（EBCDIC コードページの H’3F’ など）。 プレースホルダ文字は、非表示文字が端末に送信されるのを防ぐために使用できます。
例：
NTCPAGE IANA=IBM01140,CCSID=1140,ECS=1140,ALIAS=’US’,PHC=003F
値 "IBM01140"、"1140"、または "US" を CP パラメータを使用して入力して、コードページをアクティブにすることができます。 *CODEPAGE には、名前 IBM01140 が含まれます。 コードページの置換文字は、引用符（?）である "U+003F" によって置き換えられます。
使用できるコードページの数は、使用される ICU 実装によって異なります。
Natural バージョン 4.2.5 以降および ICU バージョン 3.8 以降ではそれぞれ、該当する NTCPAGE エントリを省略できます。 その代わりに、現在使用されているデータパッケージ内に定義されているすべてのコードページを Natural で使用できます。 NTCPAGE エントリが必要となるのは、代替エイリアス名またはプレースホルダ文字が必要な場合のみです。
Adabas は、幅広いコードページをサポートし、世界中の言語を扱うことができます。 文字エンコードおよびデータ変換は、Adabas の内部で処理されます。このとき、ストレージ（ファイルエンコード）とユーザーへの表示（ユーザーエンコード）用のデフォルトエンコードとして
Unicode が使用されます。 コードページまたは Unicode のサポート（CFICU=ON）がセッションに対して強制される場合、Natural アプリケーションはユーザーエンコードを指定し、それをこのセッションが開かれるときに（OP コマンド）Adabas ニュークリアスに伝える必要があります。 ADALNK モジュールにより、呼び出し元の設定に応じて Adabas バッファデータが変換されます。 メインフレームでは、ICU ではなく Entire Conversion Services（ECS）が変換に使用されます。 オープンシステムでは、ICU
が Adabas によって使用されます。 したがって、NATCONFG の関連する NTCPAGE エントリに ECS 名が定義されている必要があります。 データベースが開かれるときに、Natural ニュークリアスによって OP コマンドが送信されます。メインフレームバージョンの Adabas では、レコードバッファ内のすべての A フィールドの ACODE 設定およびすべての W フィールドの WCODE 設定（UTF-16 を意味する 4095）とともに送信されます。オープンシステムバージョンの Adabas では、レコードバッファ内の WCHARSET 設定とともに送信されます。 ACODE/WCODE オプションは、このデータベースの OPRB パラメータに定義されている必要があります。
Adabas 変換の詳細については、OP コマンドの説明および Adabas のメインフレームドキュメントで提供されている UES（ユニバーサルエンコーディングサポート）エンコードの情報を参照してください。
Natural では、文字変換および文字タイプ定義にさまざまなテーブルが使用されます。 テーブルの内容は、Natural セッションの開始時にセッションパラメータ（TAB、UTAB1、UTAB2、および SCTAB）を使用して変更できます。
Natural がコードページサポートを使用して実行されている（つまり、パラメータ CP が "ON"、"AUTO"、またはコードページの名前に設定されている）場合、ユーザーはテーブルを変更できません。 この場合、前述のセッションパラメータが考慮されないことをユーザーに通知するために、次の Natural 起動メッセージが発行されます。
CFICU=ON が設定されているため、文字変換パラメータ table-name は無視されました。
Natural により、デフォルトコードページ（システム変数 *CODEPAGE の値）の要件に合わせてテーブルは自動的に調整されます。 『オペレーション』ドキュメントの「変換テーブル」も参照してください。
Natural では、EBCDIC および DBCS に基づく日本語コードページである IBM-939 などのマルチバイトコードページ（MBCS）がサポートされます。 マルチバイトコードページは、CP パラメータを使用して選択できます。CP を "AUTO"（サポートされている場合）またはコードページの名前に設定します。 Natural がマルチバイトコードページを使用して実行されている場合、Unicode に基づく内部 I/O バッファが使用されます。 つまり、I/O ステートメントによって内部
I/O バッファに書き込まれるすべてのデータは、Unicode に変換されます。 Unicode およびマルチバイトコードページの要件のために、I/O バッファのサイズは従来の I/O と比較して大きくなります。これは、Unicode 文字には
EBCDIC 文字の 2 倍のスペースが必要であり、フィールドを説明するために拡張属性が必要であるためです。
IBM-1140 などのシングルバイトコードページ（SBCS）の場合は、リソースを保持するために従来の EBCDIC ベースの I/O がまだ使用されています。