| キャラクタセット |  |
| キャラクタセットとは、母国語の単語やその他の基本単位の構成に使用されるアルファベットなどの文字の集合です。 Infor ERP LN アプリケーションのインストール中に、キャラクタセットを選択する必要があります。ERP LN 環境全体に 1 つのキャラクタセットだけが適用されます。したがって、選択したキャラクタセットでサポートされている言語しか保存できません。 以下の種類のキャラクタセットから選択できます。 シングルバイトキャラクタセット マルチバイトキャラクタセット Unicode キャラクタセット シングルバイトキャラクタセット シングルバイトキャラクタセットは、キャラクタ情報の保存に 1 バイトだけ必要です。したがって、最大 256 文字を使用できます。ISO 8859 標準では、主にヨーロッパ言語の文字を処理するためにロケールとも呼ばれる複数のキャラクタセットを定義しています。 以下はシングルバイトキャラクタセットの例です。 ISO 8859-1: 主にフランス語、ドイツ語、イタリア語などの西ヨーロッパ言語 ISO 8859-5: キリル言語 (ロシア語) をサポート 下位 000 ～ 127 のキャラクタ範囲はすべての ISO 8859 キャラクタセットと同じで、上位 128 ～ 255 のキャラクタ範囲はロケールごとに異なります。 アルファベットは下位の範囲にエンコードされるため、英語は ISO 8859 の各ロケールでサポートされています (英語には追加のキャラクタは不要)。 ソートはバイナリベース: ソートはエンコードでキャラクタが定義される順序にもとづいて行われます。たとえば、大文字の英字がすべてソートされてから、小文字の英字がソートされます。たとえば、｢Z｣ は ｢a｣ の前にソートされます。 マルチバイトキャラクタセット 通常、256 文字を超える言語にはマルチバイトキャラクタセットが必要です。典型的な例は中国語です。ERP LN の場合は、マルチバイトキャラクタセットには 1 文字につき 4 バイト必要です。 以下はマルチバイトキャラクタセットの例です。 BIG5: 中国語 Wansung: 韓国語 ソートはバイナリベースです。 Unicode キャラクタセット Unicode キャラクタセットはすべての (現代) 言語をサポートしている標準化キャラクタセットです。これにより、1 つの ERP LN 環境内で小さい言語セットしかサポートできないという制限がなくなります。キャラクタセットとして Unicode を選択すると、1 つの ERP LN 環境でたとえば中国語、英語、フランス語を使用できます。 Unicode キャラクタセットのもう一つの利点は、言語のソートルールが付属することです。ソート形式で表示する必要があるデータは、ICU 標準で定義されているソートルールに従って示されます。 注意 ICU 標準では、ERP LN のツールでサポートされていない特定の言語に合わせてソートルールを微調整する ｢調整｣ も定義しています。 その結果、Unicode ベースの ERP LN 環境のデータベースサイズは、マルチバイトまたはシングルバイトベースのキャラクタセットに比べて大きく、システムの CPU とメモリの負荷も大きくなります。通常、複数の言語をサポートする必要があり、言語のソートを優先する場合に Unicode が選択されます。 拡張 Ascii 許可 重要 以下のことは、Unicode モードで実行していない ERP LN 環境にのみ当てはまります。 以下の状況では、high_ascii_tolerance リソースを 0 に設定する必要があります。 ERP LN 環境が運用環境であり、しかも環境を Unicode に変換する予定の場合 ERP LN 環境が開発環境であり、しかもソフトウェア構成要素または翻訳をそこから配布する予定の場合。high_ascii_tolerance が 0 に設定されていない場合、配布された構成要素が Unicode 環境にインポートされると問題が発生します。 high_ascii_tolerance を 0 に設定するには、$BSE/lib/defaults/all ファイルに次の行を追加します。 `high_ascii_tolerance:0` ユーザロケールの役割 このセクションでは、以下のタイプのインストールにおけるユーザロケールの役割について説明します。 シングルバイト マルチバイト Unicode 重要 ユーザごとに異なるロケールを定義することは、技術的には可能です (User Data Template (ttams1110m000) セッション)。ただし、これが問題の原因となる可能性があります。そのため、Infor では複数のユーザロケールをサポートしていません。したがって、ERP LN 環境内のすべてのユーザが同じユーザロケールを持っている必要があります。 シングルバイトインストールにおけるユーザロケールの役割 シングルバイトインストールでは、ユーザロケールは、アプリケーション全体で使用できるキャラクタセットを定義します。 重要 Infor では、以下のことを強くお勧めします。 データベースで使用されるキャラクタセットに対応するユーザロケールを使用する。この方法で、｢サードパーティ｣ のデータベースツールはデータにアクセスできます。 バイナリソート順序 (照合ともいいます) を定義するロケールを使用する。 データベースでも同様に、バイナリソート順序を選択する。たとえば、西ヨーロッパ諸国では、ISO_BIN1 ロケールを使用できます。このロケールのキャラクタセットは ISO-8859-1 ロケールと同じですが、ソート順序はバイナリです。 すべてのユーザが同じユーザロケールを持っていることを確認する。これは、ツールやポーティングセットによって強制的に行われるものではありません。 ユーザロケールは、以下のことに影響します。 データベース内でのデータの保存方法。ユーザロケールは、シングルバイト文字の保存に使用されるコードポイントを決定します。 一部の bshell (3GL) 関数 mb.locale.info()。TSS_GET_IFACTOR および TSS_GET_EFACTOR のアスペクトを含めます。 set.min() set.max() set.fmin() set.fmax() BWPrint の 非 Unicode バージョン。適切な Windows コードページに変換する必要があります。注意: データを ISO ロケールから Windows コードページに変換するために、BWPrint は ユーザロケールの _WIN32 バージョンを使用します。 マルチバイトインストールにおけるユーザロケールの役割 マルチバイトインストールでは、ユーザロケールは、アプリケーション全体で使用できるキャラクタセットを定義します。 重要 Infor では、以下のことを強くお勧めします。 データベースで使用されるキャラクタセットに対応するユーザロケールを使用する。このキャラクタセットはバイナリソートを使用する必要があります。 データは、ユーザロケールのキャラクタセットを使用して、データベースに格納されます。データベースが正しい方法で文字を処理できるように、データベースに対して正しいキャラクタセットが指定されていることを確認します。この方法で、｢サードパーティ｣ のデータベースツールはデータにアクセスできます。この方法以外では、データは文字化けして見える場合があります。 すべてのユーザが同じユーザロケールを持っていることを確認する。これは、ツールやポーティングセットによって強制的に行われるものではありません。ユーザロケールがさまざまである場合、あるユーザが、異なるユーザロケールを持つ別のユーザのデータを処理すると、変換エラーが発生します。これは、主に、データベースとの間での書き込み/読み取りプロセスに影響します。結果的に、ユーザロケールは、データベースと通信するあらゆる統合に影響します。 ユーザロケールは、以下のことに影響します。 ｢ネイティブ｣ 形式 (MBCS) から TSS へ (またはその逆) のデータ変換。ユーザロケールが用語 ｢ネイティブ｣ の意味を決定します。 データベース内でのデータの保存方法。ユーザロケールは、マルチバイト文字の保存に使用されるコードポイントを決定します。 一部の bshell (3GL) 関数 mb.import$()。この関数は、データを ｢ネイティブ｣ 形式から TSS に変換します。 mb.export$()。この関数は、データを TSS から ｢ネイティブ｣ に変換します。 utf8.export$()。BaanIV ポーティングセットは、｢ネイティブ｣ 形式を中間形式として使用して、TSS から UTF-8 に変換します。ユーザロケールがデータと一致しない場合、これは変換エラーになることがあります。 mb.width()。この関数は、文字列の幅を返します。この場合、幅は ｢表示位置の数｣ で定義されます。たとえば、ISO8859n キャラクタセットで、｢アクセント記号付きのラテン小文字 e｣ 文字は 1 つの表示位置を占めます。しかし、GB2312 キャラクタセットでは、2 つの表示位置を占めます。 mb.locale.info()。TSS_GET_IFACTOR および TSS_GET_EFACTOR のアスペクトを含めます。 set.min() set.max() set.fmin() set.fmax() ログメッセージの表示。ログメッセージのテキストは、TSS キャラクタセットから ｢ネイティブ｣ 形式に変換されます。 BWPrint の非 Unicode バージョン。この場合、TSS データを ｢ネイティブ｣ 形式に変換する必要があります。 Unicode インストールにおけるユーザロケールの役割 Unicode キャラクタセットの導入以後、ユーザロケールの役割はさほど重要でなくなりました。純粋な Unicode 環境では、すべての文字が一意のコードポイントで表されます。すべてのコードポイントに、一意の解釈があります。ただし、Unicode との間での変換が発生する領域はまだいくつか存在しています。 例 Unicode 環境で作業を行います。しかし、個人的なユーザロケールは ISO8859 です。Unicode 環境と別の環境との間でデータを交換する必要があります。Unicode 環境 (たとえば ERP LN Data Director (つまり EDI)) からエクスポートを実行した場合、エクスポートファイルは ISO8859 形式です。 ユーザロケールは、以下のことには影響しません。 データベース内でのデータの保存方法。マルチバイト列内のすべてのデータは Unicode で保存されます。シングルバイト列内のデータは Unicode で ｢そのまま｣ 保存されます。事実上、ISO-8859-1 ロケールで解釈されます。たとえば｢ラテン文字 A｣ は、Unicode コードポイント 0x41 として保存されます。コードポイント 0x9e は Unicode コードポイント 0x9e として保存されます。このコードポイントは、｢アクセント記号付きのラテン小文字 e｣ 文字 (é) を表します。 bshell の通常の動作。これには、以下の関数は含まれません。 mb.export$() や mb.import$() などの変換関数 mb.locale.info() など、現在のユーザロケールに関する情報を獲得するための関数 注意: 以下の関数は、ユーザロケールの影響を受けません。 set.min() set.max() set.fmin() set.fmax() ログメッセージの表示。ログメッセージのテキストは、UTF-T 形式から UTF-8 形式に変換されます。 BWprint の Unicode バージョン ユーザロケールは、bdbpre ユーティリティによって作成されたダンプファイルにいくらか影響します。bdbpre ダンプファイル内のテキストは、UTF-8 キャラクタセットのものになります。データベースに ｢拡張 ascii｣ 文字が含まれている場合、これらの文字は、現在のユーザロケールに照らして変換されます。high_ascii_tolerance リソースはこのプロセスに影響しません。詳細については、以下の ｢拡張 ascii｣ 文字の変換に関する解説を参照してください。 ユーザロケールは、以下のことに影響します。 ｢ネイティブ｣ 形式 (MBCS) から Unicode (UTF-T) へ (またはその逆) のデータの変換。ユーザロケールが用語 ｢ネイティブ｣ の意味を決定します。 いわゆる ｢拡張 ascii｣ 文字の変換。以下を参照してください 一部の bshell (3GL) 関数 mb.import$()。この関数は、データを ｢ネイティブ｣ 形式から UTF-T に変換します。 mb.export$()。この関数は、データを UTF-T から ｢ネイティブ｣ 形式に変換します。 mb.width()。この関数は、文字列の幅を返します。この場合、幅は ｢表示位置の数｣ で定義されます。たとえば、ISO8859n キャラクタセットで、｢アクセント記号付きのラテン小文字 e｣ 文字は 1 つの表示位置を占めます。しかし、GB2312 キャラクタセットでは、2 つの表示位置を占めます。 mb.locale.info()。TSS_GET_IFACTOR および TSS_GET_EFACTOR のアスペクトを除きます。 BWPrint の非 Unicode バージョン。この場合、UTF-T データを ｢ネイティブ｣ 形式に変換する必要があります。この結果、変換エラーが発生する可能性があります。｢ネイティブ｣ キャラクタセットは制限付きの UTF-T のサブセットのみをサポートしているためです。したがって、Infor では、Unicode インストールで BWPrint の Unicode バージョンを使用するようお勧めします。 ｢拡張 ascii｣ 文字の変換 ｢拡張 ascii｣ 文字の存在は問題を引き起こします。1 つのコードポイントが異なるキャラクタセットでさまざまな意味を持つ可能性があるためです。 例 ISO-8859-1 ロケールでは、コードポイント 0xe9 (10 進数の 233) は ｢アクセント記号付きのラテン小文字 e｣ 文字 (é) として解釈されます。 ISO-8859-7 ロケールでは、このコードポイントは ｢ギリシャ小文字イオタ｣ 文字 (ι) として解釈されます。 ｢拡張 ascii｣ 文字の意味を判別するために、ERP LN では現在のユーザロケールが使用されます。ユーザロケールが ISO8859n バリアントの場合、正しい意味を判別するのに、このキャラクタセットが使用されます。それ以外の場合は、ISO85591 キャラクタセットが使用されます。 例 ユーザロケールは ISO88597 です。文字列に 0xe9 コードポイントが入っており、UTF-T への変換が必要です。このコードポイントは ｢ギリシャ語小文字イオタ｣ 文字 (ι) として解釈されます。その結果として生じる UTF-T コードポイントは 0x9bbc87b9 です。 ユーザロケールが ISO88591 で、同じ文字列を変換する必要があります。このコードポイントは ｢アクセント記号付きのラテン小文字 e｣ 文字として解釈されます。その結果として生じる UTF-T コードポイントは 0x9bbc81e9 です。 Infor では、インストールに ｢拡張 ascii｣ 文字を使用しないようお勧めします。このためには、high_ascii_tolerance リソースを 0 に設定します。 |