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

ここでいう「グローバル化」とは、コンピューター ソフトウェアをさまざまな言語に適応させるという意味です。今や、データが世界中のユーザーによってアクセスされ、アプリケーションがそのデータをユーザー自身の使用言語で表すことが当たり前となっています。PSQL のグローバル化対応によって、アプリケーションでは同一データベース内に複数の言語でテキストを保存することができるようになりました。これは、どの言語でもアプリケーションでデータを保存、処理および検索することができるということです。

この章では、作成したアプリケーションのグローバル化をサポートできるようにする PSQL 機能について説明します。グローバル化への一般的なアプローチ、およびグローバル化されたアプリケーションをサポートする特定の PSQL 機能について説明します。デフォルトで、PSQL は従来のテキスト エンコードを使用する下位バージョンとの互換性を維持します。この章では従来のエンコードを使用したアプリケーションのグローバル化を容易にする設定について説明します。

このセクションでは、重要な概念の説明と、本章で使用される用語の定義を示します。

文字セットとは、指定のハードウェアやソフトウェア システムで認識されるテキストおよびその他の記号の文字集合（リスト）です。英語で使用される文字のみを認識すればよいシステムであれば、文字セットは A～Z と a～z の文字、0～9 の数字、および数個の句読記号という小さいサイズで済みます。ほかの言語もサポートする場合は、文字セットのサイズも大きくなります。たとえば、ヨーロッパ言語ではアクセントや発音区別符号を持つ文字が追加されます。その他の言語には完全に異なる文字が存在します。

文字は、コンピューター システム内では数値として表されます（文字を数字に置き換えることを「エンコード」といいます。これについては後で説明があります）。大きな文字セットのすべての文字を表すには、大きい範囲の数値が必要です。かつては限定的で高価だったストレージ リソースを効率よく使用するために、コンピューター システムは一般的に 1 バイト（8 ビット）を使用して文字表現を格納していました。これにより、文字セットのサイズは 256 文字に制限されました。その結果、日本語などの特定の言語、あるいは西ヨーロッパなどの限定的な言語を表すために特化した従来の文字セットを持つようになりました。PSQL では従来の文字セットを数多くサポートします。

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 より大きい値用には別の文字順序を使用します。

文字エンコード システムでは、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、および Raspbian の場合、このアクセス方法はアプリケーションがロケールのエンコードを使用していることを前提としています。通常、これは 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 は、テキスト ストレージにおけるエンコードの混在に対処できません。アプリケーションではそのようなテキストをバイナリ ストレージと見なし、すべてのエンコード変換をアプリケーションで処理する必要があります。PSQL では、すべての CHAR 型データと SQL メタデータがデータベース コード ページを使用すること、また、すべての NCHAR 型データが UCS-2 であることを前提としています。

以下のトピックでは、特定のストレージ状況について説明しています。

また以下のトピックでは、従来の OEM コード ページの取り扱いについて説明しています。

テキストを UTF-8 として格納するようにした場合は、リレーショナル型の CHAR、VARCHAR、および LONGVARCHAR を使用し続けることになるでしょう。また、アプリケーションを実行するオペレーティング システム、アプリケーションで利用可能な文字列操作ライブラリ、アプリケーションで利用する PSQL アクセス方法、異なるデータ型を必要とする可能性がある列などの面でも Unicode サポートを考慮する必要があります。

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 ストレージでの照合順序と並べ替えに対し、コード ポイント順のみをサポートします。

PSQL のアクセス方法である ODBC、JDBC および ADO.NET では UTF-8 ストレージへの変換をサポートします。これらのアクセス方法では、UCS-2 ワイド文字列として、または ANSI ODBC ドライバー向けには従来のバイト文字列として、アプリケーションとテキスト値をやり取りします。適切に設定されれば、これらのアクセス方法はアプリケーションのテキスト値を、ストレージ エンジンへの転送のために UTF-8 へ変換します。

すべてのテキスト データを従来のコード ページから UTF-8 へ変換する必要があります。より長い UTF-8 バイト文字列を収容するために、列は拡張する必要があるでしょう。 テーブル名などの非 ASCII メタデータは、従来のコード ページから UTF-8 へ変換する必要があります。このような複合的な変更から、従来のコード ページを使用する古いスキーマから、データベース コード ページとして UTF-8 を使用する新しいスキーマへコピーすることによって、データベースを移行するのが妥当です。

