2 文字セットの選択

この章では、文字セットの選択方法について説明します。この項の内容は、次のとおりです。

• 文字セット・エンコーディング

• 長さセマンティクス

• Oracle Database文字セットの選択

• マルチテナント・コンテナ・データベースのデータベース文字セットの選択

• データベース作成後の文字セットの変更

• 単一言語データベースの使用例

• 多言語データベースの使用例

2.1 文字セット・エンコーディング

文字を処理する場合、コンピュータ・システムは文字をグラフィカルな表現としてではなく数値コードとして処理します。たとえば、データベースに文字Aを格納すると、実際はコンピュータ・システムによって解析される数値コードが格納されます。特に、異なる文字セット間のデータ変換を必要とする可能性があるグローバル環境では、この数値コードが重要になります。

このセクションのトピックは次のとおりです:

• エンコードされた文字セットについて

• エンコードされる文字

• 文字セットでサポートされている文字

• 文字のエンコード方法

• Oracle Database文字セットのネーミング規則

• サブセットとスーパーセット

2.1.1 エンコードされた文字セットについて

データベースの作成時に、エンコードされた文字セットを指定します。文字セットの選択によって、データベース内で表現できる言語が決定します。また、次の点にも影響を及ぼします。

• データベース・スキーマの作成方法

• 文字データを処理するアプリケーションの開発方法

• オペレーティング・システムでのデータベースの動作

• データベースのパフォーマンス

• キャラクタ・データの格納に必要な記憶域

文字グループ(アルファベット文字、表意文字、記号、句読点および制御文字など)は、文字セットとしてエンコードできます。エンコードされた文字セットは、文字セット内のそれぞれの文字を表す一意の数値コードに対応しています。数値コードはコード・ポイントまたはエンコーディング値と呼ばれます。次の表に、ASCII文字セットの16進コード値が割り当てられている文字の例を示します。

表2-1 ASCII文字セットでエンコードされた文字

文字	説明	16進コード値
!	感嘆符	21
#	数値記号	23
$	ドル記号	24
1	数字の1	31
2	数字の2	32
3	数字の3	33
A	大文字のA	41
B	大文字のB	42
C	大文字のC	43
a	小文字のa	61
b	小文字のb	62
c	小文字のc	63

コンピュータ業界では多くのエンコードされた文字セットが使用されています。各文字セットは、次の点で異なります。

• 使用可能な文字数

• 使用可能な文字(文字レパートリ)

• 書込み用スクリプトとそれによって表される言語

• それぞれの文字に割り当てられたコード・ポイント

• 特定の文字を表現するために使用するコード体系

Oracle Databaseでは、各国の規格、国際規格およびベンダー固有のエンコードされた文字セット規格のほとんどすべてをサポートしています。

関連項目:

Oracleデータベースでサポートされているすべての文字セットのリストは、「文字セット」を参照してください

2.1.2 エンコードされる文字

文字セットでエンコードされる文字は、表現する記述法によって異なります。記述法は、1つの言語または1つの言語グループを表現するために使用できます。記述法は次の2つに分類できます。

• 表音的記述法

• 表意的記述法

この項の内容は、次のとおりです。

• 句読点、制御文字、数字および記号

• 書込み方向

2.1.2.1 表音的記述法

表音的記述法は、1つの言語に対応付けられた様々な音声を表現する、複数の記号で構成されています。たとえば、ギリシア語、ラテン語、キリル文字およびデーバナーガリ語はすべて、アルファベットに基づいた表音的記述法です。アルファベットは、複数の言語を表現できます。たとえば、ラテン・アルファベットでは、多くの西ヨーロッパ諸国の言語(フランス語、ドイツ語、英語など)を表現できます。

表音的記述法に対応付けられた文字は、文字レパートリが通常256文字より少ないため、一般的には1バイトでエンコードできます。

2.1.2.2 表意的記述法

表意的記述法は、言語の音声ではなく、単語の意味を表す表意文字または象形文字で構成されています。中国語と日本語は、何万という表意文字に基づいた表意的記述法の例です。表意的記述法を使用する言語では、表音文字セットを使用する場合もあります。表音文字セットでは、追加の表音的情報を伝達する方法が提供されます。たとえば、日本語には2つの表音文字セットがあり、通常、文法的な要素にはひらがなが、外来語や擬音語にはカタカナが使用されます。

表意的記述法に対応付けられた文字は、文字のレパートリが何万とあるため、一般的には複数バイトでエンコードします。

2.1.2.3 句読点、制御文字、数字および記号

言語スクリプトのエンコーディングに加えて、次のように他の特殊文字もエンコードする必要があります。

• カンマ、ピリオドおよびアポストロフィなどの句読点

• 数字

• 通貨記号や数学演算子などの特殊な記号

• キャリッジ・リターンやタブなどの制御文字

2.1.2.4 書込み方向

ほとんどの欧米言語は、ページの上から下へ向かって左から右へ記述されます。東アジアの言語は、通常、ページの右から左に向かって上から下へ記述されますが、欧米言語から翻訳された技術文書ではしばしば例外が見られます。アラビア語とヘブライ語は、上から下へ向かって右から左へ記述されます。

アラビア語およびヘブライ語では数字の方向は逆になります。テキストが右から左に書かれている場合でも、文中の数字は左から右に向かって書かれます。たとえば、「I wrote 32 books」は「skoob 32 etorw I」と書かれます。書込み方向に関係なく、データは論理順序で格納されます。論理順序は、入力している言語の画面上での表示方法ではなく、その言語の入力で使用されている順序を意味します。

書く方向は文字のエンコードに影響を与えません。

2.1.3 文字セットでサポートされている文字

様々な文字セットによって、様々な文字レパートリがサポートされています。一般的に、文字セットは特定の書込みスクリプトに基づいているため、複数の言語をサポートできます。文字セットが最初に開発されたとき、文字レパートリには制限がありました。今でも、特定の文字を複数のプラットフォームで使用すると、問題が発生する場合があります。次のCHAR文字およびVARCHAR文字は、すべてのOracle Database文字セットで表示可能で、どのプラットフォームにもトランスポートできます。

• 大文字と小文字の英文字: AからZおよびaからz

• アラビア数字: 0から9

• 句読点記号: % ' ' ( ) * + - , . / \ : ; < > = ! _ & ~ { } | ^ ? $ # @ " [ ]

