postgresql 6.4 multi-byte (MB) support README 1998/7/22 作成 石井達夫 t-ishii@sra.co.jp http://www.sra.co.jp/people/t-ishii/PostgreSQL/ はじめに： PostgreSQL におけるマルチバイトサポートは以下のような特徴を持っています。 1.マルチバイト文字として、日本語、中国語などの各国の EUC、Unicode、 mule internal code, ISO-8859-1 がデータベース作成時に選択可能。 データベースにはこのコードのまま格納されます。 2.テーブル名にマルチバイト文字が使用可能(ただし、OS がマルチバイト のファイル名を許していることが必要) 3.カラム名にマルチバイト文字が使用可能 4.データそのものにもマルチバイト文字が使用可能 5.マルチバイト文字の正規表現検索が使用可能 6.マルチバイト文字の LIKE 検索が使用可能 7.character_length(), position(), substring() でのマルチバイト サポート 8.環境変数 PGCLIENTENCODING により、クライアント側の文字コード がバックエンド側と異る場合に、自動的にコード変換を行ないます。 インストール： デフォルトでは PostgreSQL はマルチバイトをサポートしていません。 マルチバイトサポートを有効にする方法を説明します。 src/Makefile.custom というファイルを作り、 MB=EUC_JP の 1 行を追加します。あるいは、configure 起動時に以下のように指定します。 % configure --with-mb=EUC_JP 文字コードとしては EUC_JP を含め、以下のコードが initdb による データベース初期化時およびデータベース作成時 (Unix コマンドの createdb もしくは SQL の create database) に指定できます。Makefile.custom あるいは configure で指定した文字コー ドは initdb の省略時の文字コードになります。 EUC_JP 日本語 EUC EUC_CN GB をベースにした中文EUC。code set 2 は SS2+2バイトコード = 3バイト表現です。 EUC_KR 韓国語 EUC。 EUC_TW 台湾の EUC。code set 2 は SS2+面番号+2バイトコード = 4バイト表現です。 UNICODE UTF-8。ただしサポートするのは UCS-2 の範囲、 すなわち 0xffff までです。 MULE_INTERNAL mule の内部コード。ただし、Type N の不定長文字は サポートしていません。 LATIN* ISO8859 Latin シリーズ。* は 1 から 5 まで指定 できます。シングルバイトなんですけど、 試しということで:-) 選択の目安としては、英語と日本語しか使わない場合は EUC_JP(同様に、中 国語しか使わない場合は EUC_CN... などとなります)、その他の言語も使いた い場合は UNICODE もしくは MULE_INTERNAL となるでしょう。 注意：MULE_INTERNAL を選ぶと、たくさんの文字集合に対応できて便利です が、正規表現で複数の文字集合にまたがるような範囲指定(たとえば、[a-範] とか、[abc範囲]のような)は使えません。複数の範囲指定で異なる文字集合 を使うのは構いません(たとえば [abc][範-囲])。また、[^a] のような表現 は、"a" の属する文字集合(この場合、US-ASCII)において "a" 以外である ことを表します。決して漢字や平仮名など "a" 以外をすべて表すわけでは ないことに注意して下さい。 インストールは普通に行ないます。インストールの詳細は INSTALL という テキストファイルを御覧下さい。また、 http://www.sra.co.jp/people/t-ishii/PostgreSQL/ でも簡単なインストー ル方法を紹介しています。 initdb/createdb/create database における文字コードの指定について initdb では以下のオプションで文字コードが指定できます。 -e 文字コード -pgencoding 文字コード ここで指定した文字コードは、以後 createdb/create database で文字コードを 省略した場合に設定される文字コードになります。-e または -pgencoding オプションを省略した場合は、Makefile.custom あるいは configure で指 定した文字コードが採用されます。 createdb では以下のオプションで文字コードが指定できます。 -E 文字コード create database では以下のオプションで文字コードが指定できます。 CREATE DATABASE dbanme WITH ENCODING = '文字コード'; LOCATION を同時に指定する場合は以下のようになります。 CREATE DATABASE dbanme WITH LOCATION = 'path' ENCODING = '文字コード'; createdb/create database は、文字コード指定を省略した場合は、initdb で指定した文字コードが採用されます。 環境変数 PGCLIENTENCODING について： 環境変数 PGCLIENTENCODING が設定されていない場合、libpq はセッション 開始時にサーバ側に文字コードを問い合わせ、その値を環境変数 PGCLIENTENCODING に設定します。 環境変数 PGCLIENTENCODING が設定されている場合はその値が優先され、サー バ側と異なる文字コードが使用できます。設定可能な文字コードは、上記に 加え、SJIS (シフトJIS)が指定できます。 ちなみに、SJIS は JISX0201 の 1バイトカナ、いわゆる「半角カタ カナ」もサポートしています(決して「半角カタカナ」の使用をお勧 めしているわけじゃないですが)。 たとえば、MB=EUC_JP で PostgeSQL がインストールされている場合、 postmaster を立ち上げるときに環境変数 PGCLIENTENCODING に SJIS を設 定すると、クライアントは SJIS コードで PostgreSQL にアクセスできるよ うになります。ただし、データベースに格納されるデータ自体はあくまで MB で指定した EUC_JP のままです。 クライアント側でセッション毎に文字コードを変えることもできます。 セッション開始時に環境変数 PGCLIENTENCODING がセットされていると、そ れが優先されてクライアント側の文字コードに採用されます。この機能を利 用すると、あるユーザは EUC_JP で、別なユーザは SJIS で同じデータベー スにアクセスするというようなことができるようになります。 MB=MULE_INTERNAL で PostgreSQL をインストールしておくと、普段は EUC_JP でクライアントを利用し、複数の文字集合を混在させるときだけク ライアントを MULE_INTERNAL に設定するなどの使い分けができて便利です。 ただ、一般に EUC_JP に比べ、MULE_INTERNAL によるデータ表現はややスペー スを喰うので、そのへんは考慮しておく必要があります。たとえば、2バイ トで表現できる漢字は MULE_INTERNAL では 3バイトを要します。 注意しておく必要があるのは、サーバ側の文字コードとクライアント側の文 字コードがいつも相互変換できるとは限らないことです。極端な話、サーバ 側が EUC_JP なのに、クライアント側が EUC_KR だったらどうなるでしょう。 この場合 PostgreSQL は変換できないコードを 16進表現に変換してしまい ます。たとえば、"(bdae)" のように。なお、この 16進表現は mule internalcode のコードであることに注意して下さい。これは、直接クライ アント <--> サーバの文字コードを変換するのではなく、一度内部表現であ る mule internal code を経由しているためです。 クライアント側の文字コードの設定は、"set client_encoding" コマンドで も可能です。たとえば、 set client_encoding to 'sjis'; で明示的にクライアント側の文字コードを SJIS に設定できます。実際、ク ライアントがサーバに接続する際には libpq の中で "set client_encoding" コマンドを発行しています。セッション中に set client_encoding" コマンドを発行すれば、動的に文字コードの切替え ができますが、その際には環境変数 PGCLIENTENCODING を同時にクライアン トアプリケーションの中で設定し直す必要があります。(psql には現在この 機能がないため、事実上動的にクライアント側の文字コードを設定すること ができません。) 現在設定されているクライアント側の文字コードは show client_encoding; で参照できます。また、 reset client_encoding; は、デフォルトのクライアント文字コード設定に復帰させます。postmaster を立ち上げるときに環境変数 PGCLIENTENCODING が設定されているとその文 字コードに、そうでなければコンパイル時に指定したサーバ側の文字コード と同じになります。 制限事項： SJIS を使用する場合、PostgreSQL のクライアントでまともに対応している のは psql だけです。Tcl/Tk、そのほかは対応してません。 謝辞： o 各種文字セット、コード系について、日本語 PostgreSQL メーリングリスト のメンバの方からアドバイスを頂きました。ここに感謝します。 また、SJIS 対応については、市川@お茶大さんのパッチを参考にさせてい ただきました。 改定履歴： 1998/7/22 6.4 α向けにパッチをリリース。 * initdb/createdb/create database でサーバ側の文字コードを設定 できる機能実装。このため、システムカタログの pg_database に 新しいカラム encoding を追加(MBが有効な時だけ) * copy が PGCLIENTENCODING に対応 * SQL92 の "SET NAMES" をサポート(MBが有効な時だけ) * LATIN2-5 をサポート * regression test に unicode のテストケースを追加 * MB 専用の regression テストディレクトリ test/mb を追加 * ソースファイルの置き場所を大幅見直し。MB 関係は include/mb, backend/utils/mb に置くようにした 1998/5/25 バグ修正(mb_b3.patch として pgsql-jp ML にリリース、 本家では 6.4 snapshot に取り込まれる予定) 1998/5/18 機能追加／バグ修正(mb_b2.patch として pgsql-jp ML にリリース、 本家では 6.4 snapshot に取り込まれる予定) * 環境変数 PGCLIENTENCODING のサポート。クライアント側の 文字コードを指定する。現在、SJIS, EUC_*, MULE_INTERNAL, LATIN1 が指定できる。また、 set client_encoding to 'sjis'; でも可能 * 8bit 文字が渡ると問題が起きる箇所にできるだけ対応 1998/4/21 機能追加／バグ修正(mb_b1.patch として pgsql-jp ML にリリース、 本家では 6.4 snapshot に取り込まれている) * character_length(), position(), substring() のマルチバイト 対応 * octet_length() 追加 → initdb のやり直し必要 * configure のオプションに MB サポート追加 (ex. configure --with-mb=EUC_JP) * EUC_KR の regression test 追加 ("Soonmyung. Hong" さん提供) * EUC_JP の regression test に character_length(), position(), substring(), octet_length() 追加 * regress.sh の SystemV における非互換性修正 * toupper(), tolower() に 8bit 文字が渡ると落ちることが あるのを修正 1998/3/25 PostgreSQL 6.3.1 リリース、MB PL2 が取り込まれる 1998/3/10 PL2 をリリース * EUC_JP, EUC_CN, MULE_INTERNAL の regression test を追加 (EUC_CN のデータは he@sra.co.jp さん提供) * regexp において、isalpha などに unsigend char 以外の値が 渡らないようにガードをかける * 英語のドキュメントを追加 * MB を定義しない場合に発生するバグを修正 1998/3/1 PL1 をリリース 以上。