テキストを UCS-2 として保存するようにした場合は、リレーショナル型の NCHAR、NVARCHAR、および NLONGVARCHAR を使用することになるでしょう。これには、ほかのテキストをリレーショナル型の CHAR ファミリでも格納する能力に影響はありません。また、アプリケーションを実行するオペレーティング システム、アプリケーションで利用可能な文字列操作ライブラリ、アプリケーションで利用する PSQL アクセス方法、異なるデータ型を必要とする可能性がある列などの面でも Unicode サポートを考慮する必要があります。

Unicode UCS-2 は以下のような状況に適しています。

ワイド文字列ストレージは、バイト文字列ストレージとは別の種類で、バイト文字列ストレージと一緒に使用される可能性があります。

ワイド文字の文字列の場合、PSQL ではリレーショナル データ型の NCHAR、NVARCHAR、および NLONGVARCHAR、そして Btrieve データ型の WSTRING と WZSTRING を提供します。NCHAR、NVARCHAR、NLONGVARCHAR、WSTRING および WZSTRING データ型対応のアプリケーションによって挿入されたデータはすべてワイド文字の文字列として解釈されます。

PSQL は SQL クエリ テキストの NCHAR リテラルで Unicode 文字をサポートします。CHAR リテラルのテキスト データはデータベース コード ページへ変換されます。UTF-8 以外のデータベース コード ページは、ほとんどの Unicode 文字を処理できないことを覚えておいてください。

PSQL ではデフォルトで、UCS-2 ストレージでの照合順序と並べ替えに対し、コード ポイント順のみをサポートします。

SQL アクセス方法で NCHAR ストレージを使用する場合、アプリケーションでそのアクセス方法に対する適切な NCHAR SQL 型を指定することが必要です。CHAR 型の使用で、データベース コード ページが UTF-8 でない場合は、NCHAR から CHAR への変換が起こり、データが失われる可能性もあります。

すべての場合において、SQL テキストでは NCHAR リテラルを使用します。

既存のデータベースを UCS-2 アプリケーション対応に移行するための作業には、バイト文字列からワイド文字列への変換が伴います。変換の程度は、対象のアプリケーションに応じて異なります。データベース コード ページが既存の CHAR 列のエンコードと一致するように設定されていれば、ALTER TABLE を使用して列を変換することができます。グローバル化されるデータを格納する列のみを変換する必要があります。データベース コード ページの文字セット外の文字を格納しない列は CHAR 型のままでかまいません。

アプリケーションが Windows で ANSI ODBC ドライバーを使用する場合は、アプリケーションをワイド文字データへ変換し、PSQL Unicode ODBC ドライバーを使用する必要があります。

テキストを従来のコード ページまたは OEM コード ページを使用して格納するようにした場合は、リレーショナル型の CHAR、VARCHAR、および LONGVARCHAR を使用することになるでしょう。従来のコード ページへの変換を行うためにアクセス方法を設定する場合は、ワイド文字アプリケーションを使用することができます。

従来のコード ページで、自分のアプリケーションのニーズを満たす文字セットを定義するのであれば、この従来のコード ページを使用することは、テキスト データの格納にはコンパクトで効率的な方法です。

PSQL データベース エンジンは、CHAR データがデータベース コード ページでエンコードされていると見なしています。アクセス方法には、そうなっていることを保証するための設定オプションがあります。

ストレージに OEM コード ページを使用する古いアプリケーションは、データベース コード ページを宣言しませんでした。アプリケーションが適切なリレーショナル文字列関数を慎重に使用している限りは、この状況で作業し続けることができます。

PSQL でのデフォルトの照合順序は、エンコードされたバイトのバイナリ順です。このデフォルトの照合順序は、宣言されたデータベース コード ページによる影響を受けません。

PSQL は、照合順序の制御にオルタネート コレーティング シーケンス（ACS）とインターナショナル ソート規則（ISR）メカニズムの双方を提供します。これらは、Btrieve インデックスおよびリレーショナル列で宣言することができます。リレーショナル列で CASE 宣言を使用する、または Btrieve インデックスで case-insensitive ビットを使用する場合、PSQL では常に ASCII 文字セット用に特定の ACS を使用します。

PSQL のすべてのアクセス方法で、バイト文字列テキストをサポートします。アクセス方法の中には、データベース コード ページがアプリケーションのコード ページと同じであることを前提としているものもあれば、コード ページを設定できるものもあります。

データベースのコード ページを変更すると、そのデータを、変更後の新しいコード ページを使用する新規データベースへコピーする必要があります。このコピーはアプリケーションで行う必要があります。PSQL はトランザクション内でコード ページを変換しません。