• 制御文字: スペース、水平タブ、垂直タブ、改ページ

これ以外の文字を使用する場合は、選択したデータベース文字セットでデータがサポートされているかどうか注意する必要があります。

適切なデータ変換を行うには、NLS_LANGパラメータを適切に設定する必要があります。NLS_LANGパラメータでは、クライアント・オペレーティング・システムの設定を反映する文字セットを指定してください。NLS_LANGを適切に設定すると、クライアント・オペレーティング・システムの文字コード体系からデータベース文字セットへと適切に変換できます。これらの設定が同じときは、Oracle Databaseによって、送受信されるデータはデータベース文字セットと同一の文字セットでエンコードされているとみなされるため、文字セットの妥当性チェックや変換が行われない場合があります。このため、変換が必要な場合は、データが破損する可能性があります。

文字セット間での変換中に、Oracleはクライアント側のデータがNLS_LANGパラメータで指定された文字セットでエンコードされるものと想定します。文字列に(たとえば、CHRまたはCONVERT SQL関数を使用して)他の値を入力すると、その値は、データベースに送信されたときに、適切に変換されないため損われる可能性があります。環境を適切に構成しており、データベース文字セットでデータベースに入力される可能性のある文字データのレパートリ全体がサポートされていれば、現行のデータベース文字セットを変更する必要はありません。ただし、企業がよりグローバルになり、追加の文字や新規の言語のサポートが必要になった場合は、より大きな文字レパートリを持つ文字セットの選択が必要になる可能性があります。このような場合は、Unicodeデータベースとデータ型の使用をお薦めします。

関連項目:

• Unicodeを使用した多言語データベースのサポート

• CONVERT SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

• CHR SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

• 「Oracle Locale Builderを使用したコード・チャートの表示」

2.1.3.1 ASCIIエンコーディング

表2-2に、ASCII文字セットがどのようにエンコードされているかを示します。行および列のヘッダーは、16進数字を示しています。文字のコード値を調べるには、列の数字の次に行の数字を読みます。たとえば、文字Aのコード値は0x41です。

表2-2 7ビットASCII文字セット

-	0	1	2	3	4	5	6	7
0	NUL	DLE	SP	0	@	P	'	p
1	SOH	DC1	!	1	A	Q	a	q
2	STX	DC2	"	2	B	R	b	r
3	ETX	DC3	#	3	C	S	c	s
4	EOT	DC4	$	4	D	T	d	t
5	ENQ	NAK	%	5	E	U	e	u
6	ACK	SYN	&	6	F	V	f	v
7	BEL	ETB	'	7	G	W	g	w
8	BS	CAN	(	8	H	X	h	x
9	TAB	EM	)	9	I	Y	i	y
A	LF	SUB	*	:	J	Z	j	z
B	VT	ESC	+	;	K	[	k	{
C	FF	FS	,	<	L	\	l	|
D	CR	GS	-	=	M	]	m	}
E	SO	RS	.	>	N	^	n	~
F	SI	US	/	?	O	_	o	DEL

世界中のユーザーの要求を満たすために言語は拡張されて、新規文字セットが作成されました。一般的に、この新規文字セットでは、同じスクリプトに基づいた関連のある言語グループがサポートされています。たとえば、ISO 8859文字セット・シリーズは、多様なヨーロッパ諸国の言語をサポートするために作成されました。表2-3に、ISO 8859文字セットでサポートされている言語を示します。

表2-3 lSO 8859文字セット

規格	サポートしている言語
ISO 8859-1	西ヨーロッパ諸国の言語(アルバニア語、バスク語、ブルトン語、カタロニア語、デンマーク語、オランダ語、英語、フェロー語、フィンランド語、フランス語、ドイツ語、グリーンランド語、アイスランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語)
ISO 8859-2	東ヨーロッパ諸国の言語(アルバニア語、クロアチア語、チェコ語、英語、ドイツ語、ハンガリー語、ラテン語、ポーランド語、ルーマニア語、スロバキア語、スロベニア語、セルビア語)
ISO 8859-3	南東ヨーロッパ諸国の言語(アフリカーンス語、カタロニア語、オランダ語、英語、エスペラント語、ドイツ語、イタリア語、マルタ語、スペイン語、トルコ語)
ISO 8859-4	北ヨーロッパ諸国の言語(デンマーク語、英語、エストニア語、フィンランド語、ドイツ語、グリーンランド語、ラテン語、ラトビア語、リトアニア語、ノルウェー語、サーミ語、スロベニア語、スウェーデン語)
ISO 8859-5	東ヨーロッパ諸国の言語(キリル文字ベース: ブルガリア語、ベラルーシ語、マケドニア語、ロシア語、セルビア語、ウクライナ語)
ISO 8859-6	アラビア語
ISO 8859-7	ギリシャ語
ISO 8859-8	ヘブライ語
ISO 8859-9	西ヨーロッパ諸国の言語(アルバニア語、バスク語、ブルトン語、カタロニア語、コーンウォール語、デンマーク語、オランダ語、英語、フィンランド語、フランス語、フリースランド語、ガリシア語、ドイツ語、グリーンランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語、トルコ語)
ISO 8859-10	北ヨーロッパ諸国の言語(デンマーク語、英語、エストニア語、フェロー語、フィンランド語、ドイツ語、グリーンランド語、アイスランド語、アイルランドのゲール語、ラテン語、リトアニア語、ノルウェー語、サーミ語、スロベニア語、スウェーデン語)
ISO 8859-13	バルト海沿岸諸国の言語(英語、エストニア語、フィンランド語、ラテン語、ラトビア語、ノルウェー語)
ISO 8859-14	ケルト系言語(アルバニア語、バスク語、ブルトン語、カタロニア語、コーンウォール語、デンマーク語、英語、ガリシア語、ドイツ語、グリーンランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、マン島のゲール語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語、ウェールズ語)
ISO 8859-15	西ヨーロッパ諸国の言語(アルバニア語、バスク語、ブルトン語、カタロニア語、デンマーク語、オランダ語、英語、エストニア語、フェロー語、フィンランド語、フランス語、フリースランド語、ガルシア語、ドイツ語、グリーンランド語、アイスランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語)

