国際文字を使って文字列を表現し処理するには、GT.Mプロセスは、Unicodeを利用できます。
UTF-8およびLC_ALLまたはLC_CTYPEのどちらかの値を持つ環境変数 gtm_chset がUTF-8サポート（例えば、zh_CN.utf8）をするロケールで設定されている場合は、GT.Mプロセスは、UTF-8表現でエンコードされる文字を含むように、文字列を解釈します。UTF-8モードでは、GT.Mは、もはや1文字が1バイトであることを前提としていないし、または、文字のグリフ(表意文字)表示幅が1です。ICUはコンピュータシステム上に構築されている方法に応じて、UTF-8モードで動作するためには、GT.Mプロセスは、3番目の環境変数を必要とするかもしれない、gtm_icu_version を適切に設定します。
環境変数 gtm_chset に、値が無い、文字列 "M"、または、"UTF-8" 以外の値の場合、GT.Mは1バイトを8ビットとして扱い、英語圏や多くの単一言語のアプリケーションでは十分に足ります。
Mモードに関連するすべてのGT.Mコンポーネントは、GT.Mリリースがインストールされている最上位レベルのディレクトリと、環境変数 gtm_dist で、Mモードのプロセスがそのディレクトリにするはずのポイントに属します。すべてのUnicode関連のコンポーネントは、utf8 サブディレクトリに存在し、環境変数 gtm_dist は、UTF-8モードのプロセスのためのそのサブディレクトリを指す必要があります。したがって、環境変数 gtm_chset と LC_ALL / LC_CTYPEに加えて、UTF-8プロセスのための gtm_dist 値 もまた utf8 サブディレクトリを指している必要があります。
MモードとUTF-8モードは、データベースに対してでは無く、プロセスのために設定されます。Unicodeのサブセットとして、ASCII文字（ $CHAR() が 0〜127の値）は、MとUTF-8モードでのプロセスでは、同一に解釈されます。データベースのインデックスと値は、単純にバイトのシーケンスであり、したがってそれは、一つはUTF-8でのエンコードとしてグローバルノードを解釈するプロセスとして可能で、そして、他はバイトコードとして同じノードを解釈するため可能です。このようなアプリケーションの構成は、おそらく移行フェーズ中またはデータのインポート/エクスポートの接続を除いては、極めて異例となることに、注意してください。
UTF-8モードでは、文字列処理関数（$EXTRACT()など）は、マルチバイト文字列で動作するため、処理される実際のデータに応じて MおよびUTF-8モードで異なる結果が生成されます。各関数には、MおよびUTF-8モード（ すなわち、Mモードで$EXTRACT と同様にふるまう UTF-8モードでの$ZEXTRACT ）で、一連のバイトを同じように操作するために使用できる "Z" とそれに続く自分自身（例えば、$ZEXTRACT）があります。
Mモードでは、不正な文字の概念は存在しません。UTF-8モードでは、一連のバイトが有効な文字を表していない可能性があり、UTF-8文字列を予期して処理する関数によってはエラーが発生します。Unicode サポートを追加するためのアプリケーションの移行時には、不正な文字のエラーが、まだ変更されていないアプリケーションコードが頻繁に示しています。VIEW "NOBADCHAR" は、それら存在が開発を妨げる時間に、これらのエラーを抑制します。
UTF-8モードでは、GT.Mは、 $PRINCIPAL以外のデバイスからの文字エンコーディングごとに従来の1バイトと同様に、UTF-16 バリエーションを IO エンコードもサポートします。
次の表は、GT.M Unicode サポートをまとめたものです。
|
拡張機能 |
説明 |
|---|---|
|
$ASCII() |
UTF-8モードで、$ASCII() 関数は、与えられた文字列内の文字の整数Unicodeのコードポイントの値を返します。$ASCII() の名前は、Unicodeデータに対してやや変則的ですが、その名前が、MモードからUTF-8モードへ関数を論理的に拡張したものであることに注意してください。詳細な情報と使用例は、 “$ASCII()” を参照してください。 |
|
$Char() |
UTF-8モードでは、$CHAR() は、その引数（複数可）で指定されたUnicodeコードポイントの対応する整数値で表される文字で構成される文字列を返します。詳細な情報と使用例については、 “$Char()” を参照してください。 |
|
$Extract() |
$EXTRACT() 関数は、与えられた文字列の部分文字列を返します。詳細な情報と使用例については、“$Extract()” を参照してください。 |
|
$Find() |
$FIND() 関数は、その位置の文字列内の部分文字列の出現を整数文字位置を返します。 詳細な情報と使用例については、 “$Find()”を参照してください。 |
|
$Justify() |
$JUSTIFY 関数はフォーマットされた文字列を返します。詳細な情報と使用例については、“$Justify()” を参照してください。 |
|
$Length() |
$LENGTH() 関数は、文字で、または、オプションの第二引数で指定した区切り文字によって区切られた" pieces"で、測定される文字列の長さを返します。 詳細な情報と使用例については、“$Length()”を参照してください。 |
|
$Piece() |
$PIECE() 関数は、区切り文字は、1つまたは複数の文字で構成された、指定した文字列が部分文字列の区切りを返します。詳細な情報と使用例については、 “$Piece()”を参照してください。 |
|
$TRanslate() |
$TRANSLATE()関数は、引数の最初の文字を置換または削除の結果は、そのほかの引数のパターンで指定された文字列を返します。詳細な情報と使用例については、 “$TRanslate()” を参照してください。 |
|
$X |
UTF-8モードとTRMとSD出力のために、現デバイスへ書き込まれる与えられた文字列の表示カラム（グリフの幅）によって、$Xが増加します。詳細な情報と使用例については、“$X”を参照してください。 |
|
$ZASCII() |
$ZASCII ()関数は、オクテット（8ビットのバイト）で指定されたシーケンスの数値バイト値（0〜255）を返します。詳細な情報と使用例については、“$ZAscii()”を参照してください。 |
|
$ZCHset |
読み取り専用の固有の特殊変数 $ZCHSETは、環境変数gtm_chsetから値を取得します。アプリケーションは、$ZCHSETの値によってGT.Mプロセスによって使用される文字セットを取得することができます。$ZCHSETは、2つの値だけを持つことができます - "M"、または、"UTF - 8" とそれは、SETコマンドの等号の左側に表示することはできません。詳細な情報と使用例については、“$ZCHset”を参照してください。 |
|
$ZCHar() |
$ZCHAR() 関数は、その引数で指定された数値バイト値（0〜255）に対応する1つ以上のバイトのバイトシーケンスを返します。詳細な情報と使用例については、“$ZCHar()”を参照してください。 |
|
$ZCOnvert() |
$ZCONVERT() 関数は、異なったエンコーディングに変換された文字列として、第1引数を返します。2つの引数の形式は、文字セット内の大文字小文字のエンコーディングを変更します。3つの引数の形式は、符号化方式を変更します。詳細な情報と使用例については、“$ZCOnvert()”を参照してください。 |
|
$ZExtract() |
$ZEXTRACT() 関数は、オクテット（8ビットバイト）の与えられたシーケンスのバイトシーケンスを返します。詳細な情報と使用例については、“$ZExtract()”を参照してください。 |
|
$ZFind() |
$ZFIND ()関数は、オクテット（8ビットバイト）のシーケンス内のバイトのシーケンスの発生位置の整数のバイト位置を返します。詳細な情報と使用例については、“$ZFind()”を参照してください。 |
|
$ZJustify() |
$JUSTIFY() 関数は、フォーマットされた固定長のバイトシーケンスを返します。詳細な情報と使用例については、“$ZJustify()”を参照してください。 |
|
$ZLength() |
$ZLENGTH() 関数は、バイト単位で、または、オプションの第二引数で指定した区切り文字によって分けられた"pieces(断片)"で、測定されたオクテットのシーケンスの長さを返します。詳細な情報と使用例については、“$ZLength()”を参照してください。 |
|
$ZPATNumeric |
ZPATN[UMERIC] は、パターンマッチ演算子で使用される GT.Mがどのようにpatcode N を解釈するかその方法を決定する読み取り専用の固有の特別な変数です。$ZPATNUMERIC="UTF-8" で、patcode Nは、Unicodeで定義されているように任意の数値文字にマッチします。デフォルトでは、patcode N は、Mは実際に数値として扱われるだけの数字であるASCII数字を一致します。詳細な情報と使用例については、“$ZPATNumeric”を参照してください。 |
|
$ZPiece() |
$ZPIECE()関数は、1つ以上のバイトで構成される、指定されたバイトシーケンスによって、バイトの区切りのシーケンスを返します。Mでは、$ZPIECE() は一般的に論理レコードから論理フィールドを返します。詳細な情報と使用例については、“$ZPiece()”を参照してください。 |
|
$ZPROMpt |
$ZPROM [PT] は、ダイレクトモードの現在のプロンプトを指定する文字列の値が含まれています。デフォルトは、GTM> がダイレクトモードのプロンプトです。Mルーチンは、SETコマンドによって$ZPROMPTを変更することができます。$ZPROMPTは31バイトを超えることはできません。もし長い文字列に$ZPROMPTを割り当てようとしている場合、GT.Mは最初の31バイトを受け取り、残りを切り捨てます。もし31バイト目が有効なUTF-8文字の終わりではない場合、指定されたUTF-8の文字セットでは、GT.Mは完全に31バイトの制限内に収まる最後の文字の末尾に$ZPROMPT値を切り捨てます。詳細な情報と使用例については、“$ZPROMpt”を参照してください。 |
|
$ZSUBstr() |
$ZSUBSTR() 関数は、バイトのシーケンスから適切にエンコードされた文字列を返します。詳細な情報と使用例については、“$ZSUBstr()” を参照してください。 |
|
$ZTRanslate() |
$ZTRANSLATE()関数は、その他の引数のパターンによって指定された、その引数の最初のバイトを、置換したり省略したりする結果として、バイトシーケンスを返します。$ZTRANSLATE() は、暗号化などのタスク用のツールを提供します。詳細な情報と使用例については、“$ZTRanslate()” を参照してください。 |
|
$ZWidth() |
$ZWIDTH() 関数は、画面やプリンタ上へ文字列を表示するために必要な列の数を返します。詳細な情報と使用例については、“$ZWidth()” を参照してください。 |
|
%HEX2UTF |
GT.Mの %HEX2UTFユーティリティは、16進表記で指定されたバイトストリームからGT.MのUTFエンコードの文字列へ変換します。このルーチンは、対話的または非対話的のどちらの使用でのエントリポイントがあります。詳細な情報と使用例については、“%HEX2UTF” を参照してください。 |
|
%UTF2HEX |
GT.M の %UTF2HEX ユーティリティは、UTF-8でエンコーディングされたGT.M文字列の内部エンコーディングのバイトの16進表記で返します。このルーチンは、対話的または非対話的のどちらの使用でのエントリポイントがあります。詳細な情報と使用例については、“%UTF2HEX” を参照してください。 |
|
[NO]WRAP (USE) |
自動記録の終了を有効または無効にします。現在のレコードのサイズ($X)が最大 WIDTHに達し、かつ、デバイスがWRAPを有効になっている時に、ルーチンがWRITE ! コマンドを発行したかのように、GT.Mは新しいレコードを開始します。 詳細な情報と使用例については、“WRAP” を参照してください。 |
|
DSE と LKE |
UTF-8モードでは、DSEとLKEは、ファイル名、キー、またはデータ（ DSE -KEY、DSE -DATA、LKE -LOCKの修飾子などのような）を必要とするすべてのそれらのコマンド修飾子で、Unicodeの中で文字を受け入れます。より多くの情報および使用例については、 GT.M管理および操作ガイド の LKEとDSEの章を参照してください 。 |
|
GDE オブジェクト |
GDEは、ファイルの名前にUnicode 文字を含めることができます。 UTF-8モードでは、GDEは、それが "@" コマンド経由で実行されたときに、UTF-8でエンコードされているテキストファイルとみなします。詳細については、 GT.M管理および操作ガイド のGDEの章を参照してください。 |
|
FILTER[=expr] |
FILTER が適用されるデバイス上で、指定されたカーソル移動シーケンスの文字フィルタリングを指定します。 UTF-8モードでは、通常のUnicodeライン・ターミネータが認識されます (U+000A (LF), U+0000D (CR), U+000D followed by U+000A (CRLF), U+0085 (NEL), U+000C (FF), U+2028 (LS) and U+2029 (PS) )。もしFILTER=CHARACTER が有効な場合、すべてのターミネータは $Xと $Yの値を維持するために認識されます。フィルターの詳細については、“フィルター” を参照してください。 |
|
Job |
Jobコマンドは、MのプロセスがDOで生成されるように同じ環境でバックグラウンドプロセスを生成します。そのため、もし親プロセスがUTF-8モードで動作している場合、JobプロセスもUTF-8モードで動作します。バックグラウンド・プロセスが親プロセスと異なるモードでなければならない場合は、必要に応じて環境を変更するためのシェル・スクリプトを作成し、ZSYstemコマンド 例：ZSYstem "/path/to/shell/script &", 、またはPIPEデバイスとして起動します。詳細およびUTF-8モードの例については、 “ジョブ”. を参照してください。 |
|
MUPIP |
MUPIP EXTRACT UTF-8モードでは、MUPIP EXTRACT, MUPIP JOURNAL -EXTRACT と MUPIP JOURNAL -LOSTTRANS はUTF-8文字エンコード形式でシーケンシャル出力ファイルを書き込みます。たとえば、^A の値が 主要雨在西班牙停留在平原 の場合、UTF-8モードでは、MUPIP EXTRACT コマンドのシーケンシャル出力ファイルは次のようになります： 09-OCT-2006 04:27:53 ZWR GT.M MUPIP EXTRACT UTF-8 ^A="主要雨在西班牙停留在平原" MUPIP LOAD もし環境変数 gtm_chsetがUTF-8に設定されている場合、MUPIP LOADコマンドは、UTF-8でエンコードされたとして、シーケンシャルファイルと見なします。MUPIP EXTRACTコマンドと対応するMUPIP LOADコマンドは、環境変数 gtm_chset に同じ設定で実行されることを確認します。M ユーティリティプログラム %GOと%GI は、モードマッチングのために同じ要件があります。MUPIP EXTRACT とMUPIP LOADの詳細については、 GT.M管理および操作ガイド の一般的なデータベース管理の章を参照してください。 |
|
Open |
UTF-8モードでは、OPENコマンドは、入力/出力デバイスのエンコーディングを決定するための追加の3つデバイスパラメータとしてICHSET、OCHSET、およびCHSETを認識します。詳細情報と使用例については、“Open” を参照してください。 |
|
パターンマッチ演算子 (?) |
GT.Mは、Unicode文字を含めるパターン文字列リテラルを可能にします。さらに、GT.Mは、Unicode文字セットをM標準パターンコード（patcodes）A、C、N、U、L、P、Eに追加拡張します。詳細については、“パターンマッチ演算子” や “$ZPATNumeric”を参照してください。 |
|
Read |
UTF-8モードで、READコマンドは、入力デバイスの文字エンコーディングとしてOPENデバイスで指定された文字セットの値を使用しています。もし文字セットが "M"または"UTF-8"に指定されている場合、データは変換なしで読み込まれます。もし文字セットが"UTF-16"、"UTF-16LE"、"UTF-16BE"の場合、データは指定されたエンコーディングで読み込み、UTF-8に変換されます。もしREADコマンドが、不正な文字または選択された表現以外の文字を検出した場合、それは実行時エラーがトリガされます。READコマンドは、固定されていないデバイスではすべてのUnicodeの行ターミネータを認識します。詳細と使用例については、“Read” を参照してください。 |
|
Read # |
番号記号(#) と非ゼロの整数式が変数名の直後に続く時は、整数式はREADコマンドの入力として受け入れられる文字の最大数を特定します。UTF-8またはUTF-16モードでは、これは、コードポイント（通常は非スペーシングのうちのいくつか）の組み合わせのシーケンスの最中で発生できます。入力デバイス上の任意の表示が発生する時、固定長のREAD ( READ #) で返される文字を表すものではありません。詳細と使用例については、“Read” を参照してください。 |
|
Read * |
UTF-8またはUTF-16モードでは、READ *コマンドは、入力のUnicodeで1文字を受け取り、変数にその文字の数値コードポイントの値を入れます。詳細と使用例については、“Read” を参照してください。 |
|
View "[NO]BADCHAR" |
Unicodeへのアプリケーションの移行の助けとして、このUTF-8モードのVIEWコマンドは、それらが不正なな文字列に遭遇した時、Unicode対応の関数がエラーをトリガするかどうかを決定します。詳細と使用例については、“View” を参照してください。 |
|
ユーザ定義の照合順序 |
一部の言語（中国語など）の場合では、Unicodeのコードポイント（文字値）に従っている文字列の順序は、言語的または文化的に正しい順序付けができない場合があります。そのような言語の中でサポートしているアプリケーションでは、照合モジュールの開発が必要です - GT.MはネイティブなM照合をサポートしていますが、特定の自然言語のためのビルド済みの照合モジュールは含まれていません。そのため、Unicodeで文字を使用するアプリケーションは、それら独自の照合関数を実装する必要があります。Unicodeの照合順序モジュールの開発の詳細については、 “Unicodeの代替照合順序の実装” を参照してください。 |
|
ユニコード・ バイト・オーダ・マーカー（BOM） |
ICHSETがUTF-16の場合、GT.MはBOM（U+FEFF）を使用してエンディアンを自動的に決定します。これを行うには、BOMをファイルまたはデータ・ストリームの先頭に表示する必要があります。もし BOMが存在しない場合、GT.Mは大きなエンディアンを仮定します。SEEKまたはAPPEND操作では、エンディアン（UTF-16LEまたはUTF-16BE）を指定する必要があります。これは、エンディアンを自動的に判別するためにファイルまたはデータストリームの先頭に移動しないためです。エンディアンが指定されていない場合、SEEKまたはAPPENDは大きなエンディアンを想定します。 もしデバイスのキャラクタ・セットがUTF-8の場合、GT.Mは入力時のBOMをチェックして無視します。 もしBOMがデバイスOPENで指定された文字セットと一致しない場合、GT.Mはエラーを生成します。READはBOMをアプリケーションに戻さず、BOMは最初のレコードの一部としてカウントされません。 もしデバイスの出力文字セットがUTF-16（ただしUTF-16BEまたはUTF-16LEではない）の場合、GT.Mは最初の出力の前にBOMを書き込みます。アプリケーションコードは、BOMを明示的に記述する必要はありません。 |
|
WIDTH=intexpr (USE) |
UTF-8モードとTRMとSD出力では、WIDTH デバイスパラメータは表示列を指定し、ストリームを視覚的に表現する切り捨て( truncation )とWRAPingを制御するために $X を使用します。詳細と使用例については、“WIDTH”を参照してください。 |
|
Write |
UTF-8モードで、WRITEコマンドは、出力デバイスの文字エンコーディングとしてOPENデバイスで指定された文字セットを使用します。もし文字セットが"M"または"UTF-8"を指定している場合、GT.Mは変換なしでデータを書き込みます。もし文字セットが "UTF-16"、"UTF-16LE"、"UTF-16BE" を指定している場合、データはUTF-8でエンコードされていると仮定し、WRITEは文字セットのデバイスパラメータで指定された文字エンコーディングに変換します。詳細と使用例については、 “Write” を参照してください。 |
|
Write * |
WRITEコマンドの引数が整数式に続いて先頭にアスタリスク(*) で構成するとき、WRITEコマンドは、その整数式のコードポイント値によって表される文字を出力します。詳細と使用例については、 “Write” を参照してください。 |
|
ZSHow |
UTF-8モードで、ZSHOWのコマンドは、次のようにバイト指向とディスプレイ指向の挙動を示します。
詳細と使用例については、 "ZSHOW デスティネーション変数" を参照してください。 |
Unicodeのサポートにより、GT.Mデータベースエンジン、または、データが保存され操作される方法に変更はありません。GT.Mは、常にMグローバル変数とローカル変数のインデックスと値が、基準の番号または任意のバイトシーケンスのどちらかを可能にすることができます。M ソースプログラムで使用される文字セットへの変更もありません。Mソースプログラムは、常にASCII になっています。（ 標準ASCII は - $C(0)から$C(127) - Unicode標準によって指定されたUTF-8エンコーディングの適切なサブセットです）。GT.Mは、コメントと文字列リテラル内の一部の非ASCII文字を受け入れます。
UnicodeをサポートするGT.M内での変更は、M言語仕様に対する主な拡張です。原理的には簡単ですが、これらは基本的には以前からある根深い仮定を確定的に変更します。例：
文字の中の文字列の長さは、バイト単位で文字列の長さと同じではありません。文字の中のUnicode文字の文字列の長さは、常により小さいか、バイト単位の長さに等しくなります。
端末上の文字列の表示幅は、文字の中の文字列の長さが異なる場合 - たとえば、Unicodeを使用し、複雑なグリフは、Unicode文字列内のエンコードされる文字のUTF-8の順番で、実際には、グリフまたはコンポーネントシンボルのシリーズで構成されます。
グリフが複数の文字で構成されている場合を、Unicodeの中の文字列は、正規と非正規の形式を持つことができます。フォームは、概念的に同じかもしれないが、それらはUnicodeで文字の異なる文字列です。
![[重要]](images/important.jpg) |
重要 |
|---|---|
GT.Mは、異なりそして等しくないものとして同じ文字列について正規と非正規のバージョンを扱います。FISは、アプリケーションが標準的な形式を使用して書き込まれることを推奨します。入力文字列の正規表現への適合が保証することができない場合では、各言語の言語的および文化的に適切なアプリケーションロジックは、非正規の文字列を標準的な文字列へ変換する必要があります。 |
アプリケーションは、文字やバイナリデータの組み合わせで動作することがあります - たとえば、データベース内のいくつかの文字列は、実験機器のためのエスケープシーケンスを含めることができます署名などのデジタル画像があります。さらに、Mのアプリケーションは、伝統的に同じ文字列の一部として異なるデータ項目を格納することによって文字列をオーバーロードしているので、同じ文字列には、Unicodeとバイナリデータの両方を含めることができます。GT.Mは、Unicodeとバイナリデータの両方を含んでいる文字列が入っているUnicode文字列だけでなくバイナリデータを操作するプロセスを可能にする機能があります。
GT.Mのデザイン哲学は、物事をシンプルに保つことですが、必要以上にはシンプルにしません。Unicodeの使用が複雑に加わる処理の分野があります。これらは、典型的に長さの解釈と文字の解釈とが互いに影響しあうことが生じます。例：
バイトの順序は、バイナリデータとしてとらえた場合、けっして不適切になることはありませんが、Unicode文字列として扱われた場合には、不適切となることがあります。不適切なUnicode文字列の検出とハンドリングは、バイナリとUnicodeデータが同じ列の異なる部分に存在する場合は、特に、複雑さが追加されます。
バイナリデータがUnicodeの図形文字(グリフ文字)にマップできない場合があるので、ZWRite 形式では異なる文字のような表現が必要です。Unicodeとしてそれを解釈するプロセスによって出力されるバイトのシーケンスが、バイナリとしてそのシーケンスを解釈し、その逆も同様に、プロセスへの正しい入力フォームとして処理する必要があります。したがって、ZWR形式でMUPIP EXTRACT と MUPIP LOAD操作を含むIO操作を実行する時には、そのプロセスが、希望する出力を生成し正しい読み込みと入力処理するために、互換性のある環境変数および/またはロジックがあることを確認してください。
人間または非GT.Mアプリケーションが互いに影響しあう入力/出力を管理しているアプリケーションロジックは、さらに緊密な精査が必要です。例えば、ファイルの固定長レコードは、常にバイト単位で定義されています。Unicode関連の操作では、アプリケーションが、文字がレコード境界を交差するように、データを出力する場合があります（例えば、レコードが残っているスペースの2バイトを持っていて次のUTF8文字が3バイト長ある）、この場合、GT.Mは1つ以上のパッド・バイト(pad byte)でレコードを埋めます。パッド入りのレコードがUTF-8として読み込まれる時に、末尾のパッド・バイトは、GT.Mによってストリップされ、アプリケーションコードへは提供されません。
一部の言語（中国語など）の場合では、Unicodeのコードポイント（文字値）に従っている文字列の順序は、言語的または文化的に正しい順序付けができない場合があります。そのような言語の中でサポートしているアプリケーションでは、照合モジュールの開発が必要です - GT.MはネイティブなM照合をサポートしていますが、特定の自然言語のためのビルド済みの照合モジュールは含まれていません。
グリフは、システムを書くのにテキスト要素を視覚的に表現したものであり、Unicodeのコードポイントは基礎となるデータです。内部的に、GT.Mは、UnicodeのコードポイントのシーケンスとしてエンコードされたUTF-8文字列を保存します。Unicode互換のある出力デバイス（ 端末, プリンタ, アプリケーション ）は、コードポイントのシーケンスを描写するグリフのシーケンスとして文字をレンダリングしますが、文字とグリフの間に一対一対応がない場合があります。
例えば、デーヴァナーガリー書記大系 (Devanagari：サンスクリット語とヒンディー語を書くときに使われる音節主音的な書記法) から次の単語を考えてみましょう。
अच्छी
画面やプリンタ上は、それが4列に表示されます。内部的にGT.Mは、5個のUnicodeコードポイントのシーケンスとして格納します。
|
# |
文字 |
Unicode コードポイント |
文字の意味 |
|---|---|---|---|
|
1 |
अ |
U+0905 |
デーヴァナーガリー字体 A |
|
2 |
च |
U+091A |
デーヴァナーガリー字体 CA |
|
3 |
् |
U+094D |
デーヴァナーガリー文字の符号 VIRAMA |
|
4 |
छ |
U+091B |
デーヴァナーガリー字体 CHA |
|
5 |
ी |
U+0940 |
デーヴァナーガリー母音符号 II |
デーヴァナーガリーの書記体系 (U+0900 to U+097F) は、英語のアルファベットの使用とは対照的に音節の表現に基づいています。したがって、それは特定の音節を表すために子音のhalf-form (ハーフ フォーム)を使用しています。上記の例では、half-form (ハーフ フォーム)を使用しています (U+091A) 。
ハーフフォーム(half-form)の形式の子音は、デーヴァナーガリー書記体系のコンテキストで有効なテキスト要素にもかかわらず、それはUnicode標準の文字に直接マップされません。これは、デーヴァナーガリーSIGN VIRAMA と デーヴァナーガリーLETTER CHA とデーバナーガリー文字LETTER CAを組み合わせることによって得られます。
画面やプリンタ上で、ターミナルのフォントは、半子音のグリフイメージを検出し、次の表示位置でそれを表示します。内部的にGT.Mは、それを表示するために必要な列数を計算するために、デーヴァナーガリー書記体系におけるICUのグリフに関連する規則を使用しています。結果として、それがハーフフォーム(half-form)の子音を表す3個のUnicodeコードポイントの組み合わせを検出した時に、GT.Mは、$X を1つ進めます。
GT.Mプロンプトでこのサンプルを表示するには、次のコマンドシーケンスを入力します。
GTM>write $ZCHSET
UTF-8
GTM>set DS=$char($$FUNC^%HD("0905"))_$char($$FUNC^%HD("091A"))_$char($$FUNC^%HD("094D"))
GTM>set DS=DS_$char($$FUNC^%HD("091B"))_$char($$FUNC^%HD("0940"))
GTM>write $zwidth(DS); 4 columns are required to display local variable DS on the screen.
4
GTM>write $length(DS); DS contains 5 characters or Unicode code-points.
5
GTM>
Unicodeでサポートされているすべての書記体系では、文字列処理やネットワーク伝送やストレージやUnicodeデータの取得のために文字はコードポイントであるのに対して、画面やプリンタに表示するための文字はグリフです。これは、多くの他の一般的なプログラミング言語についても当てはまります。アプリケーション開発のライフサイクル全体を念頭に、これを区別してください。
GT.MはUnicodeで文字を処理するためのフレームワークを提供していますが、それは、言語固有の情報については ICU (International Components for Unicode) ライブラリに依存しています。
ICUは広く使用されているデファクトスタンダードのパッケージで( 詳細は http://icu-project.org 参照)、GT.Mは、テキストの境界検出やUTF-8とUTF-16間の文字列変換やグリフの表示幅の計算のようなUnicode文字セットの知識を必要とするほとんどの操作をICUに頼っています。
|
重要 |
|---|---|
Unicodeサポートがプロセスのために捜し求めない限り（つまり環境変数 gtm_chset が "UTF8でない限り）、GT.MプロセスはICUを必要としません。言い換えれば、既存の非Unicodeのアプリケーションは、ICUなしでサポートされているプラットフォーム上で動作し続けます。 |
ICUのバージョン番号は、整数であるメジャー番号とマイナー番号とミリ番号とマイクロ番号の major.minor.milli.micro 形式です。機能とAPIの互換性では異なる可能性がある別のメジャーおよび/またはマイナーバージョン番号を持つ2つのバージョンは、保証されていません。ミリやマイクロのバージョンの違いは、機能やAPIの互換性を保つためのメンテナンスリリースです。ICUリファレンスリリースは、メジャーおよびマイナーバージョン番号によって定義されます。一部の文字の表示幅がICU 4.0で変更され、そして、言語とICUの両方が進化するにつれ、将来再び変更される可能性があることに、注意してください。
オペレーティングシステムのディストリビューションは、一般的に、OSとハードウェアに合わせたICUライブラリが含まれていて、したがって、FISはどのようなICUライブラリも提供していません。ユニコード機能をサポートするためには、GT.Mは、システムにインストールされているICUの適切なバージョンを必要とします - サポートされているICUのバージョンについては、リリースされたGT.Mのリリースノートを確認してください。
GT.Mは、シンボルの名前変更を無効にしてコンパイルされているICUを想定し、もしICUの利用可能なバージョンがシンボルの名前変更を有効にしてビルドされている場合、起動時にエラーを発行します。シンボル名の変更を有効にしてICUをビルドしたバージョンを使用するには、環境変数 $gtm_icu_version が、MajorVersion.MinorVersionとしてフォーマットされた希望のICUのメジャーバージョンとマイナーバージョン番号を示します（例：ICU-3.6は"3.6" を示す）。$gtm_icu_version がそのように定義される場合は、GT.MはICUの特定のバージョンを開こうとします。このケースでは、GT.Mは、このICU内のシンボルの名前が変更されているかどうかに関係なく、動作します。この環境変数の欠落または不正な形式の値は、非改名のICU シンボルを探すだけのためにGT.Mに引き起こします。各GT.Mリリースのリリースノートには、必要な基準のリリースのバージョン番号だけでなく、リリース前にGT.Mをテストするために使用されたミリ、マイクロバージョン番号を識別します。一般的に、特定のICUリファレンスで必要とされるバージョン番号と、そのGT.Mバージョンのリリースノートで識別されるものよりも大きいミリとマイクロバージョン番号を持つICUの任意のバージョンを使用しても安全でなければなりません。
ICUは、プロセス内で複数のスレッドをサポートし、ICUのバイナリライブラリは、マルチスレッドをサポートするか、あるいは、サポートしないかのどちらか一方を、ソースコードからコンパイルすることができます。対照的に、GT.Mは、GT.Mプロセス内でマルチスレッドをサポートしていません。一部のプラットフォーム上では、通常マルチスレッドをサポートするためにコンパイルされているストックされたICUライブラリは、GT.Mでは変更されないままに動作する可能性があります。他のプラットフォーム上では、マルチスレッドが無効になってサポートされるそのソースファイルからICUを再構築するために必要となる場合があります。テストされサポートされている特定の構成についての詳細は、各GT.Mリリースのリリースノートを参照してください。一般的に、各GT.Mバージョンで使用されるICUのバイナリのGT.Mチームのプリファレンスは、優先順位の高い順に、以下のとおりです。
オペレーティングシステムのディストリビューション付属のストックされたICUバイナリ。
ICUのプロジェクトページのダウンロードセクションから得られたICUのバイナリディストリビューション。
ICUのバージョンが、ローカルで、マルチスレッドの設定が無効の状態でオペレーティングシステムのディストリビューションで提供されるソースコードからコンパイルされた。
ICUのバージョンが、ローカルで、マルチスレッドの設定が無効の状態で、ICUのプロジェクトページからソースコードからコンパイルされた。
GT.Mは、ICUに動的にリンクするPOSIX関数 dlopen() を使用します。スレッドを使用してコンパイルするICUを必要とする他のアプリケーションがある場合には、異なる場所でICUの異なるビルドを配置し、その適切なICUとリンクする各アプリケーションを有効にする dlopen() のサーチパスの機能（例えば、Linuxの LD_LIBRARY_PATH環境変数）を使用します。
ICUをコンパイルするには、 GT.M管理および操作ガイド の付録「 ICUのコンパイル」 と各GT.Mリリースのリリースノートを参照してください。
GT.MでのUnicodeのサポートは、データベース自体ではなくデータベース内のデータの解釈にのみ影響し、ZWR形式からあるモードでの抽出を他のモードでの抽出に変換する簡単な方法は、他方のモードのプロセスを使用してデータベースからもう一度抽出することができます。
もし 8ビット・オクテットのシーケンスにASCII範囲（0〜127）以外のバイトが含まれている場合、「M」および「UTF-8」モードでは、同じバイト列のZWR形式の抽出が異なります。"M"モードでは、ZWR形式での抽出の$C()値は常に255以下です。 "UTF-8" モードでは、より大きい値を持つことができ - Unicodeの有効な文字のコードポイントは255をはるかに超えている必要があります。
出力デバイスに書き込まれる文字は、制御出力デバイスのOCHSET変換の対象であることに注意してください。もしOCHSETが "M"の場合、マルチバイト文字は変換なしで生のバイトで書き込まれます。
各マルチバイト・グラフィック文字（$ZCHSETによって分類される）は、出力デバイスのOCHSETで指定されたエンコーディング形式に変換されたデバイスに直接書き込まれます。
$ZCHSETで分類される各マルチバイトの非グラフィック文字は、$CHAR(nnnn) 表記で記述されます、.nnnn は10進文字コードです（つまり、$ZCHSET="UTF-8" の場合は最大1114111、$ZCHSET="M"の場合は255までのコードポイント）。
$ZCHSET="UTF-8"で、添字またはデータに不正な形式のUTF-8バイトシーケンスが含まれていると、ZWRITEはシーケンス内の各バイトを個別の不正な文字として扱います。このような各バイトは、$ZCHAR(nn[,...]) 表記で記述されます。各 nn は、不正なUTF-8バイトシーケンスの対応するバイトです。
異なるキャラクタ・セットを使用する別のシステムへの入力としてシステムからのZWRITE出力を使用しようとすると、エラーが発生したり、ソース・システムに存在していたのと同じ状態にならない場合があります。アプリケーション開発者は、すべての非ASCII文字（またはそれの有用なサブセット）が非グラフィック（「参照」）であることを宣言する1つまたは複数のパターンテーブルを定義して使用することでこれを処理できます。パターンテーブルの定義の詳細については、第12章 : “国際化” の "パターンコード定義" を参照してください。
アプリケーション開発者は、M標準の patcode (A,C,L,U,N,P,E) をUnicodeで動作するように拡張していますが、アプリケーション開発者はデフォルトの分類を変更することも、非標準の patcode (B,D,F-K,M,O,Q-T,V-X) がASCIIサブセットを超えています。これは、パターンテーブルより大きいコードの文字が含まれていないことを意味します最大ASCIIコード127。
GT.Mでは、文字列は暗黙的に正規化されません。Unicode 正規化は、文字列の正規表現を計算する方法です。文字列に組み合わせ文字（基本文字とアクセント文字で構成されるアクセント付き文字など）とプリコンポーズ文字が含まれている場合は、正規化が必要です。従来のコードセットとの下位互換性のために、 Unicode™ 標準に割り当てられたコードポイントは、そのような事前合成された文字を指します。同じ文字の両方のバージョン（または文字の組み合わせ）を含むアプリケーションの場合、Unicodeは標準形式の1つを推奨します。GT.Mは文字列を正規化しないため、アプリケーション開発者は、文字列照合と文字列照合が従来の健全な方法で動作するように、必要に応じて文字列を正規化する機能を開発する必要があります。そのような場合、複数の表現が可能な場合には、単一の表現を受け入れる編集チェックを使用することができます。
GT.Mは、$PRINCIPAL入出力デバイス（端末、シーケンシャル、ソケットデバイスを含む）のUTF-16、UTF-16LE、UTF-16BE エンコーディングをサポートしていません。$PRINCIPALデバイスでUnicode™ 関連 I / Oを実行するには、アプリケーション開発者はICHSETまたはOCHSETデバイスパラメータに "UTF-8"を使用する必要があります。
UNIX端末と端末エミュレータによるUTF-16のサポートがまれであるため、GT.Mは端末I / Oデバイス用のUTF-16、UTF-16LE、UTF-16BEエンコーディングをサポートしていません。UNIXプラットフォームでは、Unicodeのデファクト文字エンコーディングとしてUTF-8を使用しています。リモートホスト（Windowsなど）からの端末接続は、UTF-8エンコーディングでGT.Mと通信する必要があります。
GT.Mの内部文字エンコーディングとして「UTF-8」を使用すると、照合アルゴリズムを除くCPUサイクルの追加要件は、「M」文字セットを使用する同一アプリケーションと比較して大幅に増加するべきではありません。「UTF-8」の追加メモリー要件は、アプリケーションおよび使用される実際の文字セットによって異なります。たとえば、Latin-1（2バイト符号化）文字に基づくアプリケーションでは、最大2倍のメモリが必要になることがあります、そして、中国語/日本語（3バイト符号化）文字に基づくものは、「M」文字を使用する同一のアプリケーションと比較して、最大3倍のメモリを必要とすることがあります。「UTF-8」の追加のディスクスペースとI / Oパフォーマンスのトレードオフも、アプリケーションと使用される文字に基づいて異なります。
GT.Mの以前のバージョンでは、文字が1バイトで表されるという前提で、特定のオブジェクトに対する制限が設けられていました。GT.Mで有効になっているUnicodeをサポートするため、次の制限は、文字ではなくバイト単位です。
M文字列の最大長は1,048,576バイト（1Mib）に制限されています。したがって、使用される文字によっては、最大文字数を1,048,576文字から262,144（256K）文字に減らすことができます。
プログラムまたは間接的なソース行の最大長は2,048バイトに制限されています。アプリケーション開発者は、マルチバイトのソースコメントや文字列リテラルをソース行に使用することを検討する場合は、このバイト制限に注意する必要があります。
GT.M上に配置するためのUnicodeベースのアプリケーションの設計と開発には、以下の経験則を遵守してください。
Unicodeに関連するGT.Mの機能は、UTF-8モードでのみ利用可能になります。
[少なくとも] UTF-8モードでは、バイト操作では Z* と同等の関数を使用する必要があります。
Mモードでは、標準関数は常にZ等価と同じです。
インスタンス内のすべてのグローバル名とサブスクリプトに同じ文字セットを使用します。
使用されている言語の言語および文化の教義に従って照合システムを定義します。
キーとして使用される文字列が正規のものであることを保証するアプリケーション・ロジックを作成します。
CHSET="M"を指定するか、I / O操作中に不正な文字を処理してください。
互換性のある文字エンコード形式を使用して、任意の外部ルーチンと通信します。
$ZCHSET と "BADCHAR" と同じ設定でプログラムをコンパイルして実行します。