KANJI1サーバー文字セット[廃止] - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - データ タイプおよびリテラル

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
2021年7月
Language
日本語
Last Update
2021-09-23
dita:mapPath
ja-JP/tpf1598412463935.ditamap
dita:ditavalPath
ja-JP/wrg1590696035526.ditaval
dita:id
B035-1143
Product Category
Software
Teradata Vantage

使用目的

以前のVantageおよびTeradata Database漢字リリースとの互換性を維持する必要がある日本のアプリケーション。

Teradataの国際化計画に従って、今後、KANJI1サポートは推奨されず、近い将来に廃止されます。KANJI1をデフォルトの文字セットとして使用することはできません。システムはデフォルトのKANJI1文字セットをUNICODE文字セットに変更します。KANJI1の新規オブジェクトの作成は、高度に制限されています。KANJI1を使用するクエリーやアプリケーションの多くは、従来通り動作する可能性はありますが、KANJI1を使用するサイトはできるだけ早く別の文字セットに変換する必要があります。

埋込み文字

ASCII SPACE (0x20)

SQL宣言

CHARACTER(n) CHARACTER SET KANJI1

VARCHAR(n) CHARACTER SET KANJI1

nの最大値

64000

これは、LONG VARCHAR CHARACTER SET KANJI1のサイズでもあります。

使用上の注意

KANJI1には、現在のセッションの文字セットで判別されたクライアント文字セットのKanjiEBCDIC、KANJISJIS、またはKanjiEUCの1バイト文字とマルチバイト文字が混在しています。

KANJI1は、以前のリリースのCHARACTERタイプの意味と制限を継承します。例えば、SUBSTR関数によって無効な文字列が生成される可能性があります。

KANJI1には、次の特殊性があります。
  • このタイプの1バイト文字部分は、JIS X 0201で定義された正規の形式で格納されます。
  • このタイプのマルチバイト文字部分は、クライアントの使用形式で格納されるので、異種のクライアント間で共用することはできません。

エクスポート後のKANJI1サーバー文字セットのCHARACTERデータの最大長(バイト数)は、必ずCHARACTER(n)とVARCHARACTER(n)のnになります。

日本語サポートが使用可能なシステムでは、データベースは、すべてのの文字データに1バイト文字とマルチバイト文字が混在していると想定します。1バイト文字とマルチバイト文字が混在するデータは、CHAR、VARCHAR、またはLONG VARCHARとして定義された列に関連付けられます。

KANJI1文字セットのエンコーディングは、現在のセッションの文字セットに応じて、KanjiEBCDIC、KanjiEUC、またはKanjiShift-JISクライアント文字セットのいずれかになります。

セッションの文字セットに応じて、1バイト文字とマルチバイト文字は、次の表のように区別されます。

クライアント文字セット 定義
KanjiEBCDIC 文字は、シフト アウト文字が見つかるまで1バイトとみなされます。

後続の文字は、シフト イン文字が見つかるまでマルチバイト文字とみなされます。シフト インが見つからずに文字列の終わりに達した場合には、エラー状態が発生します。

KanjiEUC マルチバイト文字の先頭バイトの最上位ビットは、必ずオンです。マルチバイト文字は、2バイトです。ただし、KanjiEUC cs3文字には3バイトが必要です。
KanjiShift-JIS

character列にCASESPECIFICオプションが定義されている場合には、英大文字への変換は実行されず、単純なローマ字(A~Z、a~z)は、大小文字が同じの同じ文字である場合にのみ一致しているものとみなされます。

KANJI1サーバー文字セットの詳細について、<Teradata Vantage™ - Advanced SQL Engine国際文字セット サポート、B035-1125>を参照してください。

大文字への変換

各種の日本語文字に対するUPPERCASE関数の結果を次の表に示します。

クライアント文字セット 文字列 変換の結果
KanjiEBCDIC mNabcb MN<abc>B
KanjiEUC mn a ss 2B ss 3c MNa ss 2B ss 3c
KanjiShift-JIS mn Iabc MN Iabc

単純なローマ字は必ず同じ正規表現であるため、英大文字への変換の結果は、Vantageでサポートされるすべての文字セットで同じになります。

制限

CLOBタイプは、KANJI1サーバー文字セットをサポートしません。

CHARACTERタイプの埋込みと切捨て

Teradataモードでは、文字表現がそれより短いCHAR列に割り当てられた場合には、余分なバイトが切り捨てられます。その結果、間違った文字列になることがあります。この切捨ての発生は、ユーザーに通知されません。

ANSIモードでは、ブランク以外の文字が切り捨てられるとエラーが発生します。

ある長さの文字表現がそれより長いCHAR列に割り当てられた場合には、フィールドにSPACE文字が埋め込まれます。

モードがTeradataかANSIかには関係なく、短い文字列には1バイトのスペースが埋め込まれます。2つのモードでは、切捨て方法のみが異なります。

マルチバイト文字データの検証と格納

サーバー上の妥当性検査済みのマルチバイト文字データの変換および格納は、現在のセッションの文字セットによって異なります。次の表で説明します。

クライアント文字セット サーバー上でマルチバイト文字が変換および格納される方法
KanjiEUC 以下のとおり、現在のセッションのクライアント エンコーディングに従う。
  • コード セットcs0:

    このコード セットの各文字は、最初のバイトがEUCから内部表現方法に(JIS X 0201に基づいて)すべての文字に変換され、1バイト文字として格納されます。

  • コード セットcs1:

    このコード セットの各文字は、最初のバイトが(JIS X 0208に基づいて) KanjiShift-JIS文字データにのみ変換されます。これは、<Teradata Vantage™ - Advanced SQL Engine国際文字セット サポート、B035-1125>の変換マップに示されています。

    GRAPHICデータは、変換されずに格納されます。

    後続の文字も、KanjiShift-JISに変換されます。

  • コード セットcs2:

    このコード セットの各文字は、最初のバイトが文字データにのみ変換されます。最初のバイト(ss 2=0x8E)は0x80に変換され、2番目のバイトは変更されずにそのままになります。

  • コード セットcs3:

    このコード セットの各文字は、最初のバイトが文字データにのみ変換されます。先頭バイト(ss 3=0x8F)は0xFFに変換され、残りの2バイトは変更されないままです。

    GRAPHICデータは、変換されずに格納されます。

KanjiEBCDIC 受け取ったときのまま。

変換されず、クライアントのエンコーディングのまま格納されます。

KanjiEBCDICの場合のみ、シフト アウト文字とシフト イン文字は、同じエンコーディング(それぞれ0x0Eと0x0F)に変換されてから文字列の一部として格納されます。

KanjiShift-JIS

例: 固定長のKanjiEBCDIC

固定長列には、次のKanjiEBCDICデータが入るものとします。

<  S   T   R   I   N   G  > 12  

列定義は、データの内部表現およびシフト アウト文字(<)とシフト イン文字(>)を収容するために少なくとも16バイト(CHAR(16) CHARACTER SET KANJI1)が必要です。次のとおりです。

0E 42E2 42E3 42D9 42C9 42D5 42D7 0F 31 32 

マルチバイト文字データの3つのクライアント表現では、同じ記号順序に異なる長さが必要になることに注意する必要があります。

例: 固定長のKanjiShift-JIS

同じ文字列をKanjiShift-JISで表現すると、次のようになります。

S   T   R   I   N   G  12 

これには、14バイトの長さ(CHAR(14) CHARACTER SET KANJISJIS)が必要です。KanjiShift-JIS文字列に同等の内部表記は、次のとおりです。

8272 8273 8271 8268 826D 8266 31 32