これまで、文字セットは、多言語を制限付きでサポートしてきました。この制限とは、類似するスクリプトに基づく言語グループにかぎりサポートしてきたという意味です。最近では、ユニバーサル文字セットが、多言語サポートのための有効なソリューションになってきました。Unicodeは、このようなユニバーサル文字セットの1つで、現代の主要なスクリプトのほとんどを包含しています。

関連項目:

Unicodeを使用した多言語データベースのサポート

2.1.4 文字のエンコード方法

コンピュータ業界では、様々なタイプのコード体系が作成されてきました。選択する文字セットによって、使用するコード体系の種類が異なります。コード体系には様々なパフォーマンス特性があります。これらの特性は、データベース・スキーマやアプリケーションの開発に影響を及ぼす場合があります。選択した文字セットは、次のコード体系のいずれかを使用します。

• シングルバイト・コード体系

• マルチバイト・コード体系

2.1.4.1 シングルバイト・コード体系

シングルバイト・コード体系は効率的です。シングルバイトの1文字は1バイトで表現されるため、文字を表現するのに必要な領域量が最も小さく、処理およびプログラミングでの使用が容易です。シングルバイト・コード体系は、次のいずれかのタイプとして分類されます。

• 7ビット・コード体系

  シングルバイト7ビット・コード体系は、128文字までの文字を定義でき、通常、1つの言語のみをサポートします。最も一般的なシングルバイト文字セットは、ASCII(American Standard Code for Information Interchange)で、コンピュータ処理の初期から使用されています。

• 8ビット・コード体系

  シングルバイト8ビット・コード体系は、256文字までの文字を定義でき、通常、1つの関連言語グループをサポートします。たとえば、ISO 8859-1は、西ヨーロッパ諸国の多数の言語をサポートしています。次の図に、ISO 8859-1の8ビット・コード体系を示します。

図2-1 ISO 8859-1の8ビット・コード体系

「図2-1 ISO 8859-1の8ビット・コード体系」の説明

2.1.4.2 マルチバイト・コード体系

マルチバイト・コード体系は、中国語や日本語のようなアジア言語の表意文字をサポートするために必要です。これは、中国語や日本語では何千という文字が使用されるためです。このコード体系では、各文字を表現するために固定または可変のバイト数を使用します。

• 固定幅マルチバイト・コード体系

  固定幅マルチバイト・コード体系では、各文字が固定のバイト数で表現されます。マルチバイト・コード体系では、バイト数は2以上です。

• 可変幅マルチバイト・コード体系

  可変幅コード体系は、1バイト以上を使用して1つの文字を表現します。一部のマルチバイト・コード体系は、特定のビットを使用して、1文字を表現するためのバイト数を示します。たとえば、1文字の表現に使用する最大のバイト数が2バイトの場合は、最上位ビットを使用して、そのバイトがシングルバイト文字であるか、ダブルバイト文字の1番目のバイトであるかを示します。

• シフト・センシティブ可変幅マルチバイト・コード体系

  一部の可変幅コード体系では、制御コードを使用して、同じコード値を持つシングルバイト文字とマルチバイト文字が区別されます。シフトアウト・コードは後続の文字がマルチバイトであることを示します。シフトイン・コードは後続の文字がシングルバイトであることを示します。シフト・センシティブ・コード体系は、主にIBMプラットフォームで使用されます。ISO-2022文字セットは、データベース文字セットとしては使用できませんが、メール・サーバーなどのアプリケーションには使用できることに注意してください。

2.1.5 Oracle Database文字セットのネーミング規則

Oracle Databaseの文字セット名には、次のネーミング規則が使用されます。

<region><number of bits used to represent a character><standard character set name>[S|C]

名前のうち山カッコで囲まれた各部は連結されます。オプションのSまたはCを使用して、サーバー(S)またはクライアント(C)でのみ使用できる文字セットを区別します。

ノート:

次の点に留意してください:

• Macintoshプラットフォームではサーバー文字セット(S)を使用する必要があります。Macintoshのクライアント文字セットは、現在使用されていません。EBCDICプラットフォームでは、サーバー上ではサーバー文字セット(S)、クライアント上ではクライアント文字セット(C)を使用します。

• UTF8およびUTFEは、このネーミング規則の例外です。

次の表に、Oracle Databaseの文字セット名の例を示します。

表2-4 Oracle Databaseの文字セット名の例

Oracle Databaseの文字セット名	説明	地域	1文字の表現に使用されるビット数	標準文字セット名
US7ASCII	米国7ビットASCII	米国	7	ASCII
WE8ISO8859P1	西ヨーロッパ8ビットISO 8859 Part1	WE (西ヨーロッパ)	8	ISO8859の第1部
JA16SJIS	日本語16ビットシフトJIS	日本	16	SJIS

2.1.6 サブセットとスーパーセット

データベース間の文字セットの変換または互換性について説明する際、Oracleのドキュメントでは、2つの文字セットの関係を説明するために、スーパーセット、サブセット、バイナリ・スーパーセットまたはバイナリ・サブセットという用語を使用します。「バイナリ」が付かないサブセットおよびスーパーセットという用語は、2つのOracle文字セットのキャラクタ・リポジトリ、つまり各文字セットでサポート(エンコード)される一連のキャラクタに関連します。定義としては、文字セットBがサポートするすべてのキャラクタを文字セットAがサポートしている場合、AはBのスーパーセットになります。文字セットAが文字セットBのスーパーセットの場合、BはAのサブセットです。

バイナリ・サブセットおよびバイナリ・スーパーセットという用語は、前述のサブセット/スーパーセットの関係を制限したもので、2つの文字セットのキャラクタのバイナリ表現(バイナリ・コード)に条件が付加されます。定義としては、文字セットBがサポートするすべてのキャラクタを文字セットAがサポートし、これらのすべてのキャラクタのAとBで同じバイナリ表現を持つ場合、AはBのバイナリ・スーパーセットになります。文字セットAが文字セットBのバイナリ・スーパーセットの場合、BはAのバイナリ・サブセットです。

文字セットAが文字セットBのバイナリ・スーパーセットの場合、Bでエンコードされたテキストの値は、同時にAでも有効になり、文字セット変換の必要はありません。AがBのバイナリ・スーパーセットでない場合、Bでエンコードされたテキストの値は、データが失われることなくAで表示できますが、バイナリ表現を変換するには、文字セット変換が必要な場合があります。