データベースのメタデータで、変換を必要とする文字を使用している場合、その変更は新しいデータベースのスキーマの作成時に行う必要があります。この種類のメタデータの一般的な例として、テーブル名があります。

先の概念と定義で説明したように、エンコードは PSQL データベース エンジンと PSQL クライアント アプリケーション間で文字データをどのように変換するかを指定します。PSQL では、クライアントとサーバー間のエンコードの複雑性、およびオペレーティング システム、言語、アクセス方法のさまざまな組み合わせに対処します。エンコードの機能拡張は、データベース コード ページとクライアント エンコードに分割されています。この 2 種類のエンコードは、別個のものですが相互に関係しています。

データベース コード ページおよびクライアント エンコードは、リレーショナル エンジンのみに適用されます。MicroKernel エンジンには影響がありません。

［データベース コード ページ］はデータベース用プロパティであり、データベースに保存する文字データのエンコードを指定します。デフォルトのデータベース コード ページは "サーバーのデフォルト" で、データベース エンジン実行中のサーバーのオペレーティング システム コード ページを意味します。（オペレーティング システムのコード ページは一般的に「OS エンコード」と呼ばれます。この章のこれ以降の説明ではこの表現を使用します）。

データベース コード ページは、特に、異なる OS エンコードを使用して PSQL DDF を手動で別のプラットフォームへコピーしながら、データベース エンジンにメタデータを正しく変換させたい場合に役立ちます。

PSQL でデータベースを作成する場合、デフォルトでは、データベース エンジンを実行しているマシン用のアクティブ コード ページを使用するようになっています。たとえば、Windows の英語版を実行しているマシンの場合、コード ページには 1252 が割り当てられます。PSQL のエンコード変換は "None"（なし）に設定されます。作成したアプリケーションでは PSQL データベースと同じコード ページを使用するか、エンコード変換を "Automatic"（自動）に設定しておく必要があります。

PSQL では以下のコード ページをサポートします。ここで挙げるページはすべてバイト文字列ストレージを使用します。

クライアントのエンコードは、PSQL クライアント上のアプリケーションが使用するデータ エンコードです。アプリケーションは、任意に選択したエンコードでテキストを管理することができます。データベース エンジンとクライアント アプリケーション間で互換性のあるエンコードを確立する必要があります。

データベース エンジンとクライアントで異なるエンコードを使用している場合でも、文字がサーバー マシンのコード ページとクライアント マシンのコード ページの両方に存在していれば、PSQL がその異なるエンコード間で自動変換することができます。

データの変換は、要求に応じてクライアントで行われます。変換はいつも必要なわけではありません。たとえば、クライアントとサーバーの OS エンコードが一致している場合は不要です。

PSQL Control Center（PCC）それ自体はデータベース エンジンのクライアント アプリケーションです。クライアントとして、PCC では、各データベース セッションで PCC がメタデータおよびデータを読み取りまたは追加する際に使用するエンコードを指定することができます。既存データベースのデフォルトでは、PCC が実行されているマシンのエンコードを使用します。これは、PCC の旧来の動作です。新しいデータベースのデフォルトでは、自動変換を使用します。『PSQL User's Guide』の PCC 接続エンコードを参照してください。

次の表では、PCC 接続エンコードとデータベース コード ページの設定の相互の影響を説明します。PCC 接続エンコードは PCC にのみ適用されます。ほかのクライアント アプリケーションには影響しません。

Btrieve API を使用する場合は、アプリケーションで使用されるローカル エンコードでファイル名とパスを提供する必要があります。Btrieve API は、サーバーおよびクライアント上の OS エンコード間の相違に対処します。

DTI（Distributed Tuning Interface）を使用する場合は、アプリケーションで使用されるローカル エンコードでファイル名とパスを提供する必要があります。DTI は、サーバーおよびクライアント上の OS エンコード間の相違に対処します。

DTI API を使用してデータベースを作成する場合、作成時にデータベース コード ページのプロパティを指定できます。このプロパティは、文字データの自動変換を設定するために SQL アクセス方法で使用できます。

.NET Framework および .NET アプリケーションでは UTF-16 文字列を使用します。これらは、CHAR 列にテキストを格納する場合、コード ページに変換される必要があります。

接続プロパティ PVTranslate=Auto は、接続エンコードをデータベース コード ページに設定します。encoding プロパティを直接設定することもできます。

詳細については、『Data Provider for .NET Guide』の接続の追加、PsqlConnectionStringBuilder オブジェクトおよび文字セットの変換を参照してください。

