ストレージ
文字データは、使用されているサーバー文字セットに応じて文字またはバイト単位で割り当てられます。1文字当たりの格納バイト数は、次の表に示すように、サーバー文字セットによって異なります。
| サーバー文字セット | サーバー使用形式 | サーバーのスペース割り当て | 異種クライアント間で共用可能か? |
|---|---|---|---|
| LATIN | 固定8ビットのLATIN | Character-based | Yes(はい) |
| UNICODE | 固定16ビットのUNICODE | ||
| GRAPHIC | 固定16ビットのUNICODE | ||
| KANJISJIS | 1バイトとマルチバイトが混在するKANJISJIS | Byte-based | Yes(はい) |
CHARACTERの外部表現
クライアント アプリケーションは、Vantageと対話するときに、その文字セット(文字データ用の使用形式)を指示します。サーバーは、すべての文字データをその形式でクライアント アプリケーションに返します。
クライアントのシステム データ型との変換は、Vantageによって行なわれます。
CHARACTER型の場合にエクスポートされるバイト数の詳細は、Teradata SQL文字列およびクライアント物理バイトを参照してください。
表示形式
CHARACTER(n)のデフォルトの表示書式は、X(n)です。例えば、X(5)の場合、‘HELLO’のデータは‘HELLO’のように表示されます。
GRAPHICデータ
GRAPHICを使って、マルチバイトの文字データを表わすことができます。
GRAPHIC(n)は、CHARACTER(n) CHARACTER SET GRAPHICと等価です。すべてのGRAPHIC(n)データをCHARACTER(n) CHARACTER SET GRAPHICと定義するのが最善策です。
グラフィック列の各マルチバイト文字は、1論理文字当たり2バイトであるものとして格納されます。したがって、グラフィック データ列は、必ず、evenのバイト数を表わすことになります。
長さ(n)なしでGRAPHICを指定した場合、デフォルトはGRAPHIC(1)になります。
以下のルールが、GRAPHICデータの切捨てと文字の埋込みに適用されます。
| グラフィック文字列の状況 | THEN … |
|---|---|
| 列の指定長より短い | 残りのスペースにグラフィック埋込み文字が入ります。 |
| 列の指定長より長い | 余分な文字が切り捨てられます。 |
GRAPHICの外部表現
次の表では、IBM DB2 GRAPHICタイプのクライアント表現をリストしています。
アプリケーション定義とクライアント データ型を判別するのは、アプリケーション プログラマの責任です。
| クライアントCPUアーキテクチャ | クライアントの内部データ形式 |
|---|---|
| IBMメインフレーム | n個のDB2 GRAPHIC文字の2nバイト |
グラフィック データとクライアント文字セット
- KanjiEBCDICの2バイトのグラフィック データ
- 2バイトのShift-JISコードを表わすKanjiShift-JIS
- 固定長の2バイトのEUC文字を表わすKanjiEUC
G '<graphic_characters>'
KanjiEBCDICの文字セットでは、グラフィック文字列内のマルチバイト文字は、次のように、シフト アウト/シフト イン文字で区切る必要があります。
INSERT INTO TableEBCDIC (ColGRAPH)
VALUES (G'<AB>');
ここで、ABは、有効なKanjiEBCDICマルチバイト文字列であり、Gは文字列がグラフィック レパートリーに属さなければならないことを示します。また、各単一引用符は1バイト文字です。