Oracle Databaseでは、その文字セットのすべてのサブセット/スーパーセットのペアのリストを保持するわけではなく、トランスポータブル表領域やプラガブル・データベースの互換性を確認するときなど、様々な状況で認識されるバイナリ・サブセット/スーパーセットのペアのリストを保持します。

関連項目:

Oracle Databaseで認識されるバイナリ・サブセット/スーパーセットのペアのリストは、「バイナリ・サブセット/スーパーセットのペア」を参照してください

2.2 長さセマンティクス

シングルバイト文字セットの場合、文字列のバイト数と文字数は同じです。マルチバイト文字セットの場合は、1文字または1つのコード・ポイントが1つ以上のバイトで構成されています。可変幅文字セットの場合は、バイト長に基づく文字数の計算が困難な場合があります。列の長さをバイト数単位で計算することをバイト・セマンティクス、文字数単位で計算することをキャラクタ・セマンティクスと呼びます。

キャラクタ・セマンティクスは、可変幅のマルチバイト文字列の記憶要件を定義する場合に役立ちます。たとえば、Unicodeデータベース(AL32UTF8)で、VARCHAR2列を英語の5文字とともに最大5文字の中国語文字を格納できるように定義する必要があるとします。バイト・セマンティクスを使用すると、この列には、長さ3バイトである中国語文字用に15バイトと、長さ1バイトである英語文字用に5バイト、合計20バイトが必要です。キャラクタ・セマンティクスを使用すると、この列に必要な文字数は10となります。

次の式では、バイト・セマンティクスが使用されています。

• VARCHAR2(20 BYTE)

• SUBSTRB(string, 1, 20)

VARCHAR2式のBYTE修飾子とSQL関数名のB接尾辞に注意してください。

次の式では、キャラクタ・セマンティクスが使用されています。

• VARCHAR2(10 CHAR)

• SUBSTR(string, 1, 10)

VARCHAR2式のCHAR修飾子に注意してください。

文字データ型の列、ユーザー定義タイプ属性、PL/SQL変数の長さセマンティックスは、それぞれの定義でBYTEまたはCHAR修飾子を使用して明示的に指定できます。DDL文の作成で必要なセマンティックスが正しく記述され、DDL文が実行環境に非依存になるため、この方法で長さセマンティックスを指定することをお薦めします。

列、ユーザー定義タイプ属性またはPL/SQL変数の定義にBYTE修飾子もCHAR修飾子も含まれない場合、列、属性または変数に関連する長さセマンティックスは、セッション・パラメータNLS_LENGTH_SEMANTICSの値によって決定されます。レガシー・スクリプトを使用してデータベース・オブジェクトを作成する際、そのスクリプトが非常に大きく複雑で明示的にBYTEまたはCHAR修飾子を含めて更新できない場合、必要なセマンティックスでオブジェクトが作成されるように、各スクリプトを実行する前に明示的にALTER SESSION SET NLS_LENGTH_SEMANTICS文を実行します。

NLS_LENGTH_SEMANTICS初期化パラメータは、新しいセッションのNLS_LENGTH_SEMANTICSセッション・パラメータのデフォルト値を決定します。デフォルト値はBYTEです。Oracle SQLに文字長セマンティックスが導入される前に記述された可能性のある既存のアプリケーション・インストール手順と互換性を保つために、この初期化パラメータを未定義のままにするか、BYTEに設定することをお薦めします。そうでない場合、作成された列が予想よりも大きいために、アプリケーション障害が発生したり、場合によってはバッファ・オーバーフローが発生する可能性があります。

バイト・セマンティクスは、データベース文字セットのデフォルトです。文字長セマンティクスはNCHARデータ型のデフォルトであり、このデータ型に使用できる唯一の長さセマンティクスです。NCHARの定義には、CHARまたはBYTE修飾子を指定できません。

次に例を示します。

CREATE TABLE employees

( employee_id NUMBER(4)
, last_name NVARCHAR2(10)
, job_id NVARCHAR2(9)
, manager_id NUMBER(4)
, hire_date DATE
, salary NUMBER(7,2)
, department_id NUMBER(2)
) ;

NCHARの文字セットがAL16UTF16でもUTF8でも、last_nameに最大10個のUnicodeコード・ポイントを保持できます。NCHARの文字セットがAL16UTF16の場合は、保持する10個のコードポイントが最大で20バイトの領域を占有します。NCHARの文字セットがUTF8の場合は、最大で30バイトの領域を占有します。

次の図に、UTF-8文字セットで各種文字を格納するために必要なバイト数を示します。ASCII文字には1バイト、ASCII以外のラテン語、ギリシャ語、キリル語、アラブ語、およびヘブライ語の文字には2バイト、アジア言語の文字には3バイト、補助文字には4バイトの記憶域が必要です。

図2-2 各種文字の格納バイト数

「図2-2 各種文字の格納バイト数」の説明

関連項目:

• SUBSTRおよびSUBSTRB関数の詳細は、「様々な長さセマンティクスに使用するSQL関数」を参照してください

• NLS_LENGTH_SEMANTICS初期化パラメータの詳細は、「長さセマンティクス」を参照してください

• UnicodeとNCHARデータ型の詳細は、「Unicodeを使用した多言語データベースのサポート」を参照してください

• SUBSTRBおよびSUBSTR関数と文字型データのBYTEおよびCHAR修飾子の詳細は、『Oracle Database SQL言語リファレンス』 を参照してください

2.3 Oracle Database文字セットの選択

Oracle Databaseでは、次の項目でデータベース文字セットを使用します。

• SQL CHARデータ型(CHAR、VARCHAR2、CLOBおよびLONG)で格納されるデータ

• 表名、列名およびPL/SQL変数などの識別子

• SQLとPL/SQLのソース・コードの入力と格納

データベースで使用される文字コード体系は、CREATE DATABASE文の一部として定義されます。データ・ディクショナリ内の列を含めて、すべてのSQL CHARデータ型列(CHAR、CLOB、VARCHAR2およびLONG)のデータは、データベース文字セットに格納されます。さらに、選択するデータベース文字セットによって、データベース内のオブジェクトに名前を指定できる文字が決定されます。SQL NCHARデータ型列(NCHAR、NCLOBおよびNVARCHAR2)では、各国語文字セットが使用されます。

データベースの作成後は、一部の例外を除いて、データベースを再作成せずに文字セットを変更することはできません。