Java 仮想マシンや Java アプリケーションでは UTF-16 文字列を使用します。これらは、CHAR 列にテキストを格納する場合、コード ページに変換される必要があります。

接続プロパティ PVTranslate=Auto は、接続エンコードをデータベース コード ページに設定します。encoding プロパティを直接設定することもできます。

PvTranslate=Auto プロパティが指定されると、JDBC ドライバーは文字列リテラルを Unicode としてエンジンに送ります。この設定がなければ、従来の動作として文字列リテラルがデータベース コード ページに変換されます。アプリケーションで NCHAR 文字列リテラル（例："N'ABC'"）を使用する場合は、接続プロパティの設定を PvTranslate=Auto にしてください。

『JDBC Driver Guide』の 接続文字列の要素を参照してください。

PSQL ODBC ドライバーは、多くのメカニズムをサポートしてクライアント エンコードを制御します。

DSN を設定する場合、エンコード オプションとして "自動"、"OEM/ANSI"、および "なし" から選択することができます。"自動" を設定すると、ドライバーはクライアント エンコードからデータベース コード ページへ変換するようになります。"OEM/ANSI" を設定すると、ドライバーはクライアント エンコードを対応する OEM コード ページへ変換するようになります。"なし" に設定すると、ドライバーがテキストを変換できないようにします。詳細については、『ODBC Guide』のエンコード変換を参照してください。

データベース内に OEM 文字データがある場合、従来の解決法はアクセス方法で OEM/ANSI 変換を指定することでした。ここでは、OEM 文字データを使用する Linux クライアント向けに従来の方法について説明します。

『ODBC Guide』のOEM/ANSI 変換も参照してください。

ODBC を使用する場合、エンコードは、Win32 の OS では SHIFT-JIS を使用してください。

日本語版の Linux は一般的にデフォルトでそのエンコードを EUC-JP または UTF-8 に設定します。

日本語版の Linux を使用している場合、クライアントは別の Linux サーバー（たとえばローカルに）、あるいは Win32 の SHIFT-JIS サーバーに接続できます。Linux サーバーに置かれている SHIFT-JIS にエンコードされたデータベースに接続することも可能です。

以下に示す手順を使用して必要な設定を行ってください。これらのケースは、アプリケーション自体は何も変換を行わず、そのマシンのネイティブのエンコードを使用することを前提としています。

このサーバーで受け取るものはすべて SHIFT-JIS でなければいけません。サーバーからクライアントに送られるものはすべて EUC-JP でなければいけません。

これを達成するには、指定のデータベースへの接続に使用する ODBC.INI（デフォルトで /usr/local/psql/etc にあります）内のクライアント DSN 設定が次のようになっている必要があります。

TranslationDLL の行では、ODBC クライアント インターフェイスが使用する変換ライブラリを設定します。

TranslationOption の行は、9000（EUC-JP）から 0932（SHIFT-JIS）への変換が必要であることを指定しています。

この例を使用すると、クライアントからのすべてのデータはサーバーに送られる前に SHIFT-JIS に変換され、サーバーがクライアントにデータを送る前には EUC-JP に変換されます。

このサーバーで受け取るものはすべて SHIFT-JIS でなければいけません。サーバーからクライアントに送られるものはすべて UTF-8 でなければいけません。

これを達成するには、指定のデータベースへの接続に使用する ODBC.INI（デフォルトで /usr/local/psql/etc にあります）内のクライアント DSN 設定が次のようになっている必要があります。

TranslationDLL の行では、ODBC クライアント インターフェイスが使用する変換ライブラリを設定します。

TranslationOption の行は、9001（UTF-8）から 0932（SHIFT-JIS）への変換が必要であることを指定しています。

この例を使用すると、クライアントからのすべてのデータはサーバーに送られる前に SHIFT-JIS に変換され、サーバーがクライアントにデータを送る前には UTF-8 に変換されます。

この設定を使用する場合は、DSN の定義を変更する必要はありません。dsnadd ツールで作成されたままの DSN を使用します。

この設定を使用する場合は、DSN の定義を変更する必要はありません。dsnadd ツールで作成されたままの DSN を使用します。『PSQL User's Guide』の dsnadd を参照してください。

このサーバーで受け取るものはすべて EUC-JP でなければいけません。サーバーからクライアントに送られるものはすべて UTF-8 でなければいけません。

これを達成するには、指定のデータベースへの接続に使用する ODBC.INI（デフォルトで /usr/local/psql/etc にあります）内のクライアント DSN 設定が次のようになっている必要があります。

