他のバージョンの文書10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

Chapter 7. 多言語対応

Table of Contents
7.1. ロケールのサポート
7.1.1. 概要
7.1.2. 利点
7.1.3. 問題点
7.2. マルチバイトサポート
7.2.1. サポートされる文字セット符号化方式
7.2.2. 符号化方式の設定
7.2.3. サーバ・クライアント間の符号化方式自動変換
7.2.4. 翻訳が不可能な場合に起こること
7.2.5. 参照先
7.2.6. 歴史
7.2.7. Windows/ODBC 上の WIN1250
7.3. シングルバイト文字セットの変換

管理者の立場で利用可能な多言語対応機能について説明します。

PostgreSQL は 3 種類の取り上げ方で多言語対応を支援しています。

7.1. ロケールのサポート

ロケールのサポートはアルファベット、並び換え、数字の形式など言語間の文化的嗜好を配慮したあるアプリケーションを対象にします。 PostgreSQL は標準 ISO C と POSIX に類似したサーバのオペレーティングシステム提供の利器であるロケールを使用します。追加情報はお使いのシステムのドキュメントを参照下さい。

7.1.1. 概要

ロケールのサポートは、initdb を使用してデータベースクラスタを作成するとき自動的に初期化されます。 initdb はその実行環境のロケール設定にしたがってデータベースクラスタを初期化します。そのため、システムがデータベースクラスタで使用したいロケールにすでに設定してある場合は何も行う必要はありません。 違うロケールを使用したい場合(またはシステムのロケール設定が不明な場合)は、initdb--locale オプションで、希望のロケールを指定することができます。以下に例を示します。

$ initdb --locale=sv_SE

この例の設定はロケールをスウェーデン(SE)で使用されているスウェーデン語(sv)に合わせています。ほかにも en_US(米国英語)や fr_CA(カナダのフランス語)などの設定もできます。 ロケールに複数の文字セットが使用可能であれば、cs_CZ.ISO8859-2 のように記述することができます。お使いのシステムでどのロケールがどういう名前で使えるかはオペレーティングシステムのベンダーがどのようなものを提供しているかと、何がインストールされているかに依存します。

米国の照合規則でスペイン語のメッセージを使用するときなど、時としていくつかのロケールの規則を併用すると便利です。これをサポートするために、ロケールには多言語対応の規則の特定の箇所だけを管理する一連のサブカテゴリがあります。

LC_COLLATE文字列の並び換え順
LC_CTYPE文字の分類(文字とはどんなもの?大文字小文字を区別しない?)
LC_MESSAGESメッセージの言語
LC_MONETARY通貨形式
LC_NUMERIC数字の書き方
LC_TIME日付と時刻の書き方

これらのカテゴリの名前は、特定のカテゴリについて選択されているロケールを上書きするための initdb オプションの名前としてそのまま使用できます。たとえば、ロケールをカナダのフランス語に設定しながら通貨形式については米国の規則を使用するには、initdb --locale=fr_CA --lc-monetary=en_US とします。

システムがロケールをサポートしていないように動作させたい場合は、特別なロケールの C、もしくは POSIX を使用してください。

一部のロケールカテゴリでは、その値をデータベースクラスタの存続時間に対して固定しなければならないものがあります。なぜなら、initdb の実行後はこれらの値を変更できなくなるからです。LC_COLLATELC_CTYPE がこのカテゴリに入ります。これらはインデックスの並び替え順に影響をおよぼすため、固定されていなければなりません。さもないと、テキスト型列上のインデックスは破壊されます。PostgreSQLinitdb が見れるように LC_COLLATELC_CTYPE の値を記録してこの事が必ず守られるようにします。サーバは起動された時点で自動的にこれらの 2 つの値を採用します。

その他のロケールカテゴリは、実行時の設定にロケールカテゴリと同じ名前の変数を設定することで、いつでもサーバを起動するときに変更することができます (詳細は Section 3.4 を参照してください)。initdb で選択されたデフォルトは、サーバの起動時にデフォルトとして動作するように postgresql.conf 設定ファイルに書き込まれるだけです。この書き込みを postgresql.conf から削除すると、サーバは実行環境の設定をそのまま使用します。