データベース用のOracle Database文字セットを選択する場合は、次の項目について考慮する必要があります。

• データベースでサポートする必要がある言語

• データベースで将来サポートが必要になる言語

• 文字セットがオペレーティング・システムで使用可能かどうか

• クライアントで使用する文字セット

• その文字セットがアプリケーションで適切に処理されるかどうか

• 文字セットがパフォーマンスに与える影響

• 文字セットに関連付けられている制限

Oracle Database文字セットのリストは、「文字セット」を参照してください。Oracle文字セット名は、言語とそれが使用される地域に基づいています。地域名が付いている一部の文字セットは、リストに言語でも明示的に示されています。

ある文字セットに含まれている文字を確認するには、次の方法があります。

• 各国製品、国際的製品またはベンダー製品のドキュメントあるいは規格ドキュメントをチェックします。

• Oracle Locale Builderを使用します。

この項では、次の項目について説明します。

• 現在および将来の言語要件

• クライアントのオペレーティング・システムとアプリケーションの互換性

• クライアントとサーバーの間の文字セット変換

• データベース文字セットの選択がパフォーマンスに与える影響

• データベース文字セットに関する制限事項

• 各国語文字セットの選択

• サポート対象のデータ型の概要

  関連項目:

  • 「UCS-2エンコード形式」

  • 「各国語文字セットの選択」

  • 「データベース作成後の文字セットの変更」

  • ロケール・データ

  • ロケール・データのカスタマイズ

2.3.1 現在および将来の言語要件

複数の文字セットを使用して現在の言語要件を満たすことができる可能性があります。データベース文字セットの選択時には、将来の言語要件を考慮してください。将来、追加の言語サポートが必要になると思われる場合は、後で異なる文字セットへの移行が必要にならないように、その言語をサポートしている文字セットを選択します。Unicode文字セットAL32UTF8は世界のほとんどの言語をサポートしているため、通常はUnicode文字セットAL32UTF8を選択してください。

ノート:

Oracle Database 12cリリース2以降、データベースの作成にOracle Universal Installer (OUI)またはOracle Database Configuration Assistant (DBCA)を使用する場合、使用されるデフォルトのデータベース文字セットはUnicode文字セットAL32UTF8です。

2.3.2 クライアントのオペレーティング・システムとアプリケーションの互換性

Oracle Databaseには独自のグローバリゼーション・アーキテクチャがあるため、データベース文字セットはオペレーティング・システムに依存しません。たとえば、英語版Windowsオペレーティング・システムで、日本語文字セットを使用してデータベースを作成し、稼働することができます。ただし、クライアントのオペレーティング・システム上のアプリケーションがそのデータベースにアクセスするには、適切なフォントと入力メソッドでデータベース文字セットをサポートできる必要があります。たとえば、英語版Windowsオペレーティング・システムでは、先に日本語フォントと入力メソッドをインストールしなければ、日本語データの挿入や取出しができません。日本語のデータを挿入および取得するもう1つの方法として、リモートで日本語オペレーティング・システムを使用してデータベース・サーバーにアクセスする方法もあります。

2.3.3 クライアントとサーバーの間の文字セット変換

クライアントのオペレーティング・システム上の文字セットと異なるデータベース文字セットを選択した場合、Oracle Databaseでは、オペレーティング・システムの文字セットをデータベース文字セットに変換できます。文字セット変換には、次のデメリットがあります。

• データ消失の可能性

• オーバーヘッドの増加

文字セット変換がデータ消失の原因になる場合があります。たとえば、文字セットAを文字セットBに変換する場合、変換先の文字セットBには、Aと同じ文字セット・レパートリが含まれている必要があります。文字セットBで使用できない文字は、置換文字に変換されます。この置換文字は、多くの場合、疑問符や言語的に関連する文字で指定されます。たとえば、ä(ウムラウト付きのa)は、aに変換できます。分散環境の場合には、類似した文字レパートリを持つ文字セットを使用してデータ消失を回避してください。

文字セット変換では、データがクライアントに到達するまでに文字列が何度もバッファ間でコピーされる場合があります。データベース文字セットは、常に、クライアントのオペレーティング・システム固有の文字セットと同等か、そのスーパーセットである必要があります。通常は、データベースにアクセスするクライアント・アプリケーションの文字セットによって、最適なスーパーセットが決定します。

すべてのクライアント・アプリケーションが同じ文字セットを使用している場合は、その文字セットが、通常、データベース文字セットとして最善の選択肢です。複数のクライアント・アプリケーションが異なる文字セットを使用している場合、データベース文字セットは、クライアントのすべての文字セットのスーパーセットである必要があります。これによって、クライアント文字セットからデータベース文字セットへの変換時に、すべての文字が確実に受け渡されます。

関連項目:

文字セットの移行

2.3.4 データベース文字セットの選択がパフォーマンスに与える影響

最適なパフォーマンスのためには、変換が不要な文字セットを選択し、使用言語にとって最も効率的なエンコーディングを使用してください。シングルバイト文字セットは、パフォーマンスの点で、マルチバイト文字セットよりも優れており、領域要件に関しても、シングルバイト文字セットが最も効率的です。ただし、シングルバイト文字セットには、サポートできる言語の種類に制限があります。

2.3.5 データベース文字セットに関する制限事項

ASCIIベースの文字セットがサポートされているのは、ASCIIベースのプラットフォーム上のみです。同様に、EBCDICベースの文字セットが使用できるのは、EBCDICベースのプラットフォーム上のみです。

データベース文字セットは、SQLとPL/SQLソース・コードの識別に使用します。このためには、データベース文字セットに、プラットフォーム固有のEBCDICまたは7ビットASCIIのいずれかがサブセットとして含まれている必要があります。したがって、固定幅のマルチバイト文字セットをデータベース文字セットとして使用することはできません。現在、データベース文字セットとして使用できないのはAL16UTF16文字セットのみです。

2.3.5.1 名前を表すために使用する文字セットに関する制限事項

次の表に、名前を表すために使用できる文字セットに関する制限事項を示します。

表2-5 名前を表すために使用する文字セットに関する制限事項

