データベースのグローバル化
 
このページをシェアする                  
データベースのグローバル化
PSQL のグローバル化機能
この章では、以下の項目について説明します。
概要
概念と定義
文字セットとエンコードの選択
Unicode UTF-8 による多言語データベースのサポート
Unicode UCS-2 による多言語データベースのサポート
従来のエンコードおよび OEM エンコードによる多言語データベースのサポート
データベース コード ページとクライアント エンコード
PSQL ユーティリティにおける Unicode のサポート
照合順序と並べ替えのサポート
ロケールのサポート
概要
ここでいう「グローバル化」とは、コンピューター ソフトウェアをさまざまな言語に適応させるという意味です。今や、データが世界中のユーザーによってアクセスされ、アプリケーションがそのデータをユーザー自身の使用言語で表すことが当たり前となっています。PSQL のグローバル化対応によって、アプリケーションでは同一データベース内に複数の言語でテキストを保存することができるようになりました。これは、どの言語でもアプリケーションでデータを保存、処理および検索することができるということです。
この章では、作成したアプリケーションのグローバル化をサポートできるようにする PSQL 機能について説明します。グローバル化への一般的なアプローチ、およびグローバル化されたアプリケーションをサポートする特定の PSQL 機能について説明します。デフォルトで、PSQL は従来のテキスト エンコードを使用する下位バージョンとの互換性を維持します。この章では従来のエンコードを使用したアプリケーションのグローバル化を容易にする設定について説明します。
概念と定義
このセクションでは、重要な概念の説明と、本章で使用される用語の定義を示します。
文字セット
文字セットとは、指定のハードウェアやソフトウェア システムで認識されるテキストおよびその他の記号の文字集合(リスト)です。英語で使用される文字のみを認識すればよいシステムであれば、文字セットは A~Z と a~z の文字、0~9 の数字、および数個の句読記号という小さいサイズで済みます。ほかの言語もサポートする場合は、文字セットのサイズも大きくなります。たとえば、ヨーロッパ言語ではアクセントや発音区別符号を持つ文字が追加されます。その他の言語には完全に異なる文字が存在します。
従来の文字セット
文字は、コンピューター システム内では数値として表されます(文字を数字に置き換えることを「エンコード」といいます。これについては後で説明があります)。大きな文字セットのすべての文字を表すには、大きい範囲の数値が必要です。かつては限定的で高価だったストレージ リソースを効率よく使用するために、コンピューター システムは一般的に 1 バイト(8 ビット)を使用して文字表現を格納していました。これにより、文字セットのサイズは 256 文字に制限されました。その結果、日本語などの特定の言語、あるいは西ヨーロッパなどの限定的な言語を表すために特化した従来の文字セットを持つようになりました。PSQL では従来の文字セットを数多くサポートします。
Unicode 文字セット
Unicode 標準は、世界中の言語で使用されているすべての文字に対応した文字セットを定義しています(www.unicode.org を参照)。また、Unicode は文字幅、文字表記の方向、語および改行などを指定するための追加情報を定義することで文字セットの概念を拡大させています。これにより、アプリケーションでは Unicode のテキストを適切に表示および操作することができます。アプリケーションおよびデータベースでも、大文字小文字の変換や並べ替えなどの作業にこの追加情報が必要です。
PSQL は Unicode 文字セットを認識し、アプリケーションでどのような言語が要求されても、その文字データを保管および検索できるようにします。
エンコード
エンコードとは、文字セットの各文字と数値を関連付けることです。当初、コンピューター システムやシステムのプログラミング言語は、文字とバイトを区別しませんでした。また、エンコードは単に特定の文字に相当するバイト値でした。1 バイトでエンコードが可能な文字数よりも多くの文字を表示するニーズに応えるために、別のエンコードが定義されました。大きい文字セットのエンコードでは 1 文字に対して複数バイトを使用する可能性があります。
従来のエンコード
従来の文字セットの場合、エンコードはコード ページで定義されます。コード ページは、文字から値へ(または値から文字へ)変換するためのルックアップ テーブルのように考えることができます。テキストを使用するアプリケーションでは必ず同じコード ページを使用することが重要です。あるコード ページを使用したデータベースに格納されている文字が別のエンコードで読み取られると、別の文字として表示されることがあります。
従来のコード ページはすべて、バイナリ単位が 8 ビット バイトです。現在使用されているほとんどの(従来の)コード ページは ASCII(American Standard Code for Information Interchange)のスーパーセットで、128 個の制御コードと印刷可能文字で構成される文字セットを定義する 7 ビット コードです。8 番目のビットを使用することで、追加の 128 個のコードが、1 バイト値で合計 256 文字のエンコードに対応できます。
Microsoft Windows には ANSI および OEM という 2 つのコード ページ グループがあります。これら両グループのコード ページは拡張 ASCII コード ページですが、どちらのグループも文字とバイトを区別しません。
ANSI コード ページでは、非 ASCII 値(127 よりも大きい値)が国際的な文字を表します。この文字は通常、1 言語または言語グループ用にカスタマイズされます。一般的に、ANSI コード ページは Windows システム上のグラフィカル ユーザー インターフェイスを使用するバイト文字列アプリケーション向けに使用されます。ANSI コード ページはアクティブ コード ページ(ACP、PSQL ではクライアント コード ページといいます)と呼ばれることもあります。Windows アプリケーションは常に現在アクティブなコード ページを 1 つ持ちます。たとえば、Windows で英語のアクティブ コード ページのデフォルトは 1252 です。
OEM(Original Equipment Manufacturer)コード ページは、その名称が示すように、特定のシステム向けに特定のメーカーが開発したコード ページです。もともと、これらのコード ページは MS-DOS 向けに使用されていたものですが、今でもコンソール アプリケーション用に使用されています。英語によく使用される OEM コード ページは、コード ページ 437 です。代表的な OEM コード ページには ANSI コード ページに似た文字セットがありますが、127 より大きい値用には別の文字順序を使用します。
Unicode エンコード
文字エンコード システムでは、1 つ 1 つの文字がコード ポイントと呼ばれる一意の値に割り当てられており、それをエンコード データに使用することができます。コード ポイントは面単位で構成されます。各面には、65,536(216)字分のコード ポイントを収録することができます。Unicode では最大 17 面が使用できるように設定されています。1 番目の面である 0 面は BMP(Basic Multilingual Plane:基本多言語面)と定義されており、現在定義されているコード ポイントの大部分がここに含まれています。このドキュメントの作成時点で、0、1、2、15、および 16 面のみにコード ポイントが含まれています。Unicode 標準ではコード ポイントのエンコード方式にいくつかの方法があります。一般的に使用される 2 つの方式は UTF-8 と UCS-2 です。UTF-8 は文字のコード ポイント値をバイト文字列にエンコードします。この場合、1 文字につき 1 バイトから 4 バイト使用します。UCS-2 は 16 ビット値(「ワイド文字」と呼ばれることが多いです)を使用して文字のコード ポイント値をエンコードします。
PSQL は BMP のコード ポイントを認識します。また、Unicode エンコード(バイト文字列には UTF-8、ワイド文字の文字列には UCS-2 )を使用するアプリケーションに対応しています。UTF-8 のバイナリ単位は 8 ビットです。UCS-2 のバイナリ単位は 16 ビット(ワイド文字)です。
エンコードの宣言
[データベース コード ページ]は PSQL のデータベース用プロパティであり、データベースに保存する文字データのエンコードを宣言します。このプロパティの目的は、文字データを正しく解釈できるようにすることです。ただし、この[データベース コード ページ]プロパティは宣言に過ぎません。PSQL は、アプリケーションがデータベースに追加するデータおよびメタデータのエンコードを検証しません。特定のエンコードで文字データが保存および検索されることを保証するのはアプリケーション側で行ってください。データベース コード ページが適用されるのは、従来のコード ページまたは UTF-8 でエンコードされたテキストのみであることに留意してください。ワイド文字のテキストは UCS-2 を使用してエンコードされます。データベース エンジンがワイド文字のテキストとバイト文字列テキスト間で変換を行うには、適切な設定が必要です。データベース コード ページのデフォルト値は、データベース エンジンが実行されているオペレーティング システムのシステム コード ページです。
PSQL の SQL アクセス方法では、アプリケーションとアクセス方法との間でやり取りされるバイト文字列用のクライアント コード ページを推測します。Windows の場合、このアクセス方法はアプリケーションがバイト文字列にアクティブ コード ページ(ACP)を使用していることを前提としています。Linux および OS X の場合、このアクセス方法はアプリケーションがロケールのエンコードを使用していることを前提としています。通常、これは LANG 環境変数で設定されます。
PSQL では、データベース エンジンとクライアント間でエンコードを確実に適合させる方法があります。たとえば、アプリケーションは、PSQL SQL クライアントがデータベース コード ページとクライアント アプリケーション間でデータを自動的に変換するように指定することができます。これは、自動変換と呼びます。ただし、この自動変換によって文字を変換するのは、それらの文字がサーバー マシン上のコード ページとクライアント マシン上のコード ページの両コード ページの文字セットに存在する場合のみであることに注意してください。
以前のバージョンとの互換性を保つために、アクセス方法における自動変換はデフォルトで無効になっています。アプリケーションでのアクセス方法の設定で自動変更を有効にする必要があります。可能であれば、データベース コード ページを設定し、その値を読み取って使用するためのアクセス方法を設定する方法をお勧めします。
照合順序と並べ替え
照合順序(コレーション)は、文字列のソート順を決定する処理および機能として用いられる一般的な用語です。照合順序は言語によって異なるので、単純なバイナリ文字列比較で各言語の必要な照合順序を示すように、多言語のコード ページにエンコードを配置することはできません。複数レベルの並べ替えが必要な場合、個々のデータ テーブルを正しいソート順で定義する必要があります。
文字セットとエンコードの選択
一般的に、グローバル化戦略を実行するには、言語またはニーズを満たすその他のテキストや文字に基づいて要求される文字セットを特定することから始めます。次に、その文字セットをサポートするエンコードを選択します。使用されるエンコードはデータベースとクライアント アプリケーションでさえ異なるかもしれません。いくつかの例を見てみましょう。
最もグローバルな文字セットは Unicode 文字セットです。従来の文字セットがクライアントで使用されていたとしても、PSQL で保存する際にそれらをすべて Unicode へ変換することができます。新規アプリケーションまたは新規モジュールの場合は、テキストを UCS-2 または UTF-8 で格納するのが簡単な方法です。しかし、すべてのアプリケーションが新規というわけではありません。
アプリケーションに対してもう 1 つ考慮しなければならないことは、クライアント プログラムのテクノロジです。アプリケーションが C/C++ で .NET Framework、Java VM、または UNICODE オプション使用する場合、そのアプリケーションは既にワイド文字の文字列を使用したテキストを処理しています。このような状況で、主に考慮する点は、PSQL の設定でそのテキストを保存するようにすることと、その保存方法の選択です。
アプリケーションが C/C++ でバイト文字列を使用している、また、従来の PSQL ODBC ドライバーを使用している場合、グローバル化には 2 つの経路が考えられます。1 つはアプリケーションを移植してワイド文字の文字列を使用できるようにすること。もう 1 つはインストールされたクライアントの従来のコード ページを引き続きアプリケーションがサポートするようにし、Unicode 保存用に変換できるようにすることです。
既存のアプリケーションへの対応として非常に保守的な方法は、現在のコード ページを引き続き使用し、サポートする他の言語を利用することです。たとえば、ANSI コード ページ 1252 または OEM コード ページ 850 を使用する Windows の英語圏市場向けに開発されたアプリケーションは、アプリケーション ストレージを変更しなくても西ヨーロッパ言語サポートします。主な変更はプログラムのテキストをローカライズすることです。
メモ: ユーザー データとメタデータ
PSQL には扱わなければならない 2 種類のテキストがあります。1 つはユーザー データです。このデータを扱うのは主にアプリケーションですが、インデックス順序付けや SQL 文字列関数でも使用します。もう 1 つはメタデータです。このデータはテーブル、列およびインデックスといった SQL オブジェクトの名前です。メタデータは UCS-2 エンコードを処理しないので、データベース コード ページの宣言による従来のコード ページに従います。SQL クエリには、文字列リテラルのユーザー データとオブジェクト名のメタデータの両方が含まれることがあります。したがって、SQL クエリを検討する場合、全体としては SQL テキスト用に Unicode エンコードの 1 つを使用している場合であっても、ユーザー データとメタデータの文字セットを区別する必要があります
PSQL は、テキスト ストレージにおけるエンコードの混在に対処できません。アプリケーションではそのようなテキストをバイナリ ストレージと見なし、すべてのエンコード変換をアプリケーションで処理する必要があります。PSQL では、すべての CHAR 型データと SQL メタデータがデータベース コード ページを使用すること、また、すべての NCHAR 型データが UCS-2 であることを前提としています。
以下のトピックでは、特定のストレージ状況について説明しています。
Unicode UTF-8 による多言語データベースのサポート
Unicode UCS-2 による多言語データベースのサポート
また以下のトピックでは、従来の OEM コード ページの取り扱いについて説明しています。
従来のエンコードおよび OEM エンコードによる多言語データベースのサポート
Unicode UTF-8 による多言語データベースのサポート
テキストを UTF-8 として格納するようにした場合は、リレーショナル型の CHAR、VARCHAR、および LONGVARCHAR を使用し続けることになるでしょう。また、アプリケーションを実行するオペレーティング システム、アプリケーションで利用可能な文字列操作ライブラリ、アプリケーションで利用する PSQL アクセス方法、異なるデータ型を必要とする可能性がある列などの面でも Unicode サポートを考慮する必要があります。
Unicode UTF-8 を使用する場合
Unicode UTF-8 エンコードは以下のような状況に適しています。
既存のアプリケーションでサポートする言語を新たに追加したいが、アプリケーションへの変更は最小限に留めたい場合。たとえば、ANSI 文字のみ(英語など)を用いた PSQL データベースがあり、アプリケーションを拡張して、英語、ドイツ語、ポーランド語、およびチェコ語でデータを含めることができるようにしたいとします。UTF-8 は、ヨーロッパのスクリプトの場合には、1 文字に対して必要なバイト数が多くても 2 バイトであるため、コンパクトな記憶域を提供します。
Web アプリケーション。これは多くの Web プラットフォームで UTF-8 が使用されているからです。Unicode UTF-8 は ASCII と互換性があり、ラテン語由来の言語の文字セットにはコンパクトなので、多くの場合、Unicode テキストの交換用の標準エンコードとして使用されます。
Linux または OS X アプリケーション。これは UTF-8 文字列処理をサポートします。
OS X 上の PSQL サーバー。
PSQL における Unicode UTF-8 サポート
PSQL でサポートされるコード ページの 1 つは UTF-8 です。UTF-8 のテキスト ストレージのために、お客様の PSQL データベース用のデータベース コード ページには UTF-8 を設定します。
UTF-8 の場合、文字列ストレージはバイト文字列であることに留意してください。バイト文字列の場合、PSQL はリレーショナルデータ型の CHAR、VARCHAR、LONGVARCHAR、そして Btrieve データ型の STRING と ZSTRING を提供します。『SQL Engine Reference』のデータ型も参照してください。ヨーロッパ言語は 1 文字に対して、従来のコード ページの単一バイトではなく 2 バイトを必要とすることが多いので、UTF-8 を保存するときは列が拡大されることもあります。
既存の CHAR、VARCHAR および LONGVARCHAR データ型用のアプリケーションで挿入された文字列データはすべて UTF-8 文字列として解釈されます。PSQL SQL アクセス方法を設定して、自動的に UTF-8 へ変換させることができます(Unicode UTF-8 対応のアクセス方法を参照)。
データベース コード ページが UTF-8 で、クライアント環境が Unicode(ワイド文字または UTF-8)をサポートする場合、SQL テキストは CHAR リテラルの Unicode 文字をサポートします。その他のコード ページでは、一般的な Unicode 文字は NCHAR リテラルに含まれる必要があります。
照合順序と並べ替え
PSQL ではデフォルトで、UTF-8 ストレージでの照合順序と並べ替えに対し、コード ポイント順のみをサポートします。
Unicode UTF-8 対応のアクセス方法
PSQL のアクセス方法である ODBC、JDBC および ADO.NET では UTF-8 ストレージへの変換をサポートします。これらのアクセス方法では、UCS-2 ワイド文字列として、または ANSI ODBC ドライバー向けには従来のバイト文字列として、アプリケーションとテキスト値をやり取りします。適切に設定されれば、これらのアクセス方法はアプリケーションのテキスト値を、ストレージ エンジンへの転送のために UTF-8 へ変換します。
アプリケーションが Windows で ANSI ODBC ドライバーを使用する場合は、Windows 版のドライバー マネージャーによって、すべてのデータがバイト文字列向けのクライアント コード ページ(従来のコード ページ)へ変換されます。これにより、従来の文字セットには存在しない文字がある場合、その文字は失われます。また、Unicode ODBC ドライバーを使用するために、アプリケーションを変換する必要があります。
アプリケーションが Linux または OS X で ANSI ODBC ドライバーを使用する場合は、アプリケーションのロケールの設定で文字列エンコードとして UTF-8 を指定します。完全を期すため、接続文字列で pvtranslate=auto を宣言し、また、データベース コード ページが UTF-8 となることを宣言します。
JDBC の場合、アプリケーションが JDBC ドライバーへの接続文字列で pvtranslate=auto を指定する必要があります。『JDBC Driver Guide』の接続文字列の概要を参照してください。
ADO.NET の場合、アプリケーションがデータベース エンジンへの接続文字列で pvtranslate=auto を指定する必要があります。『Data Provider for .NET Guide』の接続の追加を参照してください。
既存のデータベースを Unicode UTF-8 へ移行する
すべてのテキスト データを従来のコード ページから UTF-8 へ変換する必要があります。より長い UTF-8 バイト文字列を収容するために、列は拡張する必要があるでしょう。 テーブル名などの非 ASCII メタデータは、従来のコード ページから UTF-8 へ変換する必要があります。このような複合的な変更から、従来のコード ページを使用する古いスキーマから、データベース コード ページとして UTF-8 を使用する新しいスキーマへコピーすることによって、データベースを移行するのが妥当です。
メモ: 既存データおよびメタデータがすべて純粋な ASCII という特殊なケースでは、データベース コード ページを UTF-8 へ変更するだけで済みます。
既存の(7 ビット)ASCII バイト文字列はすべて UTF-8 バイト文字列でもあります。
Unicode UCS-2 による多言語データベースのサポート
テキストを UCS-2 として保存するようにした場合は、リレーショナル型の NCHAR、NVARCHAR、および NLONGVARCHAR を使用することになるでしょう。これには、ほかのテキストをリレーショナル型の CHAR ファミリでも格納する能力に影響はありません。また、アプリケーションを実行するオペレーティング システム、アプリケーションで利用可能な文字列操作ライブラリ、アプリケーションで利用する PSQL アクセス方法、異なるデータ型を必要とする可能性がある列などの面でも Unicode サポートを考慮する必要があります。
Unicode UCS-2 を使用する場合
Unicode UCS-2 は以下のような状況に適しています。
アプリケーションでアジアの文字データをサポートする場合。UCS-2 では、すべての文字が 2 バイトとして格納され、アジアの文字データ用の UTF-8 よりもコンパクトなストレージを提供します。
アプリケーションですべてのストレージをグローバル化しないので、アプリケーションに従来のバイト文字の列とワイド文字の列が一緒に含まれる場合。
アプリケーションで、ワイド文字データと、Java、ADO.NET、またはワイド文字クライアントとの互換性を向上させる必要がある場合。そのようなアプリケーションでは、アプリケーション文字列に UCS-2 を使用します。
PSQL における Unicode UCS-2 サポート
ワイド文字列ストレージは、バイト文字列ストレージとは別の種類で、バイト文字列ストレージと一緒に使用される可能性があります。
ワイド文字の文字列の場合、PSQL ではリレーショナル データ型の NCHAR、NVARCHAR、および NLONGVARCHAR、そして Btrieve データ型の WSTRING と WZSTRING を提供します。NCHAR、NVARCHAR、NLONGVARCHAR、WSTRING および WZSTRING データ型対応のアプリケーションによって挿入されたデータはすべてワイド文字の文字列として解釈されます。
PSQL は SQL クエリ テキストの NCHAR リテラルで Unicode 文字をサポートします。CHAR リテラルのテキスト データはデータベース コード ページへ変換されます。UTF-8 以外のデータベース コード ページは、ほとんどの Unicode 文字を処理できないことを覚えておいてください。
Unicode UCS-2 での照合順序と並べ替え
PSQL ではデフォルトで、UCS-2 ストレージでの照合順序と並べ替えに対し、コード ポイント順のみをサポートします。
Unicode UCS-2 対応のアクセス方法
SQL アクセス方法で NCHAR ストレージを使用する場合、アプリケーションでそのアクセス方法に対する適切な NCHAR SQL 型を指定することが必要です。CHAR 型の使用で、データベース コード ページが UTF-8 でない場合は、NCHAR から CHAR への変換が起こり、データが失われる可能性もあります。
ODBC アプリケーションでは、パラメーターに SQL_WCHAR、SQL_WVARCHAR および SQL_WLONGVARCHAR SQL 型を使用する必要があります。
Windows ODBC アプリケーションでは、ODBC に SQL_C_WCHAR として特定されるワイド文字列を使用する必要があります。また、Windows ODBC アプリケーションは PSQL の Unicode ODBC ドライバーを使用する必要があります。従来の ANSI ODBC ドライバーを使用すると、Windows のドライバー マネージャーがすべてのワイド文字列をバイト文字列に変換するので、データが失われます。
Linux および OS X の ODBC アプリケーションでは、UTF-8 エンコード設定のロケールを使用し、アプリケーションのバイト文字列(SQL_C_CHAR)で UTF-8 を使用して、NCHAR 値(SQL_WCHAR)用のデータを提供する必要があります。
JDBC アプリケーションでは、文字列パラメーターに NVARCHAR 型を設定するか、setNString() などの "N" メソッドを使用して文字列データを NCHAR SQL 型として送る必要があります。また、接続文字列で pvtranslate=auto を設定し、デーベース コード ページも設定します。そのように設定しない場合は、JDBC は下位バージョンとの互換性を保ち、文字列データには宣言された、またはデフォルトのバイト文字列エンコードを使用します。『JDBC Driver Guide』の接続文字列の概要を参照してください。
ADO.NET アプリケーションでは、データベース エンジンへの接続文字列で pvtranslate=auto を指定する必要があります。『Data Provider for .NET Guide』の接続の追加を参照してください。
すべての場合において、SQL テキストでは NCHAR リテラルを使用します。
既存のデータベースを Unicode UCS-2 へ移行する
既存のデータベースを UCS-2 アプリケーション対応に移行するための作業には、バイト文字列からワイド文字列への変換が伴います。変換の程度は、対象のアプリケーションに応じて異なります。データベース コード ページが既存の CHAR 列のエンコードと一致するように設定されていれば、ALTER TABLE を使用して列を変換することができます。グローバル化されるデータを格納する列のみを変換する必要があります。データベース コード ページの文字セット外の文字を格納しない列は CHAR 型のままでかまいません。
アプリケーションが Windows で ANSI ODBC ドライバーを使用する場合は、アプリケーションをワイド文字データへ変換し、PSQL Unicode ODBC ドライバーを使用する必要があります。
従来のエンコードおよび OEM エンコードによる多言語データベースのサポート
テキストを従来のコード ページまたは OEM コード ページを使用して格納するようにした場合は、リレーショナル型の CHAR、VARCHAR、および LONGVARCHAR を使用することになるでしょう。従来のコード ページへの変換を行うためにアクセス方法を設定する場合は、ワイド文字アプリケーションを使用することができます。
従来のコード ページを使用する状況
従来のコード ページで、自分のアプリケーションのニーズを満たす文字セットを定義するのであれば、この従来のコード ページを使用することは、テキスト データの格納にはコンパクトで効率的な方法です。
PSQL における従来のコード ページのサポート
PSQL データベース エンジンは、CHAR データがデータベース コード ページでエンコードされていると見なしています。アクセス方法には、そうなっていることを保証するための設定オプションがあります。
ストレージに OEM コード ページを使用する古いアプリケーションは、データベース コード ページを宣言しませんでした。アプリケーションが適切なリレーショナル文字列関数を慎重に使用している限りは、この状況で作業し続けることができます。
従来のコード ページでの照合順序と並べ替え
PSQL でのデフォルトの照合順序は、エンコードされたバイトのバイナリ順です。このデフォルトの照合順序は、宣言されたデータベース コード ページによる影響を受けません。
PSQL は、照合順序の制御にオルタネート コレーティング シーケンス(ACS)とインターナショナル ソート規則(ISR)メカニズムの双方を提供します。これらは、Btrieve インデックスおよびリレーショナル列で宣言することができます。リレーショナル列で CASE 宣言を使用する、または Btrieve インデックスで case-insensitive ビットを使用する場合、PSQL では常に ASCII 文字セット用に特定の ACS を使用します。
従来のコード ページ向けのアクセス方法
PSQL のすべてのアクセス方法で、バイト文字列テキストをサポートします。アクセス方法の中には、データベース コード ページがアプリケーションのコード ページと同じであることを前提としているものもあれば、コード ページを設定できるものもあります。
ANSI ODBC ドライバーでは DSN 設定の 1 つに OEM/ANSI 変換を提供します。これにより、アプリケーションの OEM コード ページ(ANSI コード ページではなく)がデータベース コード ページであることを宣言します。ANSI ODBC ドライバーは、接続文字列の encoding プロパティと pvtranslate=auto オプションもサポートします。
Unicode ODBC ドライバーは常に pvtranslate_true プロパティが設定されているかのように動作し、アプリケーションの CHAR データを必要に応じてデータベース コード ページに変換します。
JDBC ドライバーには接続文字列に明示的な encoding プロパティがあります。pvtranslage=auto プロパティが指定された場合、このドライバーはエンコードをデータベースのコード ページに設定します。
ADO.NET プロバイダーには明示的な encoding 接続プロパティがあります。pvtranslage=auto 接続プロパティが指定された場合、このドライバーはエンコードをデータベースのコード ページに設定します。
Delphi 向けの PDAC アクセス方法には、OEM コード ページまたは ANSI(ACP)コード ページを使用して、エンジンへ CHAR データを送るかどうかを制御する OEMConversion プロパティがあります。
既存のデータベースを別のコード ページへ移行する
データベースのコード ページを変更すると、そのデータを、変更後の新しいコード ページを使用する新規データベースへコピーする必要があります。このコピーはアプリケーションで行う必要があります。PSQL はトランザクション内でコード ページを変換しません。
データベースのメタデータで、変換を必要とする文字を使用している場合、その変更は新しいデータベースのスキーマの作成時に行う必要があります。この種類のメタデータの一般的な例として、テーブル名があります。
データベース コード ページとクライアント エンコード
先の概念と定義で説明したように、エンコードは PSQL データベース エンジンと PSQL クライアント アプリケーション間で文字データをどのように変換するかを指定します。PSQL では、クライアントとサーバー間のエンコードの複雑性、およびオペレーティング システム、言語、アクセス方法のさまざまな組み合わせに対処します。エンコードの機能拡張は、データベース コード ページとクライアント エンコードに分割されています。この 2 種類のエンコードは、別個のものですが相互に関係しています。
データベース コード ページおよびクライアント エンコードは、リレーショナル エンジンのみに適用されます。MicroKernel エンジンには影響がありません。
データベース コード ページ
[データベース コード ページ]はデータベース用プロパティであり、データベースに保存する文字データのエンコードを指定します。デフォルトのデータベース コード ページは "サーバーのデフォルト" で、データベース エンジン実行中のサーバーのオペレーティング システム コード ページを意味します。(オペレーティング システムのコード ページは一般的に「OS エンコード」と呼ばれます。この章のこれ以降の説明ではこの表現を使用します)。
データベース コード ページは、特に、異なる OS エンコードを使用して PSQL DDF を手動で別のプラットフォームへコピーしながら、データベース エンジンにメタデータを正しく変換させたい場合に役立ちます。
PSQL でデータベースを作成する場合、デフォルトでは、データベース エンジンを実行しているマシン用のアクティブ コード ページを使用するようになっています。たとえば、Windows の英語版を実行しているマシンの場合、コード ページには 1252 が割り当てられます。PSQL のエンコード変換は "None"(なし)に設定されます。作成したアプリケーションでは PSQL データベースと同じコード ページを使用するか、エンコード変換を "Automatic"(自動)に設定しておく必要があります。
サポートされるコード ページ
PSQL では以下のコード ページをサポートします。ここで挙げるページはすべてバイト文字列ストレージを使用します。
ASCII
EUCJP
ISO8859_1
UTF-8
Windows のコード ページ
CP437, CP737, CP775, CP850, CP852, CP855, CP857, CP858, CP862, CP866, CP932
CP1250, CP1251, CP1252, CP1253, CP1254, CP1255, CP1256, CP1257, CP1258
クライアントのエンコード
クライアントのエンコードは、PSQL クライアント上のアプリケーションが使用するデータ エンコードです。アプリケーションは、任意に選択したエンコードでテキストを管理することができます。データベース エンジンとクライアント アプリケーション間で互換性のあるエンコードを確立する必要があります。
データベース エンジンとクライアントで異なるエンコードを使用している場合でも、文字がサーバー マシンのコード ページとクライアント マシンのコード ページの両方に存在していれば、PSQL がその異なるエンコード間で自動変換することができます。
データの変換は、要求に応じてクライアントで行われます。変換はいつも必要なわけではありません。たとえば、クライアントとサーバーの OS エンコードが一致している場合は不要です。
PCC におけるエンコードのサポート
データベースの作成時にデーターベースのコード ページを設定する、または既存のデータベースのコード ページ設定を編集するために、PCC を使用することができます。
メモ: データベース コード ページのプロパティを変更しても、データベースのデータが変更されることはありません。ただし、既存のデータベースのデータベース コード ページを変更すると、既存のデータ項目の解釈方法に影響があります。
PSQL Control Center(PCC)それ自体はデータベース エンジンのクライアント アプリケーションです。クライアントとして、PCC では、各データベース セッションで PCC がメタデータおよびデータを読み取りまたは追加する際に使用するエンコードを指定することができます。既存データベースのデフォルトでは、PCC が実行されているマシンのエンコードを使用します。これは、PCC の旧来の動作です。新しいデータベースのデフォルトでは、自動変換を使用します。『PSQL User's Guide』のPCC 接続エンコードを参照してください。
次の表では、PCC 接続エンコードとデータベース コード ページの設定の相互の影響を説明します。PCC 接続エンコードは PCC にのみ適用されます。ほかのクライアント アプリケーションには影響しません。
PCC 接続エンコードが特定のエンコードに設定されている
PCC 接続エンコードが "自動変換" に設定されている
PCC はデータベース コード ページを無視し、指定されたエンコードを使用して CHAR 型のデータ、文字列、リテラル、およびメタデータを読み書きします。NCHAR 型のデータの場合は、この設定による影響はありません。
これは、PCC の旧来の動作です。
PCC およびデータベースは、CHAR データとメタデータのエンコードを自動的に確立します。クエリ内の文字列リテラルは Unicode としてエンジンに送られます。NCHAR 型のデータの場合は、この設定による影響はありません。
Btrieve API におけるエンコードのサポート
Btrieve API を使用する場合は、アプリケーションで使用されるローカル エンコードでファイル名とパスを提供する必要があります。Btrieve API は、サーバーおよびクライアント上の OS エンコード間の相違に対処します。
DTI におけるエンコードのサポート
DTI(Distributed Tuning Interface)を使用する場合は、アプリケーションで使用されるローカル エンコードでファイル名とパスを提供する必要があります。DTI は、サーバーおよびクライアント上の OS エンコード間の相違に対処します。
DTI API を使用してデータベースを作成する場合、作成時にデータベース コード ページのプロパティを指定できます。このプロパティは、文字データの自動変換を設定するために SQL アクセス方法で使用できます。
ADO.NET におけるエンコードのサポート
.NET Framework および .NET アプリケーションでは UTF-16 文字列を使用します。これらは、CHAR 列にテキストを格納する場合、コード ページに変換される必要があります。
接続プロパティ PVTranslate=Auto は、接続エンコードをデータベース コード ページに設定します。encoding プロパティを直接設定することもできます。
詳細については、『Data Provider for .NET Guide』の接続の追加PsqlConnectionStringBuilder オブジェクトおよび文字セットの変換を参照してください。
JDBC におけるエンコードのサポート
Java 仮想マシンや Java アプリケーションでは UTF-16 文字列を使用します。これらは、CHAR 列にテキストを格納する場合、コード ページに変換される必要があります。
接続プロパティ PVTranslate=Auto は、接続エンコードをデータベース コード ページに設定します。encoding プロパティを直接設定することもできます。
PvTranslate=Auto プロパティが指定されると、JDBC ドライバーは文字列リテラルを Unicode としてエンジンに送ります。この設定がなければ、従来の動作として文字列リテラルがデータベース コード ページに変換されます。アプリケーションで NCHAR 文字列リテラル(例:"N'ABC'")を使用する場合は、接続プロパティの設定を PvTranslate=Auto にしてください。
JDBC Driver Guide』の接続文字列の要素を参照してください。
ODBC におけるエンコードのサポート
PSQL ODBC ドライバーは、多くのメカニズムをサポートしてクライアント エンコードを制御します。
DSN を設定する場合、エンコード オプションとして "自動"、"OEM/ANSI"、および "なし" から選択することができます。"自動" を設定すると、ドライバーはクライアント エンコードからデータベース コード ページへ変換するようになります。"OEM/ANSI" を設定すると、ドライバーはクライアント エンコードを対応する OEM コード ページへ変換するようになります。"なし" に設定すると、ドライバーがテキストを変換できないようにします。詳細については、『ODBC Guide』のエンコード変換を参照してください。
OEM から ANSI へのデータ変換に使用する従来の変換方法
データベース内に OEM 文字データがある場合、従来の解決法はアクセス方法で OEM/ANSI 変換を指定することでした。ここでは、OEM 文字データを使用する Linux クライアント向けに従来の方法について説明します。
メモ: 従来の方法は引き続きサポートされますが、前に説明したようにデータベースに OEM コード ページを指定し、アクセス方法で自動変換を使用することをお勧めします。
ODBC Guide』のOEM/ANSI 変換も参照してください。
ODBC を使用する場合、エンコードは、Win32 の OS では SHIFT-JIS を使用してください。
日本語版の Linux は一般的にデフォルトでそのエンコードを EUC-JP または UTF-8 に設定します。
日本語版の Linux を使用している場合、クライアントは別の Linux サーバー(たとえばローカルに)、あるいは Win32 の SHIFT-JIS サーバーに接続できます。Linux サーバーに置かれている SHIFT-JIS にエンコードされたデータベースに接続することも可能です。
以下に示す手順を使用して必要な設定を行ってください。これらのケースは、アプリケーション自体は何も変換を行わず、そのマシンのネイティブのエンコードを使用することを前提としています。
Linux EUC-JP クライアントを Win32 SHIFT-JIS サーバーへ接続させる
Linux UTF-8 クライアントを Win32 SHIFT-JIS サーバーへ接続させる
Linux EUC-JP クライアントを Linux EUC-JP サーバーへ接続させる
Linux UTF-8 クライアントを Linux UTF-8 サーバーへ接続させる
Linux UTF-8 クライアントを Linux EUC-JP サーバーへ接続させる
Linux EUC-JP クライアントを Linux EUC-JP サーバーへ接続させる、サーバーにデータを保存する場合は SHIFT-JIS エンコードを使用する
Linux EUC-JP クライアントを Win32 SHIFT-JIS サーバーへ接続させる
このサーバーで受け取るものはすべて SHIFT-JIS でなければいけません。サーバーからクライアントに送られるものはすべて EUC-JP でなければいけません。
これを達成するには、指定のデータベースへの接続に使用する ODBC.INI(デフォルトで /usr/local/psql/etc にあります)内のクライアント DSN 設定が次のようになっている必要があります。
[dbclient]
Driver=/usr/local/psql/lib/libodbcci.so
Description=PSQL ODBC Client Interface: JPN-2000SERVER:1583/dbclient
ServerDSN=DEMODATA
ServerName=JPN-2000SERVER:1583
TranslationDLL=/usr/local/psql/lib/libxlate.so.10
TranslationOption=90000932
TranslationDLL の行では、ODBC クライアント インターフェイスが使用する変換ライブラリを設定します。
TranslationOption の行は、9000(EUC-JP)から 0932(SHIFT-JIS)への変換が必要であることを指定しています。
この例を使用すると、クライアントからのすべてのデータはサーバーに送られる前に SHIFT-JIS に変換され、サーバーがクライアントにデータを送る前には EUC-JP に変換されます。
Linux UTF-8 クライアントを Win32 SHIFT-JIS サーバーへ接続させる
このサーバーで受け取るものはすべて SHIFT-JIS でなければいけません。サーバーからクライアントに送られるものはすべて UTF-8 でなければいけません。
これを達成するには、指定のデータベースへの接続に使用する ODBC.INI(デフォルトで /usr/local/psql/etc にあります)内のクライアント DSN 設定が次のようになっている必要があります。
[dbclient]
Driver=/usr/local/psql/lib/libodbcci.so
Description=PSQL ODBC Client Interface: JPN-2000SERVER:1583/dbclient
ServerDSN=DEMODATA
ServerName=JPN-2000SERVER:1583
TranslationDLL=/usr/local/psql/lib/libxlate.so.10
TranslationOption=90010932
TranslationDLL の行では、ODBC クライアント インターフェイスが使用する変換ライブラリを設定します。
TranslationOption の行は、9001(UTF-8)から 0932(SHIFT-JIS)への変換が必要であることを指定しています。
この例を使用すると、クライアントからのすべてのデータはサーバーに送られる前に SHIFT-JIS に変換され、サーバーがクライアントにデータを送る前には UTF-8 に変換されます。
Linux EUC-JP クライアントを Linux EUC-JP サーバーへ接続させる
この設定を使用する場合は、DSN の定義を変更する必要はありません。dsnadd ユーティリティで作成されたままの DSN を使用します。
Linux UTF-8 クライアントを Linux UTF-8 サーバーへ接続させる
この設定を使用する場合は、DSN の定義を変更する必要はありません。dsnadd ユーティリティで作成されたままの DSN を使用します。『PSQL User's Guide』のdsnaddを参照してください。
Linux UTF-8 クライアントを Linux EUC-JP サーバーへ接続させる
このサーバーで受け取るものはすべて EUC-JP でなければいけません。サーバーからクライアントに送られるものはすべて UTF-8 でなければいけません。
これを達成するには、指定のデータベースへの接続に使用する ODBC.INI(デフォルトで /usr/local/psql/etc にあります)内のクライアント DSN 設定が次のようになっている必要があります。
[dbclient]
Driver=/usr/local/psql/lib/libodbcci.so
Description=PSQL ODBC Client Interface: JPN-2000SERVER:1583/dbclient
ServerDSN=DEMODATA
ServerName=JPN-2000SERVER:1583
TranslationDLL=/usr/local/psql/lib/libxlate.so.10
TranslationOption=90019000
TranslationDLL の行では、ODBC クライアント インターフェイスが使用する変換ライブラリを設定します。
TranslationOption の行は、9001(EUC-JP)から 9000(UTF-8)への変換が必要であることを指定しています。
この例を使用すると、クライアントからのすべてのデータはサーバーに送られる前に EUC-JP に変換され、サーバーがクライアントにデータを送る前には UTF-8 に変換されます。
Linux EUC-JP クライアントを Linux EUC-JP サーバーへ接続させる、サーバーにデータを保存する場合は SHIFT-JIS エンコードを使用する
この状況は Win32 エンジンに SHIFT-JIS データベースがある場合に可能ですが、すべてのファイルを Linux EUC-JP サーバーに移動することができます。この場合、そのデータベースは EUC-JP Linux マシンにありますが、DDF ファイル内のすべてのデータおよびデータ ファイルは SHIFT-JIS です。
この場合、DSN は以下のようになります。
[dbclient]
Driver=/usr/local/psql/lib/libodbcci.so
Description=PSQL ODBC Client Interface: JPN-2000SERVER:1583/dbclient
ServerDSN=DEMODATA
ServerName=JPN-2000SERVER:1583
TranslationDLL=/usr/local/psql/lib/libxlate.so.10
TranslationOption=90000932
CodePageConvert=932
最後の行は、サーバーでは EUC-JP エンコードを使用するが、このサーバー上のデータは SHIFT-JIS として処理することを指定しています。
ワイド文字対応 ODBC ドライバー用のエンコードのサポート
PSQL ではワイド文字データ用のドライバーを使用する ODBC で UCS-2 をサポートし、また DSN エンコード変換用のデフォルトをサポートします。『ODBC Guide』のエンコード変換およびODBC 接続文字列を参照してください。
ワイド文字データを扱うアプリケーション用の ODBC ドライバー
PSQL は、ワイド文字データを使用する 32 ビットおよび 64 ビット アプリケーション向けの ODBC ドライバーを提供します。このドライバーは Windows オペレーティング システムのみが対象で、以前からあるドライバーのセットに追加されます。
表 15 ワイド文字データ用の PSQL ODBC ドライバー
ドライバー名
説明
PSQL ODBC Unicode Interface
ローカルまたはリモートの名前付きデータベースへ接続します。
32 ビット ODBC アドミニストレーターでは、ワイド文字データを扱う 32 ビット アプリケーション向けの 32 ビット DSN を作成します。32 ビット ドライバーは PSQL の全エディションでインストールされます。
64 ビット ODBC アドミニストレーターでは、ワイド文字データを扱う 64 ビット アプリケーション向けの 64 ビット DSN を作成します。64 ビット ドライバーは、64 ビット プラットフォームへ PSQL をインストールする場合、全エディションでインストールされます。
Linux では通常、システム エンコードは UTF-8 です。このエンコードを使用すると SQL テキストに Unicode 文字のコード ポイントを含めることができます。アプリケーションでは、UTF-8 対応の PSQL ODBC Client Interface ドライバーを使用できるので、PSQL ODBC Unicode Interface ドライバーは Linux で使用できません。Linux アプリケーションは、ワイド文字データを UTF-16 文字列(SQL_C_WCHAR)として、または SQL_C_CHAR としてシステム エンコード(通常は UTF-8)へ変換を要求することで処理できます。UTF-8 を使用する SQL テキストは既存の Pervasive ODBC Client Interface ドライバーと互換性があるので、Linux で ODBC ドライバーを追加する必要はありません。
DSN エンコード変換のデフォルト
DSN 用のエンコード変換オプションは、PSQL データベース エンジンと ODBC を使用する PSQL クライアント アプリケーション間で文字データをどのように変換するかを指定します。エンコード変換のデフォルトは、使用する PSQL ODBC ドライバーによって異なります。
表 16 DSN エンコード変換のデフォルト
ドライバー名
エンコード変換のデフォルト
備考
PSQL ODBC Unicode Interface
自動
接続文字列パラメーター Pvtranslate もデフォルトで "auto" にします。
PSQL ODBC Interface
なし
前バージョンの PSQL でのデフォルトと同じ。
PSQL ODBC Client Interface
なし
前バージョンの PSQL でのデフォルトと同じ。
PSQL ODBC Engine Interface
なし
前バージョンの PSQL でのデフォルトと同じ。
ODBC ドライバーは、ドライバーや DSN エンコード変換の設定に応じて、SQL テキストを処理します。
表 17 SQL テキストに影響を与える PSQL ODBC ドライバーと DSN エンコード変換設定
設定
SQL テキストの処理
PSQL ドライバー
ODBC Unicode Interface
ODBC Interface および ODBC Client Interface
ODBC Engine Interface
自動
SQL テキストは UTF-8 に変換され、データベース エンジンへ送られます。クライアント、サーバー、およびデータベースのコード ページは無視されます。
Yes1
No
No
SQL テキストはデータベース コード ページに変換され、データベース エンジンへ送られます。
No
Yes
Yes
なし
SQL テキストはクライアントとデータベース エンジン間で変換されません。2
Yes
Yes
Yes
OEM/ANSI
クライアント コード ページの SQL テキストは OEM/ANSI エンコードに変換され、データベース エンジンへ送られます。
Yes3
Yes3
Yes3
1 エンコード変換の設定を "自動" にすると、ワイド文字データを持つ NCHAR 列および NCHAR リテラルを使用することができます。
2 これはクライアントとデータベース エンジンが同じオペレーティング システムのエンコードを使用していることが前提です。
3 SQL テキストがワイド文字の場合、最初にそれがクライアント エンコードへ変換されます。SQL テキストがワイド文字でない場合、既にそれはクライアント エンコードになっています。その後、SQL テキストは OEM エンコードに変換され、データベース エンジンへ送られます。
PSQL ユーティリティにおける Unicode のサポート
PSQL Control Center(PCC)における Unicode サポート
この章で既に述べた PCC におけるエンコードのサポートセクションも参照してください。
ファイルを開く/ファイルを保存用のダイアログ
PCC で使用する、SQL ドキュメントを開く/保存用、エクスポートされるスキーマの保存、およびテーブル データのインポート/エクスポート用のダイアログでは機能が改善され、さまざまなファイル エンコードに対応できるようになりました。以前のバージョンでは、これらのファイルにはデフォルトのシステム コード ページが用いられるとみなされていました。ファイルの保存時に複数の Unicode エンコードを選択することはできません。本バージョンの新しいダイアログでは、ファイルを開くときに、そのファイルが Unicode エンコードを識別するバイト オーダー マーク(BOM)を使用するかどうかを検出します。また、ファイルを開くダイアログでは、ファイルに対して必要なエンコードを設定することもできます。新しい PCC 設定では、これらのダイアログで使用されるデフォルトのエンコードを管理できるようになっています。
これらの新機能の詳細については、『PSQL User's Guide』の「[ファイルを開く]ダイアログと[ファイルを保存]ダイアログ」、「データのインポート/エクスポート、スキーマのエクスポートでサポートされるワイド文字データ」および「ファイル エンコードの初期設定」セクションを参照してください。
バルク データ ユーティリティ(BDU)
バルク データ ユーティリティ(BDU)はコマンド ライン ユーティリティで、区切り文字付きテキスト ファイルのデータを PSQL テーブルに読み込むことができます。データ ファイルの読み込み時に使用するデータ エンコードを指定するために、「-c エンコード」というコマンド ライン パラメーターが提供されます。エンコード オプションは UTF-8、UTF-16LE、および UTF-16BE です。データ ファイルに BOM(バイト オーダー マーク)が含まれている場合、BDU はその BOM で指定されたエンコードを用います。つまり、コマンド ラインで encoding パラメーターの値を指定したとしても、データ ファイルで BOM を使用して UTF-8、UTF-16LE、または UTF-16BE のエンコードを示していた場合は、BDU はそのエンコードを優先して使用します。BOM または -c パラメーターがない場合、BDU はデフォルトでシステム コード ページを使用します。
PSQL User's Guide』のbduを参照してください。
照合順序と並べ替えのサポート
照合順序と並べ替えとは
照合順序(コレーション)とは、コード ページ内の文字に対応する、一連のバイナリ値の並び順を定めたものです。照合順序は、重要な違いがあることがあります。たとえば、コード ページによっては、数字、文字の順に配置されることもあれば、文字、数字の順で配置されるものもあります。並べ替えは、テキストが照合順になるように、データを再配置することです。
PSQL はバイト文字列のテキスト セグメントに対する名前付き照合順序の仕様をサポートします。インデックスは、指定された照合順序に従ってレコード キーを並べ替えます。
照合順序を指定しない場合のソート順序
照合順序が指定されていない場合、PSQL はデフォルトで、コード ポイント順に文字を並べ替えます。デフォルトは昇順、つまり、最小値から最大値の順です。これを降順に変更することができます。詳細については、『PSQL Programmer's Guide』のソート順序を参照してください。
ワイド文字を含む列における照合順序のサポート
PSQL では、コード ポイント順に従って Unicode データのデフォルトの照合順序をサポートします。UTF-16 に加えて、マルチバイトの UTF-8 テキストをコード ポイント順にソートすることができます。
オルタネート コレーティング シーケンス(ACS)を使用した照合順序のサポート
コード ページのデフォルトの照合順序とは別の照合順序を指定することができます。このユーザー定義のオルタネート コレーティング シーケンス(ACS)は、コード ページの照合順序と指定の照合順序間のマッピングです。STRING、LSTRING および ZSTRING 型の文字列キーの照合順序を決定するために 1 つまたは複数の代替シーケンスを定義できます。たとえば、ユーザー定義の ACS を使用して、数字、文字の順で配置する、または大文字と小文字の順序付けを変更する照合順序を指定することができます。PSQL には、小文字を大文字にマップして、同等にソートされるようにするための upper.alt という ACS が付属しています。同じ結果は、大文字と小文字を区別しないと設定することによっても得られますが、この例は ACS で何ができるかを示しています。
基本的に、ユーザー定義の ACS は、文字のコード ページの順序位置と、代替の順序位置を関連付けるテーブルです。ACS の作成については、『PSQL Programmer's Guide』のオルタネート コレーティング シーケンスで説明しており、例も提供しています。データ ファイルのレイアウトの定義で、キー値フィールドの ACS を指定します。本ガイドのキーのオルタネート コレーティング シーケンスの指定、および『PSQL Programmer's Guide』のデータ レイアウトを参照してください。
ACS の設定についての詳細は、『Btrieve API Guide』の Create(14)Create Index(31) および Get Next Extended(36)、『DDF Builder User’s Guide』のオルタネート コレーティング シーケンス(ACS)ファイルおよび『SQL Engine Reference』の SET DEFAULTCOLLATE を参照してください。
インターナショナル ソート規則(ISR)を使用した照合順序のサポート
ACS のもう 1 つのタイプはインターナショナル ソート規則(ISR)です。ISR は、言語固有のソート順用にあらかじめ定義されたオルタネート コレーティング シーケンスです。ISR を使用すれば、ドイツ語などの ä、ö、ü(ae、oe、ue としてソート)および ß(ss としてソート)の文字を持つ言語を正しくソートできます。PSQL は、インストールに含まれる collate.cfg ファイルで多くの ISR テーブルを提供しています。これらの使用例については、『PSQL Programmer's Guide』のインターナショナル ソート規則を使用した照合順序のサンプルに記載されています。詳細については、前述のオルタネート コレーティング シーケンスの参照情報をご覧ください。
ICU Unicode 照合順序を使用した照合順序のサポート
PSQL は、UTF-8 または UTF-16 のデータをデフォルトのバイナリ照合順序以外で並べ替える必要がある場合に使用するための、2 つの Unicode 照合順序をサポートしています。これら代替の Unicode 照合順序は、ICU(International Components for Unicode)ライブラリのリリース バージョン 54 に基づいています。次の表は、照合順序をまとめたものです。
ICU 照合順序名
インストールされたファイル
説明
u54-msft_enus_0
u54-msft_enus_0.txt
ISR 照合順序の MSFT_ENUS01252_0 をエミュレートします。エミュレーションは、Unicode の 1252 サブセットにのみ適用されます。この範囲外の文字は、ICU root 照合順序に従って並べ替えられます。
root
icudt54l.dat
デフォルトの ICU 照合順序と、その他の構成データを定義します。
ICU 照合順序は ISR テーブル名と同じように使用されますが、PVSW_MSFT_ で始まる名前を持たない点が異なります。名前は、プレフィックス u54- を付けた名前にするか、または単に root とする必要があります。また、これらの照合順序は次の Unicode データ型にのみ適用することができます。
STRING(UTF-8 と見なす)
ZSTRING(UTF-8 と見なす)
WSTRING
WZSTRING
デフォルトの PSQL インストールでは、collate.cfg ファイルと同じ場所に 2 つの ICU 照合順序が提供されます。一般的なソートの場合、デフォルトの ICU 照合順序は root という名前で参照され、その構成データは icudt54l.dat ファイルに存在します。ロケール固有のソートの場合、補足データは、ファイル名が u54 で始まり .txt 拡張子で終わるファイルに存在します。PSQL で現在サポートされる補足 ICU 照合順序は 1 つのみです。
ICU 照合順序の詳細については、ICU プロジェクトの Web サイトを参照してください。
ロケールのサポート
グローバル化の重要な側面の 1 つはロケールです。これはネイティブ言語環境のモデルと定義です。ロケールは、国によって決まる形式、またはその他の規格が存在する多くのカテゴリで構成されています。たとえば、ロケールは日付と時刻の表示形式の規則、通貨規則、数値の書式規則、および照合順序(並べ替え)を定義します。オペレーティング システムによって、ロケールはリージョン(地域)と呼ばれることもあります。
複数のロケールを、特定の言語と関連付けることができます。これにより、地域的な差異にも対応できます。たとえば、英語ではアメリカ英語のロケールとイギリス英語のロケールを持つことができます。
文字列関数を実行する場合、PSQL ではデータベース エンジンを実行しているオペレーティング システムのロケールを使用します。PSQL では、PSQL アクセス方法の 1 つを用いたアプリケーションからの要求でデータ型を変換する際は、クライアントのロケールを使用します。
詳細については、『SQL Engine Reference』のSET DECIMALSEPARATORCOMMA小数点の記号のカンマ、およびSET TIME ZONEを参照してください。