TranslationDLL の行では、ODBC クライアント インターフェイスが使用する変換ライブラリを設定します。

TranslationOption の行は、9001（EUC-JP）から 9000（UTF-8）への変換が必要であることを指定しています。

この例を使用すると、クライアントからのすべてのデータはサーバーに送られる前に EUC-JP に変換され、サーバーがクライアントにデータを送る前には UTF-8 に変換されます。

この状況は Win32 エンジンに SHIFT-JIS データベースがある場合に可能ですが、すべてのファイルを Linux EUC-JP サーバーに移動することができます。この場合、そのデータベースは EUC-JP Linux マシンにありますが、DDF ファイル内のすべてのデータおよびデータ ファイルは SHIFT-JIS です。

この場合、DSN は以下のようになります。

最後の行は、サーバーでは EUC-JP エンコードを使用するが、このサーバー上のデータは SHIFT-JIS として処理することを指定しています。

PSQL ではワイド文字データ用のドライバーを使用する ODBC で UCS-2 をサポートし、また DSN エンコード変換用のデフォルトをサポートします。『ODBC Guide』のエンコード変換およびODBC 接続文字列を参照してください。

PSQL は、ワイド文字データを使用する 32 ビットおよび 64 ビット アプリケーション向けの ODBC ドライバーを提供します。このドライバーは Windows オペレーティング システムのみが対象で、以前からあるドライバーのセットに追加されます。

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 用のエンコード変換オプションは、PSQL データベース エンジンと ODBC を使用する PSQL クライアント アプリケーション間で文字データをどのように変換するかを指定します。エンコード変換のデフォルトは、使用する PSQL ODBC ドライバーによって異なります。

ODBC ドライバーは、ドライバーや DSN エンコード変換の設定に応じて、SQL テキストを処理します。

この章で既に述べた PCC におけるエンコードのサポートセクションも参照してください。

PCC で使用する、SQL ドキュメントを開く/保存用、エクスポートされるスキーマの保存、およびテーブル データのインポート/エクスポート用のダイアログでは機能が改善され、さまざまなファイル エンコードに対応できるようになりました。以前のバージョンでは、これらのファイルにはデフォルトのシステム コード ページが用いられるとみなされていました。ファイルの保存時に複数の Unicode エンコードを選択することはできません。本バージョンの新しいダイアログでは、ファイルを開くときに、そのファイルが Unicode エンコードを識別するバイト オーダー マーク（BOM）を使用するかどうかを検出します。また、ファイルを開くダイアログでは、ファイルに対して必要なエンコードを設定することもできます。新しい PCC 設定では、これらのダイアログで使用されるデフォルトのエンコードを管理できるようになっています。

これらの新機能の詳細については、『PSQL User's Guide』の「［ファイルを開く］ダイアログと［ファイルを保存］ダイアログ」、「データのインポート/エクスポート、スキーマのエクスポートでサポートされるワイド文字データ」および「ファイル エンコードの初期設定」セクションを参照してください。

バルク データ ユーティリティ（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）は、コード ページの照合順序と指定の照合順序間のマッピングです。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 を参照してください。

ACS のもう 1 つのタイプはインターナショナル ソート規則（ISR）です。ISR は、言語固有のソート順用にあらかじめ定義されたオルタネート コレーティング シーケンスです。ISR を使用すれば、ドイツ語などの ä、ö、ü（ae、oe、ue としてソート）および ß（ss としてソート）の文字を持つ言語を正しくソートできます。PSQL は、インストールに含まれる collate.cfg ファイルで多くの ISR テーブルを提供しています。これらの使用例については、『PSQL Programmer's Guide』のインターナショナル ソート規則を使用した照合順序のサンプルに記載されています。詳細については、前述のオルタネート コレーティング シーケンスの参照情報をご覧ください。

PSQL は、UTF-8 または UTF-16 のデータをデフォルトのバイナリ照合順序以外で並べ替える必要がある場合に使用するための、2 つの Unicode 照合順序をサポートしています。これら代替の Unicode 照合順序は、ICU（International Components for Unicode）ライブラリのリリース バージョン 54 に基づいています。次の表は、照合順序をまとめたものです。

ICU 照合順序は ISR テーブル名と同じように使用されますが、PVSW_ や MSFT_ で始まる名前を持たない点が異なります。名前は、プレフィックス u54- を付けた名前にするか、または単に root とする必要があります。また、これらの照合順序は次の Unicode データ型にのみ適用することができます。

デフォルトの 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を参照してください。