名前	シングルバイト	可変幅	コメント
列名	可能	可能	-
スキーマ・オブジェクト	可能	可能	-
コメント	可能	可能	-
データベース・リンク名	可能	不可	-
データベース名	可能	不可	-
ファイル名 (データ・ファイル、ログ・ファイル、制御ファイル、初期化パラメータ・ファイル)	可能	不可	-
インスタンス名	可能	不可	-
ディレクトリ名	可能	不可	-
キーワード	可能	不可	英語ASCIIまたはEBCDIC文字でのみ表現可能です。
Recovery Managerファイル名	可能	不可	-
ロールバック・セグメント名	可能	不可	ROLLBACK_SEGMENTSパラメータはNLSをサポートしていません。
ストアド・スクリプト名	可能	可能	-
表領域名	可能	不可	-

LOBデータ(LOB、BLOB、CLOBおよびNCLOB)などのサポート対象の文字列形式と文字セットについては、表2-7を参照してください。

2.3.6 データベース文字セットに関する指示書

表A-4および表A-5に、データベース文字セットとして使用することを推奨する文字セットのリストを示しています。このリストにない、Oracleでサポートされるその他の文字セットは、引き続きこのリリースのOracle Databaseで使用できますが、将来のリリースでサポートされなくなる可能性があります。Oracle Database 11g リリース1以降、Oracle Universal Installer (OUI)およびOracle Database Configuration Assistant (DBCA)の共通インストール・パスでのデータベース文字セットの選択肢は、この推奨文字セットのリストに制限されます。ただし、文字セットが推奨リストに含まれていない場合でも、従来どおりカスタム・インストールのパスを使用して新規データベースを作成し、既存のデータベースを移行できます。ただし、できるだけ早く推奨文字セットに移行することをお薦めします。すべての新規システム・デプロイメントについて推奨する文字セット・リストの最上部には、Unicode文字セットAL32UTF8があります。

ノート:

Oracle Database 12c リリース2以降、データベースの作成にOracle Universal Installer (OUI)またはOracle Database Configuration Assistant (DBCA)を使用する場合、使用されるデフォルトのデータベース文字セットはAL32UTF8です。

2.3.7 データベース文字セットとしてのUnicodeの選択

新しいシステムのデプロイメントには、すべてUnicodeを使用することをお薦めします。レガシー・システムもUnicodeに移行することをお薦めします。現在システムをUnicodeでデプロイすると、利便性、互換性および拡張性の面で多くの利点があります。Oracle Databaseを使用すると、Unicodeの利点を利用しながら、高パフォーマンスのシステムをより迅速かつより容易にデプロイすることができます。現時点で多言語データをサポートする必要がない場合、またはUnicodeが必要ない場合でも、長期的には新規システムに最適な選択となる可能性が高く、結局は時間を短縮してコストを節減し、競争上の優位性を得ることになります。

関連項目:

Unicodeを使用した多言語データベースのサポート

2.3.8 各国語文字セットの選択

各国語文字セットとは、Unicodeデータベース文字セットがないデータベースにUnicodeの文字データを格納するための代替文字セットです。各国語文字セットを選択する別の理由は、それぞれの文字コード体系が持つ性質が、幅広い文字処理操作に向いているということです。

SQL NCHAR、NVARCHAR2およびNCLOBデータ型は、Unicodeデータのみをサポートします。UTF8またはAL16UTF16文字セットを使用できます。デフォルトはAL16UTF16です。

Unicode文字データを格納する場合は、AL32UTF8データベースでCHAR、VARCHAR2、およびCLOBの各SQLデータ型を使用することをお薦めします。文字セットがAL32UTF8以外のデータベースを使用する必要がある場合にのみ、NCHAR、NVARCHAR2、およびNCLOBの各SQLデータ型の使用を検討するようにしてください。

関連項目:

Unicodeを使用した多言語データベースのサポート

2.3.9 サポート対象のデータ型の概要

次の表に、様々なコード体系についてサポート対象のデータ型を示します。

表2-6 コード体系のサポート対象のSQLデータ型

データ型	シングルバイト	マルチバイトのUnicode以外	マルチバイトのUnicode
CHAR	可能	可能	可能
VARCHAR2	可能	可能	可能
NCHAR	不可	不可	可能
NVARCHAR2	不可	不可	可能
BLOB	可能	可能	可能
CLOB	可能	可能	可能
LONG	可能	可能	可能
NCLOB	不可	不可	可能

ノート:

BLOBでは、文字は一連のバイト順序として処理されます。データは、NLSに関連した操作の対象にはなりません。

次の表に、抽象データ型についてサポート対象のSQLデータ型を示します。

表2-7 SQLデータ型のサポート対象の抽象データ型

抽象データ型	CHAR	NCHAR	BLOB	CLOB	NCLOB
オブジェクト	可能	可能	可能	可能	可能
コレクション	可能	可能	可能	可能	可能

次のように、NCHAR属性を使用して抽象データ型を作成できます。

SQL> CREATE TYPE tp1 AS OBJECT (a NCHAR(10));
Type created.
SQL> CREATE TABLE t1 (a tp1);
Table created.

関連項目:

• Oracleオブジェクトの詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください

• Oracleコレクションの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください

2.4 マルチテナント・コンテナ・データベースのデータベース文字セットの選択

ノート:

マルチテナント・コンテナ・データベースは、Oracle Database 20cでサポートされている唯一のアーキテクチャです。ドキュメントが改訂途中の間は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じてCDBまたはPDBを指しています。アップグレードなどでは、「非CDB」が以前のリリースの非CDBを指している場合もあります。

Oracle Database 12cリリース2 (12.2)以降、マスチテナント・コンテナ・データベース(CDB)内のプラガブル・データベース(PDB)に、異なるデータベース文字セットと異なる各国語文字セットを指定できます。CDBにプラグインできるデータベースまたはPDB候補としては、従来の独立したデータベースまたは他のCDBからアンプラグされた既存のPDB、またはCDB内の新たに作成されたPDBがあります。

ノート:

CDBルートの文字セットは、CDB全体の文字セットとみなされます。

次の使用例は、CDBにプラグインする必要のあるPDB候補のデータベース文字セットに応じて発生する可能性があります。

