使用目的
以前のVantageおよびTeradata Database漢字リリースとの互換性を維持する必要がある日本のアプリケーション。
埋込み文字
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関数によって無効な文字列が生成される可能性があります。
- このタイプの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 | 以下のとおり、現在のセッションのクライアント エンコーディングに従う。
|
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