| Oracle® Databaseグローバリゼーション・サポート・ガイド 12cリリース1 (12.1) B71319-06 |
|
 前へ |
 次 |
この章では、キャラクタ・セットの選択方法について説明します。この章の内容は、次のとおりです。
文字を処理する場合、コンピュータ・システムは文字をグラフィカルな表現としてではなく数値コードとして処理します。たとえば、データベースに文字Aを格納すると、実際はコンピュータ・システムによって解析される数値コードが格納されます。特に、異なるキャラクタ・セット間のデータ変換を必要とする可能性があるグローバル環境では、この数値コードが重要になります。
この項の内容は、次のとおりです。
データベースの作成時に、エンコードされたキャラクタ・セットを指定します。キャラクタ・セットの選択によって、データベース内で表現できる言語が決定します。また、キャラクタ・セットの選択は次の方法にも影響します。
データベース・スキーマの作成方法
文字データを処理するアプリケーションの開発方法
オペレーティング・システムでのデータベースの動作
データベースのパフォーマンス
キャラクタ・データの格納に必要な記憶域
文字の集まり(アルファベット文字、表意文字、記号、句読点および制御文字など)は、キャラクタ・セットとしてエンコードできます。エンコードされたキャラクタ・セットは、キャラクタ・セット内のそれぞれの文字を表す一意の数値コードに対応しています。数値コードはコード・ポイントまたはエンコーディング値と呼ばれます。次の表に、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 Databaseでサポートされているすべてのキャラクタ・セットのリストは、「キャラクタ・セット」を参照してください
キャラクタ・セットでエンコードされる文字は、表現する記述法によって異なります。記述法は、1つの言語または1つの言語グループを表現するために使用できます。記述法は次の2つに分類できます。
この項の内容は、次のとおりです。
ほとんどの欧米言語は、ページの上から下へ向かって左から右へ記述されます。東アジアの言語は、通常、ページの右から左に向かって上から下へ記述されますが、欧米言語から翻訳された技術文書ではしばしば例外が見られます。アラビア語とヘブライ語は、上から下へ向かって右から左へ記述されます。
アラビア語とヘブライ語では、数字の記述方向が逆になります。テキストが右から左に書かれている場合でも、文中の数字は左から右に向かって書かれます。たとえば、「I wrote 32 books」は「skoob 32 etorw I」と書かれます。書込み方向に関係なく、データは論理順序で格納されます。論理順序は、入力している言語の画面上での表示方法ではなく、その言語の入力で使用されている順序を意味します。
記述方向は、文字のエンコーディングには影響しません。
様々なキャラクタ・セットによって、様々な文字レパートリがサポートされています。一般的に、キャラクタ・セットは特定の書込みスクリプトに基づいているため、複数の言語をサポートできます。キャラクタ・セットが最初に開発されたとき、文字レパートリには制限がありました。今でも、特定の文字を複数のプラットフォームで使用すると、問題が発生する場合があります。次の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データベースとデータ型の使用をお薦めします。
関連項目:
CONVERT SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
CHR SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
表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 |
米国 |
/ |
? |
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つで、現代の主要なスクリプトのほとんどを包含しています。バージョン6.2の時点で、Unicode規格は、110,000以上の文字をエンコードします。
コンピュータ業界では、様々なタイプのコード体系が作成されてきました。選択するキャラクタ・セットによって、使用するコード体系の種類が異なります。コード体系には様々なパフォーマンス特性があります。これらの特性は、データベース・スキーマやアプリケーションの開発に影響を及ぼす場合があります。選択したキャラクタ・セットは、次のコード体系のいずれかを使用します。
シングルバイト・コード体系は効率的です。シングルバイトの1文字は1バイトで表現されるため、文字を表現するのに必要な領域量が最も小さく、処理およびプログラミングでの使用が容易です。シングルバイト・コード体系は、次のいずれかのタイプとして分類されます。
シングルバイト7ビット・コード体系は、128文字までの文字を定義でき、通常、1つの言語のみをサポートします。最も一般的なシングルバイト・キャラクタ・セットは、ASCII(American Standard Code for Information Interchange)で、コンピュータ処理の初期から使用されています。
シングルバイト8ビット・コード体系は、256文字までの文字を定義でき、通常、1つの関連言語グループをサポートします。たとえば、ISO 8859-1は、西ヨーロッパ諸国の多数の言語をサポートしています。図2-1に、ISO 8859-1の8ビット・コード体系を示します。
マルチバイト・コード体系は、中国語や日本語のようなアジア言語の表意文字をサポートするために必要です。これは、中国語や日本語では何千という文字が使用されるためです。このコード体系では、各文字を表現するために固定または可変のバイト数を使用します。
固定幅マルチバイト・コード体系では、各文字が固定のバイト数で表現されます。マルチバイト・コード体系では、バイト数は2以上です。
可変幅コード体系は、1バイト以上を使用して1つの文字を表現します。一部のマルチバイト・コード体系は、特定のビットを使用して、1文字を表現するためのバイト数を示します。たとえば、1文字の表現に使用する最大のバイト数が2バイトの場合は、最上位ビットを使用して、そのバイトがシングルバイト文字であるか、ダブルバイト文字の1番目のバイトであるかを示します。
一部の可変幅コード体系では、制御コードを使用して、同じコード値を持つシングルバイト文字とマルチバイト文字が区別されます。シフトアウト・コードは後続の文字がマルチバイトであることを示します。シフトイン・コードは後続の文字がシングルバイトであることを示します。シフト・センシティブ・コード体系は、主にIBMプラットフォームで使用されます。ISO-2022キャラクタ・セットは、データベース・キャラクタ・セットとしては使用できませんが、メール・サーバーなどのアプリケーションには使用できることに注意してください。
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 |
U.S. 7ビットASCII |
米国 |
7 |
ASCII |
WE8ISO8859P1 |
西ヨーロッパ8ビットISO 8859 Part1 |
WE(西ヨーロッパ) |
8 |
ISO8859の第1部 |
JA16SJIS |
日本語16ビットシフトJIS |
JA |
16 |
SJIS |
データベース間のキャラクタ・セットの変換または互換性について説明する際、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では、そのキャラクタ・セットのすべてのサブセット/スーパーセットのペアのリストを保持するわけではなく、トランスポータブル表領域やプラガブル・データベースの互換性を確認するときなど、様々な状況で認識されるバイナリ・サブセット/スーパーセットのペアのリストを保持します。表A-11および表A-12では、Oracle Databaseで認識されるバイナリ・サブセット/スーパーセットの組を示します
シングルバイト・キャラクタ・セットの場合、文字列のバイト数と文字数は同じです。マルチバイト・キャラクタ・セットの場合は、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バイトの領域を占有します。
図2-2に、UTF-8キャラクタ・セットで各種文字を格納するために必要なバイト数を示します。ASCII文字には1バイト、ASCII以外のラテン語、ギリシャ語、キリル語、アラブ語、およびヘブライ語の文字には2バイト、アジア言語の文字には3バイト、補助文字には4バイトの記憶域が必要です。
関連項目:
SUBSTRおよびSUBSTRB関数の詳細は、「様々な長さセマンティクスに使用するSQL関数」を参照してください
NLS_LENGTH_SEMANTICS初期化パラメータの詳細は、「長さセマンティクス」を参照してください
UnicodeとNCHARデータ型の詳細は、「Unicodeを使用した多言語データベースのサポート」を参照してください
SUBSTRBおよびSUBSTR関数と文字型データのBYTEおよびCHAR修飾子の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
Oracle Databaseでは、次の項目でデータベース・キャラクタ・セットを使用します。
データベースで使用される文字コード体系は、CREATE DATABASE文の一部として定義されます。データ・ディクショナリ内の列を含めて、すべてのSQL CHARデータ型列(CHAR、CLOB、VARCHAR2およびLONG)のデータは、データベース・キャラクタ・セットに格納されます。さらに、選択するデータベース・キャラクタ・セットによって、データベース内のオブジェクトに名前を指定できる文字が決定されます。SQL NCHARデータ型列(NCHAR、NCLOBおよびNVARCHAR2)では、各国語キャラクタ・セットが使用されます。
データベースの作成後は、一部の例外を除いて、データベースを再作成せずにキャラクタ・セットを変更することはできません。
データベース用のOracle Databaseキャラクタ・セットを選択する場合は、次の項目について考慮する必要があります。
データベースでサポートする必要がある言語
データベースで将来サポートが必要になる言語
キャラクタ・セットがオペレーティング・システムで使用可能かどうか
クライアントで使用するキャラクタ・セット
そのキャラクタ・セットがアプリケーションで適切に処理されるかどうか
キャラクタ・セットがパフォーマンスに与える影響
キャラクタ・セットに関連付けられている制限
Oracleデータベース・キャラクタ・セットのリストは、「キャラクタ・セット」を参照してください。Oracleキャラクタ・セット名は、言語とそれが使用される地域に基づいています。地域名が付いている一部のキャラクタ・セットは、リストに言語でも明示的に示されています。
あるキャラクタ・セットに含まれている文字を確認するには、次の方法があります。
各国製品、国際的製品またはベンダー製品のドキュメントあるいは規格ドキュメントをチェックします。
Oracle Locale Builderを使用します。
この項の内容は、次のとおりです。
複数のキャラクタ・セットを使用して現在の言語要件を満たすことができる可能性があります。データベース・キャラクタ・セットの選択時には、将来の言語要件を考慮してください。将来、追加の言語サポートが必要になると思われる場合は、後で異なるキャラクタ・セットへの移行が必要にならないように、その言語をサポートしているキャラクタ・セットを選択します。Unicodeキャラクタ・セットAL32UTF8は世界のほとんどの言語をサポートしているため、通常はUnicodeキャラクタ・セットAL32UTF8を選択してください。
Oracle Databaseには独自のグローバリゼーション・アーキテクチャがあるため、データベース・キャラクタ・セットはオペレーティング・システムに依存しません。たとえば、英語版Windowsオペレーティング・システムで、日本語キャラクタ・セットを使用してデータベースを作成し、稼働することができます。ただし、クライアントのオペレーティング・システム上のアプリケーションがそのデータベースにアクセスするには、適切なフォントと入力メソッドでデータベース・キャラクタ・セットをサポートできる必要があります。たとえば、英語版Windowsオペレーティング・システムでは、先に日本語フォントと入力メソッドをインストールしなければ、日本語データの挿入や取出しができません。日本語のデータを挿入および取得するもう1つの方法として、リモートで日本語オペレーティング・システムを使用してデータベース・サーバーにアクセスする方法もあります。
クライアントのオペレーティング・システム上のキャラクタ・セットと異なるデータベース・キャラクタ・セットを選択した場合、Oracle Databaseでは、オペレーティング・システムのキャラクタ・セットをデータベース・キャラクタ・セットに変換できます。キャラクタ・セット変換には、次のデメリットがあります。
データ消失の可能性
オーバーヘッドの増加
キャラクタ・セット変換がデータ消失の原因になる場合があります。たとえば、キャラクタ・セットAをキャラクタ・セットBに変換する場合、変換先のキャラクタ・セットBには、Aと同じキャラクタ・セット・レパートリが含まれている必要があります。キャラクタ・セットBで使用できない文字は、置換文字に変換されます。この置換文字は、多くの場合、疑問符や言語的に関連する文字で指定されます。たとえば、ä(ウムラウト付きのa)は、aに変換できます。分散環境の場合には、類似した文字レパートリを持つキャラクタ・セットを使用してデータ消失を回避してください。
キャラクタ・セット変換では、データがクライアントに到達するまでに文字列が何度もバッファ間でコピーされる場合があります。データベース・キャラクタ・セットは、常に、クライアントのオペレーティング・システム固有のキャラクタ・セットと同等か、そのスーパーセットである必要があります。通常は、データベースにアクセスするクライアント・アプリケーションのキャラクタ・セットによって、最適なスーパーセットが決定します。
すべてのクライアント・アプリケーションが同じキャラクタ・セットを使用している場合は、そのキャラクタ・セットが、通常、データベース・キャラクタ・セットとして最善の選択肢です。複数のクライアント・アプリケーションが異なるキャラクタ・セットを使用している場合、データベース・キャラクタ・セットは、クライアントのすべてのキャラクタ・セットのスーパーセットである必要があります。これによって、クライアント・キャラクタ・セットからデータベース・キャラクタ・セットへの変換時に、すべての文字が確実に受け渡されます。
関連項目:
ASCIIベースのキャラクタ・セットがサポートされているのは、ASCIIベースのプラットフォーム上のみです。同様に、EBCDICベースのキャラクタ・セットが使用できるのは、EBCDICベースのプラットフォーム上のみです。
データベース・キャラクタ・セットは、SQLとPL/SQLソース・コードの識別に使用します。このためには、データベース・キャラクタ・セットに、プラットフォーム固有のEBCDICまたは7ビットASCIIのいずれかがサブセットとして含まれている必要があります。したがって、固定幅のマルチバイト・キャラクタ・セットをデータベース・キャラクタ・セットとして使用することはできません。現在、データベース・キャラクタ・セットとして使用できないのはAL16UTF16キャラクタ・セットのみです。
表2-5に、名前を表すために使用できるキャラクタ・セットに関する制限事項を示します。
表2-5 名前を表すために使用するキャラクタ・セットに関する制限事項
| 名前 | シングルバイト | 可変幅 | コメント |
|---|---|---|---|
列名 |
可能 |
可能 |
- |
スキーマ・オブジェクト |
可能 |
可能 |
- |
コメント |
可能 |
可能 |
- |
データベース・リンク名 |
可能 |
不可 |
- |
データベース名 |
可能 |
不可 |
- |
ファイル名(データ・ファイル、ログ・ファイル、制御ファイル、初期化パラメータ・ファイル) |
可能 |
不可 |
- |
インスタンス名 |
可能 |
不可 |
- |
ディレクトリ名 |
可能 |
不可 |
- |
キーワード |
可能 |
不可 |
英語ASCIIまたはEBCDIC文字でのみ表現可能です。 |
Recovery Managerファイル名 |
可能 |
不可 |
- |
ロールバック・セグメント名 |
可能 |
不可 |
|
ストアド・スクリプト名 |
可能 |
可能 |
- |
表領域名 |
可能 |
不可 |
- |
LOBデータ(LOB、BLOB、CLOBおよびNCLOB)などのサポート対象の文字列形式とキャラクタ・セットについては、表2-7を参照してください。
データベース・キャラクタ・セットとして使用するためにオラクル社が推奨するキャラクタ・セットのリストが表A-4および表A-5にコンパイルされました。このリストにない、Oracleでサポートされるその他のキャラクタ・セットは、引き続きOracle Database 11cで使用できますが、将来のリリースでサポートされなくなる可能性があります。Oracle Database 11gリリース1以降、Oracle Universal InstallerおよびOracle Database Configuration Assistantの共通インストール・パスでのデータベース・キャラクタ・セットの選択肢は、この推奨キャラクタ・セットのリストに制限されます。ただし、キャラクタ・セットが推奨リストに含まれていない場合でも、従来どおりカスタム・インストールのパスを使用して新規データベースを作成し、既存のデータベースを移行できます。ただし、できるだけ早く推奨キャラクタ・セットに移行することをお薦めします。すべての新規システム・デプロイメントについて推奨するキャラクタ・セット・リストの最上部には、Unicodeキャラクタ・セットAL32UTF8があります。
すべての新規システム・デプロイメントにUnicodeを使用することをお薦めします。レガシー・システムもUnicodeに移行することをお薦めします。現在システムをUnicodeでデプロイすると、利便性、互換性および拡張性の面で多くの利点があります。Oracle Databaseによって、Unicodeの利点を活かしながら高パフォーマンス・システムを高速かつ容易にデプロイできます。現時点で多言語データをサポートする必要がない場合、またはUnicodeが必要ない場合でも、長期的には新規システムに最適な選択となる可能性が高く、結局は時間を短縮してコストを節減し、競争上の優位性を得ることになります。
各国語キャラクタ・セットとは、Unicodeデータベース・キャラクタ・セットがないデータベースにUnicodeの文字データを格納するための代替キャラクタ・セットです。各国語キャラクタ・セットを選択する別の理由は、それぞれの文字コード体系が持つ性質が、幅広い文字処理操作に向いているということです。
SQL NCHAR、NVARCHAR2およびNCLOBデータ型は、Unicodeデータのみをサポートします。UTF8またはAL16UTF16キャラクタ・セットを使用できます。デフォルトはAL16UTF16です。
Unicode文字データを格納する場合は、AL32UTF8データベースでCHAR、VARCHAR2、およびCLOBの各SQLデータ型を使用することをお薦めします。キャラクタ・セットがAL32UTF8以外のデータベースを使用する必要がある場合にのみ、NCHAR、NVARCHAR2、およびNCLOBの各SQLデータ型の使用を検討するようにしてください。
表2-6に、様々なコード体系についてサポート対象のデータ型を示します。
表2-6 コード体系のサポート対象のSQLデータ型
| データ型 | シングルバイト | マルチバイトのUnicode以外 | マルチバイトのUnicode |
|---|---|---|---|
|
可能 |
可能 |
可能 |
|
可能 |
可能 |
可能 |
|
不可 |
不可 |
可能 |
|
不可 |
不可 |
可能 |
|
可能 |
可能 |
可能 |
|
可能 |
可能 |
可能 |
|
可能 |
可能 |
可能 |
|
不可 |
不可 |
可能 |
注意:
BLOBでは、文字は一連のバイト順序として処理されます。データは、NLSに関連した操作の対象にはなりません。
表2-7に、抽象データ型についてサポート対象の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 Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください
Oracle Database 12cでは、マルチテナント・コンテナ・データベース(CDB)のすべてのコンテナに、同じデータベース・キャラクタ・セットと同じ各国語キャラクタ・セットがある必要があります。つまり、CDBのすべてのプラガブル・データベース(PDB)には、CDBのルート・コンテナと同じキャラクタ・セットがある必要があります。ルート・コンテナのキャラクタ・セットは、CDB全体のキャラクタ・セットとみなされます。
単一のCDBに複数のデータベースをプラグインして統合できます。これらのデータベースは、他のCDBから切り離された従来の非CDBまたはPDBになります。これらの状況は、プラグインされているデータベースのデータベース・キャラクタ・セット、すなわち新しいPDBに応じて発生します。
キャラクタ・セットは、CDBのデータベース・キャラクタ・セットと同じです。この場合、プラグイン操作は成功します(データベース・キャラクタ・セットに関するかぎり)。
キャラクタ・セットは、CDBのデータベース・キャラクタ・セットとプラグイン互換です。プラグイン互換とは、それがCDBのキャラクタ・セットのバイナリ・サブセットであり、両方がシングルバイトまたはマルチバイトであることを意味します。この場合、新しいPDBのデータベース・キャラクタ・セットは、最初に開いた時点でCDBのデータベース・キャラクタ・セットに自動的に変更され、プラグイン操作が成功します。
キャラクタ・セットは、CDBのデータベース・キャラクタ・セットとプラグイン互換ではありません。この場合、新しいPDBは、管理タスク用に制限モードでのみ開くことができ、本番用に使用することはできません。新しいPDBのデータベース・キャラクタ・セットをCDBのキャラクタ・セットに移行できるツールがない場合、新しいPDBは使用できません。
関連項目:
キャラクタ・セットのバイナリ・サブセットについては、「サブセットとスーパーセット」を参照してください
新しいPDBをプラグインすると、新しいPDBの各国語キャラクタセットに応じて2つの状況が発生します。
キャラクタ・セットは、CDBの各国語キャラクタ・セットと同じです。この場合、プラグイン操作は成功します(各国語キャラクタ・セットに関するかぎり)。
キャラクタ・セットは、CDBの各国語キャラクタ・セットと同じではありません。この場合、新しいPDBは、管理タスク用に制限モードでのみ開くことができ、本番用に使用することはできません。新しいPDBの各国語キャラクタ・セットをCDBのキャラクタ・セットに移行できるツールがない場合、新しいPDBは使用できません。
これらの制限により、このCDBのキャラクタ・セットを選択する際に、指定されたCDBにプラグインするデータベースのキャラクタ・セットを考慮してください。次が推奨されます。
新しいすべてのデプロイメントで、すべてのPDBが空で作成される場合は、CDBデータベース・キャラクタ・セットにAL32UTF8、CDB各国語キャラクタ・セットにAL16UTF16を強くお薦めします。
統合前に既存のデータベースをAL32UTF8に移行できる場合はそのようにし、必要に応じて、1つ以上のAL32UTF8 CDBに統合することをお薦めします。Oracle Database Migration Assistant for Unicodeを使用すると、非CDBをAL32UTF8に移行できます。
統合前に既存のデータベースを移行できない場合は、プラグイン互換のデータベース・キャラクタ・セットでそれらを各セットにパーティション化し、適切なスーパーセット・キャラクタ・セットで各セットを個別のCDBにプラグインする必要があります。たとえば、統合するデータベースがUS7ASCII、WE8ISO8859P1、WE8MSWIN1252、WE8ISO8859P15、JA16SJISTILDE、JA16EUC、KO16KSC5601、KO16MSWIN949、UTF8およびAL32UTF8の場合は、次のように統合する必要があります。
US7ASCII、WE8ISO8859P1およびWE8MSWIN1252をWE8MSWIN1252 CDB
WE8ISO8859P15をWE8ISO8859P15 CDB
JA16SJISTILDEをJA16SJISTILDE CDB
JA16EUCをJA16EUC CDB
KO16KSC5601、KO16MSWIN949をKO16MSWIN949 CDB
UTF8およびAL32UTF8をAL32UTF8 CDB
注意:
UTF8およびAL32UTF8の最大文字幅が異なる場合(文字ごとに3バイトと4バイト)、プラグイン操作中のUTF8からAL32UTF8の自動変更により、文字長セマンティクスで列の暗黙的な最大バイト幅が変更されます。ファンクション索引、仮想列、ビットマップ結合索引、ドメイン索引、パーティション化キー、サブパーティション化キー、またはクラスタ・キーがこれらの列に定義されている場合、この変更が失敗することがあります。この操作は、文字長セマンティクス列が索引キーの一部で、キャラクタ・セットの変更後に、索引キーがサイズの制限を超えた場合(索引ブロック・サイズの約70%)にも失敗することがあります。データベースがプラグインされる前に、問題なっているすべてのオブジェクトをデータベースから削除する必要があります。この操作後に、オブジェクトを再作成できます。
関連項目:
CDBおよびPDBの詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。
データベースのキャラクタ・セットをUnicodeに移行する方法の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。
データベースの作成後に、データベース・キャラクタ・セットの変更が必要になる場合があります。たとえば、使用しているデータベースでサポートする必要がある言語数が増加したため、UnicodeのAL32UTF8に移行することがあります。
データベース内の文字型のデータをUnicodeに変換する必要があるため、ほとんどのケースで、データベース・キャラクタ・セットをAL32UTF8に変更する際に問題が発生します。たとえば、CHAR列とVARCHAR2列のデータが、宣言された列の長さよりも長くなる可能性があります。文字データをUnicodeに変換する際に、その中に無効な文字が含まれていると、データが失われる可能性があります。
データベース・キャラクタ・セットを変更する前に、問題点をすべて洗い出し、データ移行の計画を十分に練ることが重要です。データベース・キャラクタ・セットをAL32UTF8に変更する場合は、Database Migration Assistant for Unicodeを使用することをお薦めします。
関連項目:
キャラクタ・セットの変更方法の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。
最も単純なデータベース構成の例は、クライアントとサーバーが同じ言語環境で稼働し、同じキャラクタ・セットを使用している場合です。この単一言語の使用例には、レスポンスが高速であるという利点があります。これは、キャラクタ・セット変換に関連するオーバーヘッドが回避されるためです。次の図に、同じキャラクタ・セットを使用するデータベース・サーバーとクライアントを示します。日本語クライアントとサーバーの両方が、JA16EUCキャラクタ・セットを使用しています。
また、複数層アーキテクチャも使用できます。次の図に、に、データベース・サーバーとクライアントの間にあるアプリケーション・サーバーを示します。アプリケーション・サーバーとデータベース・サーバーは、単一言語の使用例と同じキャラクタ・セットを使用しています。サーバー、アプリケーション・サーバーおよびクライアントは、JA16EUCキャラクタ・セットを使用しています。
クライアント/サーバー環境では、クライアント・アプリケーションがサーバーと異なるプラットフォームにある場合や、プラットフォームで同じ文字コード体系が使用されていない場合に、キャラクタ・セット変換が必要になります。クライアントとサーバーの間で受け渡される文字データは、2つのコード体系間で変換される必要があります。文字の変換は、Oracle Netを介して、ユーザーが意識することなく自動的に実行されます。
任意の2つのキャラクタ・セット間で変換を行うことができます。次の図に、サーバーと日本語JA16EUCキャラクタ・セットを使用している1つのクライアントを示します。他方のクライアントは、日本語JA16SJISキャラクタ・セットを使用しています。
ターゲットのキャラクタ・セットにソース・データにあるすべての文字がない場合は、置換文字が使用されます。たとえば、サーバーではUS7ASCIIを、ドイツ語クライアントではWE8ISO8859P1を使用している場合、ドイツ語の文字ßは?に置換され、äはaに置換されます。
置換文字は、キャラクタ・セットの定義の一部として、特定の文字に対して定義できます。特定の置換文字を定義しないと、デフォルトの置換文字が使用されます。クライアント・キャラクタ・セットからデータベース・キャラクタ・セットへの変換時に置換文字を使用しないようにするには、サーバーのキャラクタ・セットが、クライアントのすべてのキャラクタ・セットのスーパーセットである必要があります。
次の図に、データベース・キャラクタ・セットにクライアント・キャラクタ・セットのすべての文字が含まれていない場合に発生するデータ消失を示します。データベース・キャラクタ・セットはUS7ASCIIです。クライアントのキャラクタ・セットはWE8MSWIN1252で、クライアントの使用言語はドイツ語です。クライアントがßを含む文字列を挿入すると、データベースではßが?に置換され、データが消失します。
ドイツ語データがサーバーに格納されると想定される場合は、データ消失と変換オーバーヘッドを回避するために、サーバーとクライアントの両方で、ドイツ語文字をサポートするデータベース・キャラクタ・セットを使用する必要があります。
キャラクタ・セットの一方が可変幅マルチバイト・キャラクタ・セットの場合は、変換によって著しいオーバーヘッドが生じる可能性があります。状況を慎重に評価した上でキャラクタ・セットを選択し、変換をできるかぎり回避する必要があります。
多言語サポートが必要な場合は、サーバーのデータベース・キャラクタ・セットにUnicode AL32UTF8を使用します。
注意:
Oracle Database 12cリリース2移行では、データベースの作成にOracle Universal InstallerまたはDatabase Configuration Assistantを使用する場合、デフォルトのデータベース・キャラクタ・セットは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データベース・キャラクタ・セットAL32UTF8を使用するサーバーを示します。
次の4つのクライアントがあるとします。
Oracle Databaseのキャラクタ・セットWE8ISO8859P1を使用するフランス語クライアント
WE8DECキャラクタ・セットを使用するドイツ語クライアント
AL32UTF8キャラクタ・セットを使用する日本語クライアント
JA16SJISキャラクタ・セットを使用する日本語クライアント
AL32UTF8クライアントの場合を除いて、各クライアントとサーバーの間で文字変換が発生しますが、AL32UTF8がユニバーサル・キャラクタ・セットであるためデータ消失は生じません。ドイツ語クライアントが日本語クライアントの1つからデータを取り出そうとすると、キャラクタ・セット変換中にデータに含まれる日本語文字がすべて消失します。
次の図に、複数層構成でのUnicodeソリューションを示します。
データベース、アプリケーション・サーバーおよび各クライアントは、AL32UTF8キャラクタ・セットを使用しています。このため、クライアントがフランス語、ドイツ語および日本語であっても、文字変換を行う必要はありません。