• PDB候補が、アプリケーションにプラグインするアプリケーションPDBである場合:

  • PDB候補のデータベース文字セットがアプリケーション・ルートのデータベース文字セットと同じ場合、(データベース文字セットに関するかぎり)プラグイン操作は成功します。

  • PDB候補のデータベース文字セットがアプリケーション・ルートのデータベース文字セットとプラグ互換性がある場合、つまり、PDB候補のデータベース文字セットがアプリケーション・ルートのデータベース文字セットのバイナリ・サブセットであり、両方がシングルバイトまたはマルチバイトである場合、PDB候補を初めて開いてプラグイン操作が成功したときに、PDB候補のデータベース文字セットは自動的にアプリケーション・ルートのデータベース文字セットに変更されます。

  • PDB候補のデータベース文字セットが、アプリケーション・ルートのデータベース文字セットとプラグ互換性がない場合(前述の2つの使用例のいずれにも該当しない場合)、プラグイン操作は成功します。ただし、この場合、新たにプラグインしたPDBは管理タスク用に制限モードでのみ開くことができ、本番用には使用できません。新しいPDBのデータベース文字セットをアプリケーション・ルートのデータベース文字セットに移行しない場合、新しいPDBは使用できません。

• PDB候補がCDBルートに直接プラグインされる場合:

  • PDB候補のデータベース文字セットがCDBのデータベース文字セットと同じ場合、(データベース文字セットに関するかぎり)プラグイン操作は成功します。

  • CDBのデータベース文字セットがAL32UTF8である場合、PDB候補のデータベース文字セットに関係なく、プラグイン操作は成功します。

  • PDB候補のデータベース文字セットがCDBのデータベース文字セットとプラグ互換性がある場合、つまり、PDB候補のデータベース文字セットがCDBのデータベース文字セットのバイナリ・サブセットであり、両方がシングルバイトまたはマルチバイトである場合、PDB候補を初めて開いてプラグイン操作が成功したときに、PDB候補のデータベース文字セットは自動的にCDBのデータベース文字セットに変更されます。

  • PDB候補のデータベース文字セットが、CDBのデータベース文字セットとプラグ互換性がない場合、つまり、前述の3つの使用例のいずれにも該当しない場合、プラグイン操作は成功します。ただし、この場合、新たにプラグインしたPDBは管理タスク用に制限モードでのみ開くことができ、本番用には使用できません。新しいPDBのデータベース文字セットをCDBのデータベース文字セットに移行しない場合、新しいPDBは使用できません。

関連項目:

• 文字セットのバイナリ・サブセットおよびバイナリ・スーパーセットの詳細は、「サブセットとスーパーセット」を参照してください。

次の使用例は、CDBにプラグインする必要のあるPDB候補の各国語文字セットに応じて発生する可能性があります。

• PDB候補が、アプリケーションにプラグインするアプリケーションPDBである場合:

  • PDB候補の各国語文字セットがアプリケーション・ルートのデータベース文字セットと同じ場合、(各国語文字セットに関するがぎり)プラグイン操作は成功します。

  • PDB候補の各国語文字セットがアプリケーション・ルートのデータベース文字セットと同じでない場合、プラグイン操作は成功します。ただし、この場合、新たにプラグインしたPDBは管理タスク用に制限モードでのみ開くことができ、本番用には使用できません。新しいPDBの各国語文字セットをアプリケーション・ルートの各国語文字セットに移行しない場合、新しいPDBは使用できません。

• PDB候補がCDBルートに直接プラグインされる場合、(各国語文字セットに関するかぎり)プラグイン操作は成功します。

ノート:

• PDBの文字セットがCDBの文字セットとは異なる場合、CDBビューおよびV$ビューの列幅に、文字セットの変換中に文字長が長くなったPDBデータが収まらない場合には、データが切り捨てられる可能性があります。

• UTF8およびAL32UTF8の最大文字幅が異なる場合(文字ごとに3バイトと4バイト)、プラグイン操作中のUTF8からAL32UTF8への自動変更により、文字長セマンティクスで列の暗黙的な最大バイト幅が変更されます。ファンクション索引、仮想列、ビットマップ結合索引、ドメイン索引、パーティション化キー、サブパーティション化キー、またはクラスタ・キーがこれらの列に定義されている場合、この変更が失敗することがあります。プラグイン操作は、文字長セマンティクス列が索引キーの一部で、文字セットの変更後に、索引キーがサイズの制限を超えた場合(索引ブロック・サイズの約70%)にも失敗することがあります。CDBにプラグインされる前に、問題なっているすべてのオブジェクトをデータベースから削除する必要があります。データベースがCDBにプラグインされた後、これらの問題なっているオブジェクトをデータベースで再作成できます。

これらの制限事項により、CDBの文字セットの選択時には次のことをお薦めします。

• すべての新しいマルチテナントのデプロイメントでは、データベース文字セットとしてAL32UTF8を使用し、CDBの各国語文字セットとしてAL16UTF16を使用します。

• 統合前に既存のデータベースをAL32UTF8データベース文字セットに移行し、必要に応じて、データベースを1つ以上のAL32UTF8 CDBに統合します。非CDBをAL32UTF8データベース文字セットに移行する場合は、Oracle Database Migration Assistant for Unicodeソフトウェアを使用できます。

関連項目:

• CDB、PDBおよびアプリケーション・コンテナの詳細は、Oracle Database概要およびOracle Multitenant管理者ガイドを参照してください。

• 非Unicodeデータベース文字セットをUnicodeデータベース文字セットに移行する方法の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。

2.5 データベース作成後の文字セットの変更

データベースの作成後に、データベース文字セットの変更が必要になる場合があります。たとえば、使用しているデータベースでサポートする必要がある言語数が増加したため、Unicode文字セットAL32UTF8に移行することがあります。

データベース内の文字型のデータをUnicodeに変換する必要があるため、ほとんどのケースで、データベース文字セットをAL32UTF8に変更する際に問題が発生します。たとえば、CHAR列とVARCHAR2列のデータが、宣言された列の長さよりも長くなる可能性があります。文字データをUnicodeに変換する際に、その中に無効な文字が含まれていると、データが失われる可能性があります。

データベース文字セットを変更する前に、問題点をすべて洗い出し、データ移行の計画を十分に練ることが重要です。データベース文字セットをAL32UTF8に変更する場合は、Database Migration Assistant for Unicodeを使用することをお薦めします。

ノート:

Oracle Database 12cリリース2以降、データベースの作成にOracle Universal Installer (OUI)またはOracle Database Configuration Assistant (DBCA)を使用する場合、使用されるデフォルトのデータベース文字セットはUnicode文字セットAL32UTF8です。