サーバのロケールの動作はどのクライアントの環境にも依存せずサーバが参照できる環境変数で決まります。ですからサーバを稼動させる前に正しいロケール設定を行うように注意してください。結果としてサーバとクライアントで異なるロケールが設定されているとメッセージはそれらがどこから生じたかよって、異なる言語で表示されます。

Note: 実行環境のロケールをそのまま使用するということは、ほとんどのオペレーションシステムでは次のような意味をもちます。指定されたロケールカテゴリ (たとえば照合) について、設定するものが見つかるまで、以下の環境変数がこの順番で調べられます。LC_ALLLC_COLLATE (個別のカテゴリに対応する変数)、LANG。これらのいずれの環境変数も設定されない場合に、ロケールがデフォルトで C に設定されます。

メッセージの言語を設定する目的でローカリゼーションライブラリはすべてのロケール設定を上書きする環境変数 LANGUAGE を見に行きます。嘘だと思うのであればより詳細な情報を得るためお使いのオペレーティングシステムのドキュメント、特に gettext のマニュアルページを参照して下さい。

ユーザーの選択した言語にメッセージを翻訳するには --enable-nls オプションを使用します。このオプションは他のロケールサポートとは独立しています。

7.1.2. 利点

ロケールのサポートは特に以下の機能に影響を与えます。

  • ORDER BY 問い合わせによる並び替え順

  • 一群の to_char 関数

  • パターン照合の LIKE~ 演算子

PostgreSQL でロケールサポートを使用する際のたったひとつの重大な欠点は実行速度です。ですから、本当に必要なときのみロケールを使用してください。また、C 以外のロケールを使用すると LIKE~ 演算子のインデックス最適化が実行できなくなってしまい、それらの演算子を使用する検索のスピードに大きな違いをもたらします。

7.1.3. 問題点

上記の説明に従って設定を行ったにもかかわらずロケールのサポートが正常に動作しない場合、オペレーティングシステムのロケールサポートが正確にコンフィギュレーションされたか確認してください。指定されたロケールがインストールされて、正常に作動するかの確認は、Perl などを使ってできます。Perl もロケールをサポートしていてもしロケールが壊れていると perl -v で以下のようなメッセージが表示されます。

$ export LC_CTYPE='not_exist'
$ perl -v
perl:warning:Setting locale failed.
perl:warning:Please check that your locale settings:
LC_ALL = (unset),
LC_CTYPE = "not_exist",
LANG = (unset)
are supported and installed on your system.
perl:warning:Falling back to the standard locale ("C").

ロケールファイルが正しい場所にあるかの確認を行ってください。 保存場所としては、/usr/lib/localeLinuxSolaris)、/usr/share/localeLinux)、/usr/lib/nls/locDUX 4.0)です。はっきりしない時はロケールのマニュアルページを参照してください。

これだと思っているロケールを PostgreSQL が実際に使用しているか確認します。LC_COLLATELC_CTYPE の設定は initdb の時点で確定され、再度 initdb を実行しないと変更できません。LC_MESSAGESLC_MONETARY を含む他のロケール設定は postmaster が起動された環境によって決まり、 postmaster を単に再起動すれば変更できます。contrib/pg_controldata ユーティリティプログラムでデータベースの LC_COLLATELC_CTYPE の設定を検証できます。

src/test/locale ディレクトリに PostgreSQL のロケールサポートのテスト一式があります。

サーバのメッセージが異なった言語の場合はエラーメッセージのテキストを構文解析してサーバサイドエラーを処理するクライアントアプリケーションで明らかに問題となります。もしそのようなアプリケーションを作成するのであればこの状況に対処する方法を工夫しなければなりません。組み込み SQL インターフェイスの (ecpg) もこの問題の影響を受けます。今のところ ecpg アプリケーションとインターフェイスをとるサーバはメッセージを英語で送るようにコンフィギュレーションするようにお勧めします。

メッセージ翻訳のカタログのメンテナンスには PostgreSQL に選択した言語を話させてみたいという数多くのボランティアのたゆみのない努力を必要としています。もしあなたの言語が現在使えなかったり完全に翻訳されない場合あなたの助力を感謝します。もし助力いただけるのであれば開発者ガイドを参照するか開発グループのメーリングリストに投稿して下さい。