| Oracle® Databaseグローバリゼーション・サポート・ガイド 12cリリース1 (12.1) B71319-06 |
|
 前へ |
 次 |
この章では、キャラクタ・セット変換とキャラクタ・セットの移行について説明します。この章の内容は、次のとおりです。
使用しているデータベースに適切なキャラクタ・セットを選択することは、重要な決定事項です。データベース・キャラクタ・セットの選択時には、次の要因を考慮する必要があります。
格納する必要があるデータの型
データベースで現在および将来対応する必要のある言語
各キャラクタ・セットの異なるサイズ要件とその要件がパフォーマンスに与える影響
国際的な汎用性を維持し、最新技術や今後の技術、言語の要件に合せるためにUnicodeを選択することをお薦めします。Unicode規格で規定されているキャラクタ・セットは、使用頻度が高い最近の書き言葉にも、めったに使用されない古い文字にもすべて対応しています。また、技術分野、科学分野、音楽表記などの各種の記号にも対応しています。Java、Windows、HTML、XMLなどの各種技術に固有のキャラクタ・セットであり、また推奨のキャラクタ・セットです。このような汎用キャラクタ・セットは他にありません。さらに、Unicodeは工業分野で大きな支持を受けており、採用する動きが急速に広まっています。
AL32UTF8はOracleが実装したUnicodeであり、ASCII文字の文字コードを1バイト、欧州系の文字と中東地方の言語を2バイト、東南アジア系の言語を3バイトで表現します。したがって、Unicodeの保存に必要な領域は通常、同じ言語で比較した場合に、従来のキャラクタ・セットの必要領域よりも多くなります。
関連するトピックとして、既存のデータベース用の新規キャラクタ・セットの選択があります。既存のデータベース用のデータベース・キャラクタ・セットを変更することを、キャラクタ・セットの移行と呼びます。この場合でも、汎用性と互換性を維持するためにUnicodeに移行することをお薦めします。データベース・キャラクタ・セット間の移行を行う際に、次の要因によるデータの損失を最小限に抑えるようにする必要もあります。
データベースがバイト・セマンティクスを使用して作成されている場合、CHARおよびVARCHAR2データ型のサイズは、文字単位ではなくバイト単位で指定されます。たとえば、表定義でCHAR(20)と指定すると、文字データを格納するために20バイトが割り当てられます。データベース・キャラクタ・セットでシングルバイト文字コード体系が使用されている場合は、文字数がバイト数と同じであるため、文字の格納時にデータ消失は発生しません。データベース・キャラクタ・セットでマルチバイト・キャラクタ・セットが使用されている場合は、1文字が1バイト以上で構成される場合があるため、バイト数は文字数とは異なります。
新規キャラクタ・セットへの移行時には、既存のCHARおよびVARCHAR2列の列幅を検証することが重要です。これは、マルチバイトを格納する必要があるエンコーディングをサポートするために、列幅の拡張が必要となる場合があるためです。変換によってデータが拡張されると、データが切り捨てられる可能性があります。
つぎの表に、変換を通じてシングルバイト文字がマルチバイト文字になる場合のデータ拡張例を示します。
表11-1 シングルバイトとマルチバイトのエンコーディング
| 文字 | WE8MSWIN 1252エンコーディング | AL32UTF8エンコーディング |
|---|---|---|
ä |
E4 |
C3 A4 |
ö |
F6 |
C3 B6 |
© |
A9 |
C2 A9 |
€ |
80 |
E2 82 AC |
前述の表の最初の1列目は選択した文字を示します。2列目はWE8MSWIN1252キャラクタ・セットでの文字の16進表現、3列目はAL32UTF8キャラクタ・セットでの各文字の16進表現を示します。文字と数字のペアは、それぞれ1バイトを表します。たとえば、ä(ウムラウト付きのa)は、WE8MSWIN1252のシングルバイト文字(E4)ですが、AL32UTF8では、2バイト文字(C3 A4)になります。また、ユーロ記号のエンコーディングは1バイト(80)から3バイト(E2 82 AC)に拡張されます。
新しいキャラクタ・セットのデータにデータ型でサポートされるバイト・サイズより大きい記憶域が必要な場合は、スキーマを変更する必要があります。CLOB列の使用が必要になる場合があります。
関連項目:
データベース・データ・ディクショナリ内でのスキーマ・オブジェクト名は、30バイトを超えることはできません。スキーマ・オブジェクト名が新規データベース・キャラクタ・セットで30バイトを超える場合は、そのオブジェクト名を変更する必要があります。たとえば、タイ語の各国語キャラクタ・セットではタイ語1文字に1バイト必要です。一方、AL32UTF8では3バイト必要です。タイ語11文字の名前を持つ表を定義している場合、データベース・キャラクタ・セットをAL32UTF8に変更するときは、この表名を10文字以下に短縮する必要があります。
既存のOracleユーザー名またはパスワードが文字ベースで作成されており、その内容が変換先のキャラクタ・セットでサイズ変更された場合、新規キャラクタ・セットへの移行後は認証がエラーとなるため、ユーザーのログイン時に問題が発生します。この問題が発生するのは、データ・ディクショナリに格納されている暗号化されたユーザー名とパスワードを、新規キャラクタ・セットへの移行時に更新できないためです。たとえば、現行のデータベース・キャラクタ・セットがWE8MSWIN1252で、変換先のデータベース・キャラクタ・セットがAL32UTF8の場合、ユーザー名scött(ウムラウト付きのo)の長さは5バイトから6バイトに変更されます。AL32UTF8では、ユーザー名が異なるため、scöttはログインできなくなります。ユーザー名とパスワードにはASCII文字を使用することをお薦めします。ASCII文字以外の場合は、新規キャラクタ・セットへの移行後に、影響のあるユーザー名とパスワードを再設定する必要があります。
CHARデータに、新規キャラクタ・セットへの移行後に拡張される文字が含まれている場合、デフォルトでは、データベースのエクスポート時に空白埋込みは削除されません。つまり、これらの行は、新規キャラクタ・セットでデータベースにインポートされるときに拒否されます。これを回避するには、CHARデータをインポートする前にBLANK_TRIMMING初期化パラメータをTRUEに設定します。
関連項目:
BLANK_TRIMMING初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
この項の内容は、次のとおりです。
エクスポート・ユーティリティとインポート・ユーティリティでは、オリジナルのデータベース・キャラクタ・セットから新規のデータベース・キャラクタ・セットにキャラクタ・セットを変換できます。ただし、キャラクタ・セット変換によって、データが消失したり、破損する可能性があります。たとえば、キャラクタ・セットAからキャラクタ・セットBに移行する場合に、変換先キャラクタ・セットBはキャラクタ・セットAのスーパーセットであることが必要です。変換先キャラクタ・セットBは、キャラクタ・セットAで定義されているすべての文字を含む場合に、スーパーセットになります。キャラクタ・セットBで使用できない文字は、置換文字に変換されます。この置換文字は、通常、?または¿として指定されるか、使用不可能な文字に関連する1文字として指定されます。たとえば、ä(ウムラウト付きのa)はaで変換できます。置換文字は、変換先キャラクタ・セットで定義されます。
注意:
変換先キャラクタ・セットBは、キャラクタ・セットAのスーパーセットであることが必要という必要条件に対して例外があります。キャラクタ・セットAに含まれるが、キャラクタ・セットBに含まれない文字がデータの中に入っていなければ、データ消失またはデータ破損を防ぐために、変換先キャラクタ・セットがキャラクタ・セットAのスーパーセットである必要はありません。
次の図に、著作権記号とユーロ記号が?に変換され、äがaに変換されるキャラクタ・セット変換の例を示します。
データ消失のリスクを削減するには、類似する文字レパートリを持つキャラクタ・セットを変換先に選択してください。AL32UTF8には既存のキャラクタ・セットのほとんどの文字が含まれているため、Unicodeへの移行は最もよい選択肢である可能性があります。
データ消失の可能性があるキャラクタ・セット移行の使用例として、無効なデータを含むデータベースの移行が考えられます。NLS_LANGパラメータがクライアント上で適切に設定されていないため、通常は、データベースに無効なデータが含まれます。NLS_LANG値には、クライアント・オペレーティング・システム・コード・ページを反映する必要があります。たとえば、英語版Windows環境では、コード・ページはWE8MSWIN1252です。NLS_LANGパラメータを適切に設定すると、データベースはクライアント・オペレーティング・システムからのデータを自動的に変換できます。NLS_LANGパラメータが適切に設定されていないと、データベースに入ってくるデータは適切に変換されません。たとえば、データベース・キャラクタ・セットがAL32UTF8で、クライアントが英語版Windowsオペレーティング・システムで、クライアント上でのNLS_LANG設定がAL32UTF8であるとします。データベースに入ってくるデータはWE8MSWIN1252でエンコードされており、クライアント上のNLS_LANG設定がデータベース・キャラクタ・セットと一致するため、AL32UTF8データには変換されません。そのため、Oracleでは変換は不要であるとみなされ、データベースに無効なデータが入力されます。
この結果、データの非一貫性の問題が2つ発生する可能性があります。一方の問題が発生するのは、データベースに含まれているデータのキャラクタ・セットがデータベース・キャラクタ・セットとは異なっているが、両方のキャラクタ・セットに同じコード・ポイントが存在する場合です。たとえば、データベース・キャラクタ・セットがWE8ISO8859P1で、中国語版Windows NTクライアントのNLS_LANG設定がSIMPLIFIED CHINESE_CHINA.WE8ISO8859P1の場合、(ZHS16GBKキャラクタ・セットの)すべてのマルチバイトの中国語データは、シングルバイトWE8ISO8859P1データの倍数として格納されます。これは、Oracleではこれらの文字がシングルバイトWE8ISO8859P1文字として処理されることを意味します。そのため、SUBSTRやLENGTHなどのSQL文字列操作関数はすべて、文字ではなくバイトを基準にして処理されます。ZHS16GBKデータを構成するすべてのバイトは、有効なWE8ISO8859P1コードです。このようなデータベースをAL32UTF8などの別のキャラクタ・セットに移行する場合、文字コードは、WE8ISO8859P1内の文字コードと同様に変換されます。このように、ZHS16GBK文字の2バイトはそれぞれ個別に変換され、AL32UTF8では意味のない値になります。次の図に、この不適切なキャラクタ・セット置換の例を示します。
2つ目の問題は、混在するキャラクタ・セットのデータがデータベースにある場合です。たとえば、データ・キャラクタ・セットがWE8MSWIN1252で、ドイツ語とギリシャ語を使用している2つの別々のWindowsクライアントがともに、NLS_LANGキャラクタ・セットとしてWE8MSWIN1252を使用している場合、データベースにはドイツ語とギリシャ語の文字が混在することになります。次の図に、異なるクライアントが、同一データベースの異なるキャラクタ・セットを使用する方法を示します。
データベース・キャラクタ・セットの移行を適切に行うには、この2つの状況の場合、手作業による調整が必要です。これは、Oracle Databaseでは格納されているデータのキャラクタ・セットを判断できないためです。不適切なデータ変換はデータを破損する恐れがあるため、新規キャラクタ・セットにデータを移行する前に、データベース全体のバックアップを作成します。Database Migration Assistant for Unicode(DMU)ソフトウェアを使用して、キャラクタ・セットのUnicodeへの移行中に、無効なキャラクタ・データを処理する方法の詳細は、「既存のデータベースのデータベース・キャラクタ・セットの変更」を参照してください。
データベース・キャラクタ・セットの移行は、通常、データ・スキャニング、データ・クレンジング、およびデータ変換の3段階からなる複雑なプロセスになります。
データベース・キャラクタ・セットを変更する前に、考えられるデータベース・キャラクタ・セット変換の問題とデータの切捨てを識別する必要があります。このステップはデータ・スキャニングと呼ばれます。データ・スキャニングによって、データベース・キャラクタ・セットの変更前に、データを新しい文字コード体系に移行するために必要な作業量が識別されます。データ・スキャニング時に検出される例には、列幅の拡張が必要なスキーマ・オブジェクトの数や、変換先の文字レパートリに存在しないデータの分布などがあります。この情報は、データベース・キャラクタ・セットの最適な変換方法の決定に役立ちます。
データの潜在的な問題を特定したら、データ変換時にデータの整合性を保持するために、データをクレンジングする必要があります。検出されたデータの問題の大きさや複雑さによっては、データ・クレンジングの作業にかかる時間と手間が大きくなる可能性があります。データ例外をすべて適切に対処するために、データ・スキャニングとデータ・クレンジングを何回も繰り返す場合があります。
データ変換は、文字データを変換元のキャラクタ・セットから変換先のキャラクタ・セット表現に変換するプロセスです。不適切なデータ変換はデータを破損する恐れがあるため、新規キャラクタ・セットにデータを移行する前に、データベース全体のバックアップを作成します。
Database Migration Assistant for Unicode(DMU)は、直感的な操作が可能な、ユーザーに親しみやすいGUIを装備しており、そのインタフェースを介して手作業による手間を大幅に減らし、移行作業を正確かつ効率よく実行して、Unicodeに効率よく移行できるようになっています。
次にいくつかのDMUの利点を示します。
ワークフローに沿って作業できるようになっている
DMUの大きな利点は、処理の論理的な流れに沿って、キャラクタ・セットの移行プロセス全体をユーザーに案内することです。
それぞれの問題に応じた対処方法を提案する
データ・スキャニングやデータ・クレンジングの実行中にエラーや障害などの問題が発生した場合に、DMUはユーザーを支援します。
データ変換の選択肢を提示する
DMUは、変換が必要なデータのみに絞って、表レベル、列レベル、および行レベルでデータを変換できます。
プロセスの状況を監視する
DMUは、処理の進行状況をわかりやすく表示するGUIを備えています。
対話型の表示機能を備えている
DMUにより、対話型のGUIを介してデータの分析と結果の確認を行うことができます。また、データ自体を確認したり、特定した移行上の問題を対話形式で解決したりすることもできます。
インライン変換のみをツールでサポート
DMUを使用した場合、Oracle Databaseはデータベースの内容のインライン変換をサポートします。今までの他の変換方式よりもパフォーマンス面でもセキュリティ面でも優れています。
クレンジングの処理を変換ステップの後の方に回すことができる
データ型の移行などのクレンジングの処理を後に回せば、実際に移行を行う停止期間に入るまでは、本番用のデータベースとアプリケーションは移行の影響を受けずに済みます。
このリリースのDatabase Migration Assistant for Unicodeには、変換できるデータベースについて、いくつかの制約があります。特に、データ・ディクショナリ内に特定のタイプの変換可能データがあるデータベースを変換しません。エクスポート/インポート移行方式を使用すれば、このような制限事項を解消できます。
現在のデータベース・リリースでは、DMUは$ORACLE_HOME/dmuディレクトリにインストールされます。
関連項目:
『Oracle Database Migration Assistant for Unicodeガイド』
全体エクスポートと全体インポートは、データベースを新しいキャラクタ・セットに変換する際にも使用できます。別々のターゲット・インスタンスを設定する必要があるため、時間も長くかかり、リソースも大量に必要になる場合があります。データをUnicode以外のキャラクタ・セットに移行する場合は、あまりお薦めできませんが、DMUを使用して、データベース内に無効な文字表現がないかどうかを調べてから、データ変換にエクスポートとインポートを使用することは可能です。Unicodeに移行しない場合は、データのサイズ超過の問題(列およびデータ型の制限に対する違反)をDMUが正確には検出しないことに注意してください。また、ソースのデータベース・キャラクタ・セットにはあっても、ターゲットのUnicode以外のキャラクタ・セットにはない文字を識別しません。
関連項目:
エクスポート・ユーティリティとインポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください
データベースが、一般的にパススルー構成と呼ばれる構成になっていて、クライアントのキャラクタ・セットがデータベース・キャラクタ・セットと同じになるように定義されている(通常はNLS_LANGクライアント設定になっている)場合は、データベースの文字データが、宣言されているデータベース・キャラクタ・セットとは異なるキャラクタ・セットで格納されている可能性があります。このような場合には、データベース・キャラクタ・セットの特性がデータの実際のキャラクタ・セットを示すと仮定し、DMUを使用して、データベースをUnicodeに移行することをお薦めします。業務上の制約または技術的な制約により、すぐにはUnicodeに移行できない場合は、最低限、データベース・キャラクタ・セットの宣言をデータベースの内容に合せる必要があります。
そのような場合、Database Migration Assistant for Unicodeリリース1.2では、CSREPAIRスクリプトを使用してデータベース・キャラクタ・セット・メタデータを修復できます。CSREPAIRスクリプトは、DMUクライアントと連携して動作し、DMUのリポジトリにアクセスします。これを使用して、データベース・キャラクタ・セットの宣言をデータの実際のキャラクタ・セットに変更できますが、それができるのは、前提とするデータベース・キャラクタ・セット・プロパティをターゲットのキャラクタ・セットに設定した状態でDMUによるデータベースの全体スキャンが完了し、さらに、表現の問題が報告されず、データベース内に存在するデータがすべて、前提とするデータベース・キャラクタ・セットに従って定義されていることが検証される場合にかぎられます。CSREPAIRは、データ・ディクショナリのメタデータ内にあるデータベース・キャラクタ・セットの宣言のみを変更し、データベースのデータを変換しないことに注意してください。
CSREPAIRスクリプトは、インストールされたDMUのadminサブディレクトリにあります。CSREPAIRスクリプトを使用するときの要件は次のとおりです。
CSREPAIRスクリプトの処理が中断されます。ただし、スキャンで、変更不要データまたは変換可能なデータが検出された場合は処理が継続されます。CLOB型のデータは変換の対象にならないため、シングルバイト・キャラクタ・セット間の修復またはマルチバイト・キャラクタ・セット間の修復のみが可能です。CSREPAIRは実行されません。CSREPAIRを実行するためのSYSDBA権限が必要です。Language and Character Set File Scanner(LCSSCAN)は、統計に基づく高パフォーマンスのユーティリティであり、不明なファイル・テキストの言語とキャラクタ・セットを判別します。様々な言語とキャラクタ・セットのペアを自動的に識別できます。言語およびキャラクタ・セット検出エンジンでは、各テキストを使用して一連の確率が設定され、各確率は1つの言語およびキャラクタ・セットのペアに対応します。統計的に最も可能性の高いペアにより、主要な言語とキャラクタ・セットが識別されます。
テキストの純粋性は、言語およびキャラクタ・セット検出の正確さに影響します。理想的なケースは、スペルや構文の誤りのない単一言語による文章です。この種のテキストには100文字以上のデータを必要とする場合があり、信頼率の高い結果を戻すことができます。これに対して、ある種の技術文書は、より長いセグメントにしなければ認識されない場合があります。ドキュメントに複数の言語やキャラクタ・セット、住所、電話番号などのテキストまたはプログラミング言語コードが混在していると、適切な結果が得られない可能性があります。たとえば、ドキュメントにフランス語とドイツ語の両方が埋め込まれていると、どちらかの言語が正常に推測される精度は統計的に減少します。プレーン・テキストとHTMLの両方のファイルが受け入れられます。書式が判明している場合は、精度を上げるためにFORMATパラメータを設定する必要があります。
この項の内容は、次のとおりです。
Language and Character Set File Scannerを起動するには、LCSSCANコマンドを使用します。構文は、次のとおりです。
LCSSCAN [RESULTS=number] [FORMAT=file_type] [BEGIN=number] [END=number] FILE=file_name
ここでは、各パラメータについて説明します。
RESULTS
| プロパティ | 説明 |
|---|---|
デフォルト値 |
|
最小値 |
|
最大値 |
|
用途 |
戻される言語とキャラクタ・セットのペアの数。確率順に表示されます。最初の選択肢の比較重量は定量化できません。このパラメータの推奨値は、デフォルト値 |
FORMAT
FORMATパラメータの指定は任意です。
| プロパティ | 説明 |
|---|---|
デフォルト値 |
|
用途 |
スキャン対象となるファイルのタイプを識別します。可能な値は、 |
BEGIN
| プロパティ | 説明 |
|---|---|
デフォルト値 |
|
最小値 |
|
最大値 |
ファイルのバイト数 |
用途 |
入力ファイル内で |
END
| プロパティ | 説明 |
|---|---|
デフォルト値 |
ファイルの終わり |
最小値 |
|
最大値 |
ファイルのバイト数 |
用途 |
入力ファイル内で |
FILE
| プロパティ | 説明 |
|---|---|
デフォルト値 |
なし |
用途 |
スキャン対象となるテキスト・ファイルの名前を指定します。 |
例11-1 LCSSCANコマンドでファイル名のみを指定する例
LCSSCAN FILE=example.txt
この例では、BEGINおよびENDパラメータがどちらも指定されていないため、example.txtファイル全体がスキャンされます。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。
例11-2 書式をHTMLに指定する例
LCSSCAN FILE=example.html FORMAT=html
この例では、BEGINおよびENDパラメータがどちらも指定されていないため、example.htmlファイル全体がスキャンされます。このスキャンでは、スキャンする前にHTMLタグが取り除かれるため、より正確な結果を得られます。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。
例11-3 LCSSCANに対してRESULTSおよびBEGINパラメータを指定する例
LCSSCAN RESULTS=2 BEGIN=50 FILE=example.txt
スキャン処理はファイルの50バイト目から始まり、ファイルの終わりまで続行されます。言語とキャラクタ・セットのペアが2つ戻されます。
例11-4 LCSSCANに対してRESULTSおよびENDパラメータを指定する例
LCSSCAN RESULTS=3 END=100 FILE=example.txt
スキャン処理はファイルの先頭から始まり、ファイルの100バイト目で終了します。言語とキャラクタ・セットのペアが3つ戻されます。
例11-5 LCSSCANに対してBEGINおよびENDパラメータを指定する例
LCSSCAN BEGIN=50 END=100 FILE=example.txt
スキャン処理はファイルの50バイト目から始まり、ファイルの100バイト目で終了します。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。
Language and Character Set File Scannerは、言語ごとに複数のキャラクタ・セットをサポートしています。
言語のバイナリ値が、サブセット/スーパーセット関係を持つ複数のエンコーディングと一致する場合は、サブセットのキャラクタ・セットが戻されます。たとえば、言語がドイツ語ですべての文字が7ビットの場合は、WE8MSWIN1252、WE8ISO8859P15またはWE8ISO8859P1のかわりにUS7ASCIIが戻されます。
キャラクタ・セットがUTF-8であると判別されると、テキスト内で4バイト文字(補助文字)が検出されないかぎり、デフォルトでOracleのキャラクタ・セットUTF8が戻されます。4バイト文字が検出されると、キャラクタ・セットはAL32UTF8としてレポートされます。
関連項目:
サポートされている言語とキャラクタ・セットのリストは、「言語およびキャラクタ・セット検出のサポート」を参照してください
原因: 内部構造へのアクセス中にエラーが発生しました。
原因: $ORACLE_HOME/nls/dataへのアクセス中にエラーが発生しました。
原因: $ORACLE_HOME/nls/dataへのアクセス中にエラーが発生しました。
原因: 開始オフセットと終了オフセットは、1以上の整数である必要があります。
原因: 終了オフセットは開始オフセットよりも大きい値に設定する必要があります。
原因: ファイルが見つからないか、オープンできません。
原因: 開始オフセットは、ファイルのバイト数よりも小さい値に設定する必要があります。
原因: 入力されたテキストが短いため、結果を生成できません。