関連項目:

文字セットの変更方法の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。

2.6 単一言語データベースの使用例

最も単純なデータベース構成の例は、クライアントとサーバーが同じ言語環境で稼働し、同じ文字セットを使用している場合です。この単一言語の使用例には、レスポンスが高速であるという利点があります。これは、文字セット変換に関連するオーバーヘッドが回避されるためです。次の図に、同じ文字セットを使用するデータベース・サーバーとクライアントを示します。日本語クライアントとサーバーの両方が、JA16EUC文字セットを使用しています。

図2-3 単一言語データベースの使用例

「図2-3 単一言語データベースの使用例」の説明

また、複数層アーキテクチャも使用できます。次の図に、データベース・サーバーとクライアントの間にあるアプリケーション・サーバーを示します。アプリケーション・サーバーとデータベース・サーバーは、単一言語の使用例と同じ文字セットを使用しています。サーバー、アプリケーション・サーバーおよびクライアントは、JA16EUC文字セットを使用しています。

図2-4 複数層の単一言語データベースの使用例

「図2-4 複数層の単一言語データベースの使用例」の説明

2.6.1 単一言語の使用例での文字セット変換

クライアント/サーバー環境では、クライアント・アプリケーションがサーバーと異なるプラットフォームにある場合や、プラットフォームで同じ文字コード体系が使用されていない場合に、文字セット変換が必要になります。クライアントとサーバーの間で受け渡される文字データは、2つのコード体系間で変換される必要があります。文字の変換は、Oracle Netを介して、ユーザーが意識することなく自動的に実行されます。

任意の2つの文字セット間で変換を行うことができます。次の図に、サーバーと日本語JA16EUC文字セットを使用している1つのクライアントを示します。他方のクライアントは、日本語JA16SJIS文字セットを使用しています。

図2-5 文字セットの変換

「図2-5 文字セットの変換」の説明

ターゲットの文字セットにソース・データにあるすべての文字がない場合は、置換文字が使用されます。たとえば、サーバーではUS7ASCIIを、ドイツ語クライアントではWE8ISO8859P1を使用している場合、ドイツ語の文字ßは?に置換され、äはaに置換されます。

置換文字は、文字セットの定義の一部として、特定の文字に対して定義できます。特定の置換文字を定義しないと、デフォルトの置換文字が使用されます。クライアント文字セットからデータベース文字セットへの変換時に置換文字を使用しないようにするには、サーバーの文字セットが、クライアントのすべての文字セットのスーパーセットである必要があります。

次の図に、データベース文字セットにクライアント文字セットのすべての文字が含まれていない場合に発生するデータ消失を示します。データベース文字セットはUS7ASCIIです。クライアントの文字セットはWE8MSWIN1252で、クライアントの使用言語はドイツ語です。クライアントがßを含む文字列を挿入すると、データベースではßが?に置換され、データが消失します。

図2-6 文字変換中のデータ消失

「図2-6 文字変換中のデータ消失」の説明

ドイツ語データがサーバーに格納されると想定される場合は、データ消失と変換オーバーヘッドを回避するために、サーバーとクライアントの両方で、ドイツ語文字をサポートするデータベース文字セットを使用する必要があります。

文字セットの一方が可変幅マルチバイト文字セットの場合は、変換によって著しいオーバーヘッドが生じる可能性があります。状況を慎重に評価した上で文字セットを選択し、変換をできるかぎり回避する必要があります。

2.7 多言語データベースの使用例

多言語サポートが必要な場合は、サーバーのデータベース文字セットにUnicode AL32UTF8を使用します。

ノート:

Oracle Database 12cリリース2以降、データベースの作成にOracle Universal Installer (OUI)またはOracle Database Configuration Assistant (DBCA)を使用する場合、使用されるデフォルトのデータベース文字セットはUnicode文字セットAL32UTF8です。

Unicodeには、主に次の2つのコード体系があります。

• UTF-16: 各文字は長さ2バイトまたは4バイトです。

• UTF-8: 各文字の格納には1から4バイト必要です。

Oracle Databaseでは、データベース文字セットとしてUTF-8が、各国語文字セットとしてUTF-8とUTF-16の両方がサポートされています。

UTF-8のデータベースとシングルバイト文字セットとの間での文字セット変換では、ごくわずかなオーバーヘッドが生じます。

UTF-8とマルチバイト文字セットとの間での変換では、多少のオーバーヘッドが生じます。変換によるデータ消失はありませんが、これには次の例外があります。

• 一部のマルチバイト文字セットは、UTF-8との間の文字セット変換で、ユーザー定義文字をサポートしていません。

• 一部のUnicode文字は、他の文字セットで複数文字にマップされます。たとえば、1つのUnicode文字はJA16SJIS文字セットの3文字にマップされます。これは、ラウンドトリップ変換でオリジナルのJA16SJIS文字に変換されない場合があることを意味します。

次の図に、Unicode UTF-8文字セットに基づくOracle Database文字セットAL32UTF8を使用するサーバーを示します。

図2-7 クライアント/サーバー構成での多言語サポートの使用例

「図2-7 クライアント/サーバー構成での多言語サポートの使用例」の説明

次の4つのクライアントがあるとします。

• Oracle Databaseの文字セットWE8ISO8859P1を使用するフランス語クライアント

• WE8DEC文字セットを使用するドイツ語クライアント

• AL32UTF8文字セットを使用する日本語クライアント

• JA16SJIS文字セットを使用する日本語クライアント

AL32UTF8クライアントの場合を除いて、各クライアントとサーバーの間で文字変換が発生しますが、AL32UTF8がユニバーサル文字セットであるためデータ消失は生じません。ドイツ語クライアントが日本語クライアントの1つからデータを取り出そうとすると、文字セット変換中にデータに含まれる日本語文字がすべて消失します。

次の図に、複数層構成でのUnicodeソリューションを示します。

図2-8 複数層構成での複数層の多言語サポートの使用例

「図2-8 複数層構成での複数層の多言語サポートの使用例」の説明

データベース、アプリケーション・サーバーおよび各クライアントは、AL32UTF8文字セットを使用しています。このため、クライアントがフランス語、ドイツ語および日本語であっても、文字変換を行う必要はありません。

関連項目:

Unicodeを使用した多言語データベースのサポート