PostgreSQL 7.2 multi-byte (MB) support README 2001/9/18 作成 石井達夫 ishii@postgresql.org http://www.sra.co.jp/people/t-ishii/PostgreSQL/ ■はじめに PostgreSQL におけるマルチバイトサポートは以下のような特徴を持っています． 1. マルチバイト文字として，日本語，中国語などの各国の EUC，Unicode， mule internal code, ISO-8859-* がデータベース作成時に選択可能． データベースにはこのコードのまま格納されます． 2. テーブル名にマルチバイト文字が使用可能 3. カラム名にマルチバイト文字が使用可能 4. データそのものにもマルチバイト文字が使用可能 5. マルチバイト文字の正規表現検索が使用可能 6. マルチバイト文字の LIKE 検索が使用可能 7. character_length(), position(), substring() などの文字列関数で のマルチバイトサポート 8. フロントエンド側のエンコーディングがバックエンド側と異る場合に， 自動的にコード変換を行ないます． ■インストール デフォルトのコンフィギュレーションでは PostgreSQL はマルチバイトを サポートしていません．マルチバイトサポートを有効にする方法を説明します． たとえば日本語 EUC を主に利用する場合は，configure 起動時に以下のよ うに指定します． $ ./configure --enable-multibyte=EUC_JP 7.1 では，--enable-unicode-conversion を指定しないと Unicode とそれ 以外のエンコーディングの間の変換ができませんでしたが，7.2 以降では単 に --enable-multibyte を指定しただけで自動的に --enable-unicode-conversion が有効になります．ただし， --enable-multibyte を指定しながら，--enable-unicode-conversion だけ を無効にすることはできません． エンコーディングとしては EUC_JP の他，以下が指定できます． SQL_ASCII ASCII EUC_JP 日本語 EUC EUC_CN GB をベースにした中文EUC．code set 2 は SS2+2バイトコード = 3バイト表現です． EUC_KR 韓国語 EUC． JOHAB ハングルベースの韓国語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 まで指定 できます． キリル文字 KOI8(KOI8-R), WIN(CP1251), ALT(CP866)をサポート しています．もちろん ISO 8859-5 も使用可能です． この場合，"LATIN5" として指定して下さい． WIN1256 アラブ諸国語Windows用エンコーディング. TCVN ベトナム語."ABC"や"VSCII"も使用可能. WIN874 タイ語. 選択の目安としては，英語と日本語しか使わない場合は EUC_JP(同様に，中 国語しか使わない場合は EUC_CN... などとなります)，その他の言語も使いた い場合は UNICODE もしくは MULE_INTERNAL となるでしょう． エンコーディングを省略した場合，デフォルト値として SQL_ASCII が採用 されます． なお，configure で選択したエンコーディングは，あくまで initdb のための デフォルト値程度の意味しかありません(initdb では引数でエンコーディングが 指定できます)．したがって，異なるエンコーディングを使用するために わざわざ PostgreSQL をリコンパイルする必要ありません． initdb は shell script なので，デフォルトのエンコーディングは script を 適当なエディタで編集することにより簡単に変更できます．initdb の 61行目 付近に， MULTIBYTE=EUC_JP のような行があるので，= 以降を希望するエンコーディングに変えるだけです． 注意：MULE_INTERNAL を選ぶと，たくさんの文字集合に対応できて便利です が，正規表現で複数の文字集合にまたがるような範囲指定(たとえば，[a-範] とか，[abc範囲]のような)は使えません．複数の範囲指定で異なる文字集合 を使うのは構いません(たとえば [abc][範-囲])．また，[^a] のような表現 は，"a" の属する文字集合(この場合，US-ASCII)において "a" 以外である ことを表します．決して漢字や平仮名など "a" 以外をすべて表すわけでは ないことに注意して下さい． インストールは --enable-multibye なしの場合と同様に行ないます．イン ストールの詳細は INSTALL というテキストファイルを御覧下さい．また， http://www.sra.co.jp/people/t-ishii/PostgreSQL/ でも簡単なインストー ル方法を紹介しています． ■initdb/createdb/create database におけるエンコーディングの指定について initdb では以下のオプションでエンコーディングが指定できます． -E エンコーディング --encoding=エンコーディング ここで指定したエンコーディングは，以後 createdb/create database でエ ンコーディングを省略した場合に設定されるエンコーディングになります． -E または --encoding オプションを省略した場合は，configure で指定し たエンコーディングが採用されます． createdb では以下のオプションでエンコーディングが指定できます． -E エンコーディング --encoding=エンコーディング create database では以下のオプションでエンコーディングが指定できます． CREATE DATABASE dbanme WITH ENCODING = 'エンコーディング'; LOCATION を同時に指定する場合は以下のようになります． CREATE DATABASE dbanme WITH LOCATION = 'path' ENCODING = 'エンコーディング'; createdb/create database では，エンコーディング指定を省略した場合は，initdb で指定したエンコーディングが採用されます．これは，initdb が作成する テンプレートデータベース(template1)の encoding アトリビュートを継承 するからです． データベースのエンコーディングは，psql -l，psql の \l で参照できます． $ psql -l List of databases Database | Owner | Encoding ---------------+---------+--------------- euc_cn | t-ishii | EUC_CN euc_jp | t-ishii | EUC_JP euc_kr | t-ishii | EUC_KR euc_tw | t-ishii | EUC_TW mule_internal | t-ishii | MULE_INTERNAL regression | t-ishii | SQL_ASCII template1 | t-ishii | EUC_JP test | t-ishii | EUC_JP unicode | t-ishii | UNICODE (9 rows) ■文字型のデータ型について 7.2では，CHAR(n)とVARCHAR(n)の n は文字数を意味します．n がバイト数を 意味する 7.1 以前とは異なりますのでご注意下さい． 例を示します． 7.2では，CHAR(1)に"あ"を格納できますが，7.1以前では格納できませんこ れは，"あ"を格納するために少なくとも2バイト以上を要するからです． 逆に，"a" は1バイトしか消費しないため，7.1でも CHAR(1) に格納できま す． なお，7.2では，7.1までと異なり，CHAR(n)に格納できない n 文字より大き い文字列は n 文字で切り捨てられるのではなく，エラーになることにご注 意下さい．これは，マルチバイト対応の有無に関わらず，文字列の扱いが SQL標準に沿うように変ったからです． ■フロントエンドとバックエンドの自動エンコーディング変換について バックエンド(データベース)と psql などのフロントエンドのエンコーディ ングは一致しているのが原則ですが，いくつかのエンコーディングについて はバックエンドとフロントエンドの間で異なるものを使用することができま す．この場合，自動的にバックエンドでエンコーディング変換が行われます． バックエンドのエンコーディング 許容されるフロントエンドの エンコーディング ---------------------------------------------------------------- EUC_JP EUC_JP, SJIS, UNICODE EUC_TW EUC_TW, BIG5, UNICODE EUC_CN EUC_CN, UNICODE EUC_KR EUC_KR, UNICODE JOHAB JOHAB, UNICODE LATIN1,3,4 LATIN1,3,4, UNICODE LATIN2 LATIN2, WIN1250, UNICODE LATIN5 LATIN5, WIN, ALT, UNICODE LATIN6,7,8,9,10 LATIN6,7,8,9,10, UNICODE ISO_8859_5,6,7,8 ISO_8859_5,6,7,8, UNICODE WIN1256 WIN1256, UNICODE TCVN TCVN, UNICODE WIN874 WIN874, UNICODE MULE_INTERNAL EUC_JP, SJIS, EUC_KR, EUC_CN, EUC_TW, BIG5, LATIN1から5, WIN, ALT, WIN1250 UNICODE EUC_JP, SJIS, EUC_KR, UHC, EUC_CN, GBK, EUC_TW, BIG5, LATIN1から10, ISO_8859_5から8, WIN, ALT, WIN1250, WIN1256, TCVN, WIN874, JOHAB ---------------------------------------------------------------- バックエンドとフロントエンドのエンコーディングが異なる場合，そのこと をバックエンドに伝える必要があります．そのための方法がいくつかありま す． o psql の \encoding コマンドを使う方法 psqlでは，\encodingコマンドを使って動的にフロントエンド側の文字コー ドを切替えることができます．例: \encoding SJIS o libpq の関数 PQsetClientEncoding を使う方法 7.0 から新しい libpq 関数 PQsetClientEncoding が追加されています． PQsetClientEncoding(PGconn *conn, const char *encoding) この関数を使えば，コネクション毎にエンコーディングを切替えることがで きます．現在のエンコーディングの問い合わせは int PQclientEncoding(const PGconn *conn) です． o 環境変数 PGCLIENTENCODING を使う方法 上記方法で対応できない場合，あるいはフロントエンドで使われるエンコー ディングがあらかじめ分かっている場合は環境変数 PGCLIENTENCODING を使 うのが便利です．この方法は更に大きく2つに分かれます． (1) postmaster 起動時に環境変数を設定する方法 すべてのクライアント(フロントエンド)が同じエンコーディングを使うのが 分かっている場合，postmaster 起動時に環境変数 PGCLIENTENCODING を設 定します．この場合でも，(2)の方法で個々のクライアント毎に別のエンコー ディングを設定することができます． (2) クライアント，フロントエンド毎にエンコーディングを設定したい場合 この場合はそのフロントエンド(たとえば psql)を起動する前に環境変数 PGCLIENTENCODING を設定します． o set client_encoding コマンドを使う方法 上記(2)の方法は，libpq を使っていない JDBC や ODBC では使用できませ ん．この場合，SQLコマンドである set client_encoding コマンドを利用し ます．例： set client_encoding to 'sjis'; ■現在設定されているフロントエンド側のエンコーディングを調べる 現在設定されているフロントエンド側のエンコーディングは show client_encoding; で参照できます． ■デフォルトのエンコーディングへの復帰 SQLコマンド: reset client_encoding; は，デフォルトのフロントエンドエンコーディング設定に復帰させます． postmasterを立ち上げるときに環境変数 PGCLIENTENCODING が設定されてい るとそのエンコーディングに，そうでなければデータベースのエンコーディ ングと同じになります． ■明示的なエンコーディング変換 7.2では，convertという関数を使い，明示的なエンコーディング変換ができ ます． convert(string text, [src_encoding name,] dest_encoding name) ここでsrc_encodingはtextのエンコーディング名です．省略すると，データ ベースエンコーディング名と同じであると見なされます．dest_encodingは， 変換後のエンコーディング名です． 例を示します． SELECT convert(text, EUC_JP) FROM unicode_tbl; は，Unicodeのテーブルunicode_tblのtext列をEUC_JPに変換して返します． ■エンコーディング変換不能の場合の処理 バックエンド側のエンコーディングとフロントエンド側のエンコーディング がいつも相互変換できるとは限りません．極端な話，バックエンド側が EUC_JP なのに，フロントエンド側が EUC_KR だったらどうなるでしょう． この場合 PostgreSQL は変換できないコードを 16進表現に変換します． たとえば，"(bdae)" のように．なお，この 16進表現は mule internal code のコードであることに注意して下さい．これは，直接フロン トエンド <--> バックエンドのエンコーディングを変換するのではなく，一 度内部表現である mule internal code を経由しているためです． なお，Unicodeとそれ以外のエンコーディングの変換だけは例外で，NOTICE メッセージが表示され，変換不能の文字は無視されます． ■SJISユーザ定義文字への対応 7.0 から SJISユーザ定義文字 (UDC) に対応しています．UDC をどう扱うか と言うことについて中条さん(nak@email.com)から問題提起と詳細な解説を 頂きましたので，参考のためにこのドキュメントの最後に付けておきます． また，この問題については，PostgreSQL日本語メーリングリストの [pgsql-jp 12288] (1999/12/17付)と [pgsql-jp 12486] (2000/1/5付) から 始まるスレッドで議論を見ることができます(メールのアーカイブは http://www.sra.co.jp/people/t-ishii/PostgreSQL/ で参照できます)． ここでは，それらの議論をふまえ，簡単に解説します． PostgreSQLでは，日本語を使用する際にバックエンド側のエンコーディング を EUC_JP または MULE_INTERNAL or Unicode にする必要があります． MULE_INTERNAL は EUC_JP に文字集合を表すコードを付けたものなので，本 質的に同じです．また，Unicode <---> SJIS 変換は現在のところサポート されていませんので無視します．したがって，ここでは EUC_JP と SJIS の 相互変換のみを考えます． 予備知識 一口に EUC_JP といっても，実際には中身は複数の文字集合から成り立って います． G0: JIS ROMAN (ASCII とほぼ同じ) G1: JIS X 0208 (JIS 漢字) G2: JIS X 0201 (1バイトカナ) G3: JIS X 0212 (JIS 補助漢字) 一方 SJIS はこのうち基本的に G0, G1, G2 をサポートしており，G3 はサ ポートしていません．したがって，SJIS は EUC_JP の部分集合とみなすこ とができ，実際 PostgreSQL 6.5 まではこの考えで実装されていました． ところが，Windows PC の SJIS の世界では，上記 JIS 規格で定義されてい ない文字コードが一部利用されており，この部分 (UDC) は従来 PostgreSQL では全く考慮されていませんでした．実際 UDC を含む SJIS を EUC_JP に 変換するときに不正な変換が行われていました．そこで PostgreSQL 7.0 で は，まずこの問題を解決することにしました． また，UDC の利用方については標準規格のようなものはありませんが，実は 業界団体での取り決めがあり，いわゆるデファクトスタンダードならば存在 することが分かりました．そこでこれについてもできるだけサポートするこ とにしました． PostgreSQL 7.0 での UDC 対応の実装 (1) ユーザ定義文字領域は JIS のユーザ定義文字領域にマッピングする． SJIS と EUC_JP で1対1の対応になります． - SJIS ユーザ定義文字領域 A (仮称) 95〜104 区 ←→ 日本語 EUC / G1 (JIS X 0208) 85〜95 区 - SJIS ユーザ定義文字領域 B (仮称) 105〜114 区 ←→ 日本語 EUC / G3 (JIS X 0212) 85〜95 区 (2) IBM 拡張文字領域 (SJIS 115〜120 区) 変換テーブルによって G1 (JIS X 0208)と，G3 (JIS X 0212)に変換されま す．なお，この変換においては，SJIS --> EUC_JP で変換し，再び EUC_JP -- > SJIS に変換すると元の SJIS に戻らないことがあります．また，EUC_JP -- > SJIS の変換では，すべての文字を変換できるわけではないので，その場 合は変換不能文字として「〓」に置き換えます． *業界団体の取り決めでは，変換不能文字は「実装依存」となっていますが， Solaris をはじめ，多くのシステムが「〓」を変換不能文字に採用していま す．PostgreSQLもこれに合わせました． (3) NEC 選定 IBM 拡張文字領域 (SJIS 89〜92 区) PostgreSQL 7.0ではすべて変換不能文字「〓」に置き換えられます． PostgreSQL 7.0.1以降では，一旦 IBM 拡張文字領域に変換された後，G1 (JIS X 0208)と，G3 (JIS X 0212)に変換されます． 謝辞： o 徳家@三協運輸サービスさんから，NEC 選定 IBM 漢字対応パッチを提供し ていただきました． o 各種文字セット，コード系について，日本語 PostgreSQL メーリングリスト のメンバの方からアドバイスを頂きました．ここに感謝します． また，SJIS 対応については，市川@お茶大さんのパッチを参考にさせてい ただきました． o SJISユーザ定義文字 (UDC) をどう扱うかと言うことについて中条さん (nak@email.com)から問題提起と詳細な解説を頂きました． ■Unicodeとそれ以外のエンコーディングとの相互変換について PostgreSQL 7.1からUnicodeとそれ以外のエンコーディングとの相互変換が 可能になりました．この変換はごく一部の文字コード(ISO 8859-1)をのぞき， ロジックによる変換ができないため，変換の際にはテーブルが必要になりま す．PostgreSQLの実装では，Unicode変換テーブルは Unicode organization が提供するものを使用，これをPerlプログラムでC言語のテーブルに変換し て作成しています(PerlプログラムはNARITA Tomio氏作成のlvバージョン 4.3.6 に付属するものを改造の上，利用しています)．Unicode organizationの提供する変換テーブルは再配布が許可されていないため， PostgreSQLのソースコードには含まれていません．以下，使用した変換テー ブルを列挙します． エンコーディング 変換テーブル ============================================================ ISO 8859-1 なし ISO 8859-2 8859-2.TXT ISO 8859-3 8859-3.TXT ISO 8859-4 8859-4.TXT ISO 8859-5 8859-5.TXT ISO 8859-6 8859-6.TXT ISO 8859-7 8859-7.TXT ISO 8859-8 8859-8.TXT ISO 8859-9 8859-9.TXT ISO 8859-10 8859-10.TXT ISO 8859-13 8859-13.TXT ISO 8859-14 8859-14.TXT ISO 8859-15 8859-15.TXT ISO 8859-16 8859-16.TXT EUC_JP JIS0201.TXT, JIS0208.TXT, JIS0212.TXT, CP932.TXT, sjis.map SJIS CP932.TXT EUC_CN GB2312.TXT GBK CP936.TXT EUC_KR KSX1001.TXT UHC CP949.TXT JOHAB JOHAB.TXT EUC_TW CNS11643.TXT Big5 BIG5.TXT WIN1256 CP1256.TXT TCVN CP1258.TXT WIN874 CP874.TXT ============================================================ 謝辞： o 徳家@三協運輸サービスさんから，CP932.TXTより生成したSJIS用の変換テー ブルを提供していただきました．これにより，IBM 拡張文字領域 (SJIS 115〜120 区), NEC 選定 IBM 拡張文字領域 (SJIS 89〜92 区)に対応する ことができるようになりました． 参考1： Pavel Behal氏により提供されたWIN1250サポートですが，Windows環境での 利用の仕方について参考になるドキュメントが付属しているので，ここに添 付しておきます． ------------------------------------------------------------------- Version: 0.91 for PgSQL 6.5 Author: Pavel Behal Revised by: Tatsuo Ishii Email: behal@opf.slu.cz Licence: The Same as PostgreSQL Sorry for my Eglish and C code, I'm not native :-) !!!!!!!!!!!!!!!!!!!!!!!!! NO WARRANTY !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Instalation: ------------ 1) Change three affected files in source directories (I don't have time to create proper patch diffs, I don't know how) [PostgreSQL 6.5.1ではこのステップは必要ありません．-- 石井] 2) Compile with enabled locale and multibyte set to LATIN2 3) Setup properly your instalation, do not forget to create locale variables in your profile (environment). Ex. (may not be exactly true): LC_ALL=cs_CZ.ISO8859-2 LC_COLLATE=cs_CZ.ISO8859-2 LC_CTYPE=cs_CZ.ISO8859-2 LC_MONETARY=cs_CZ.ISO8859-2 LC_NUMERIC=cs_CZ.ISO8859-2 LC_TIME=cs_CZ.ISO8859-2 4) You have to start the postmaster with locales set! 5) Try it with Czech language, it have to sort 5) Install ODBC driver for PgSQL into your M$ Windows 6) Setup properly your data source. Include this line in your ODBC configuration dialog in field "Connect Settings:" : SET CLIENT_ENCODING = 'WIN1250'; 7) Now try it again, but in Windows with ODBC. Description: ------------ - Depends on proper system locales, tested with RH6.0 and Slackware 3.6, with cs_CZ.iso8859-2 loacle - Never try to set-up server multibyte database encoding to WIN1250, always use LATIN2 instead. There is not WIN1250 locale in Unix - WIN1250 encoding is useable only for M$W ODBC clients. The characters are on thy fly re-coded, to be displayed and stored back properly Important: ---------- - it reorders your sort order depending on your LC_... setting, so don't be confused with regression tests, they don't use locale - "ch" is corectly sorted only in some newer locales (Ex. RH6.0) - you have to insert money as '162,50' (with comma in aphostrophes!) - not tested properly ------------------------------------------------------------------- 参考2：SJISユーザ定義文字 (UDC) をどう扱うかと言うことについて中条さん (nak@email.com)からいただいた問題提起と解説です． -------------------------- 引用開始 ---------------------------------- --- 1. SJIS コードの範囲 1 バイト目 0x81 - 0x9F，0xE0 - 0xFC 2 バイト目 0x40 - 0x7E，0x80 - 0xFC いわゆる「外字領域」の範囲: - X0208 共通自由領域 |-------------------- | 85 区 0xEB40 〜 |... |-------------------- | 89 区 0xED40 〜 ; 89〜92 区は |... ; 「NEC 選定 IBM 拡張文字領域」 |-------------------- ; と呼ばれる | 93 区 0xEF40 〜 | 94 区 0xEF9F 〜 0xEFFC - ユーザ定義文字領域 |-------------------- | 95 区 0xF040 〜 ; 95〜104 区 |... ; 「ユーザ定義文字領域 A」(仮称) |-------------------- |105 区 0xF540 〜 ; 105〜114 区 |... ; 「ユーザ定義文字領域 B」(仮称) |-------------------- |115 区 0xFA40 〜 ; 115〜120 区は一般に |... ; 「IBM 拡張文字領域」 |120 区 ... ; と呼ばれる |-------------------- --- 2. i-mode 端末が使っている図形文字コードの範囲 0xF89F - 0xF8FC (112 区) 0xF940 - 0xF949 (113 区) 0xF972 - 0xF97E (113 区) 0xF980 - 0xF990 (113 区) 0xF9B0 (114 区) --- 3. 一般的な EUC 日本語コードの定義 G0 : [0x21-0x7E] ; いわゆる JIS ROMAN G1 : [0xA1-0xFE] [0xA1-0xFE] ; JIS X 0208 G2 : 0x8E [0xA1-0xDF] ; JIS X 0201 カナ G3 : 0x8F [0xA1-0xFE] [0x21-0x7E] ; JIS X 0212 補助漢字 --- [問題点] SJIS 95〜120 区は JIS X0208 に該当する領域が存在しない ため，この領域の EUC - SJIS 文字コード変換は各ベンダに よって異なるのではないか，というのが石井様からのご指摘 でした． --- [議論] 調査の結果，SJIS 95〜120 区を EUC に変換するための標準的な ルールがないわけではない，ということがわかりました．詳細は 後述の参考資料をご覧いただくとして，ここではそのルールを 簡単にご説明いたします． - SJIS ユーザ定義文字領域 A (仮称) 95〜104 区 ←→ 日本語 EUC / G1 85〜95 区 たとえば SJIS の (95, 1) = 0xF040 は EUC の 0xF5A1 になります． - SJIS ユーザ定義文字領域 B (仮称) 105〜114 区 ←→ 日本語 EUC / G3 85〜95 区 たとえば SJIS の (105, 1) = 0xF540 は EUC の 0x8FF5A1 になります． - IBM 拡張文字領域 115〜120 区 JIS X 0208 (日本語 EUC / G1)，JIS X 0212 (日本語 EUC / G3) に該当する文字がある場合 はその文字にマッピング．そうでない場合は 日本語 EUC / G3 83〜84 区を，区点コードの上位 から順に割り当てていく (変換テーブル方式) この仕様は，広く使われている SJIS と EUC のマッピングがベンダに よって異なるため，相互運用の際に問題になっていることから，1996 年に OSF 日本ベンダ協議会が検討作成した報告書がベースになってい るようです． Solaris のドキュメントには「TOG 日本ベンダ協議会推奨 EUC・シフト JIS コード変換仕様」にもとづくと書いてあり，Solaris 2.6 から導入 しているのだそうで，私から見れば事実上の標準と考えても不自然では ないと感じます． なお，少なくとも 1996 年当時においては，Oracle や Sybase は SJIS のユーザ定義/ベンダ定義文字領域を EUC に変換する際，判別不 可能文字として扱っているらしいということも補足しておきます． --- [参考資料] // URL が長いので，途中で切れないといいのですが... -「日本語 EUC・シフト JIS コード変換仕様とコード系実態調査」 1966, OSF 日本ベンダ協議会 http://www.opengroup.or.jp/jvc/cde/sjis-euc.html -「文字コード変換規則」 Solaris 7，JFP ユーザーズガイド http://docs.sun.com/ab2/coll.139.3/JFPUG/@Ab2PageView/11683?Ab2Lang=ja&Ab2Enc=euc-jp -「日本語文字コード」 Solaris 7，JFP ユーザーズガイド http://docs.sun.com/ab2/coll.139.3/JFPUG/@Ab2PageView/879;td=5?Ab2Lang=ja&Ab2Enc=euc-jp // 謎の「1〜20 区」の記述はここからきています． --- -------------------------- 引用ここまで --------------------------------- 改定履歴： 2001/10/01 * CONVERTの追加．lpad/rpad/trim/btrim/ltrim/rtrim/translateの マルチバイト対応追加．char/varcharでバイト数ではなく，文字数 でサイズを定義するように変更．以上，7.2に反映されます． 2001/2/15 * 徳家@三協運輸サービスさんから，CP932.TXTより生成したSJIS用の 変換テーブルを提供していただきました．7.1に反映されます． 2001/1/6 * UNICODEと他のエンコーディングとの相互変換機能を追加． * 7.1に反映されます． 2000/5/20 * NEC 選定 IBM 漢字対応を追加しました．これは 徳家@三協運輸サービス さんからの contribute です． * これらは，7.0.1 に反映されます． 2000/3/22 * PQsetClientEncoding, PQclientEncoding をlibpq 関数に追加， コネクション毎にエンコーディングを変更可能に． * SJIS ユーザ定義文字 (UDC) への対応 * ./configure --with-mb=EUC_JP から ./configure --enable-multibyte=EUC_JP に変更 * SQL_ASCII の regression test 追加 * これらは 7.0 に反映されます． 1999/7/11 WIN1250(Windows用のチェコ語)サポートを追加しました． * WIN1250 がフロントエンド側のエンコーディングとして利用できるよ うになりました．この場合，バックエンド側のエンコーディングは LATIN2 または MULE_INTERNAL とします． (contributed by Pavel Behal) * backend/utils/mb/conv.cにおける型の不整合を修正しました． (contributed by Tomoaki Nishiyama) * これらは6.5.1に反映されます． 1999/3/23 キリル文字サポート追加他(6.5 に反映済) * エンコーディングとして KOI8(KOI8-R), WIN(CP1251), ALT(CP866) を サポートしています．これらは，フロントエンド，バックエンド， どちらのエンコーディングとしても使用可能であり，エンコーディングの 相互変換が可能です．また，従来からサポートしている ISO 8859-5 も 同様に使用可能です． キリル文字サポートは，Oleg Broytmann 氏の リクエスト及び協力により実現しました．これは，従来からある RCODE サポートの機能を取り込むものでもあります． * MB と locale を同時に指定した場合に大文字／小文字を無視した 正規表現検索が正常に動作しないバグを修正 1999/1/26 Big5 サポート追加(6.4.2-patched/6.5 に反映済) * Big5 がフロントエンド側のエンコーディングとして利用できるよ うになりました．この場合，バックエンド側のエンコーディングは EUC_TW または MULE_INTERNAL とします． * EUC_TW の regression test ケースを追加 (contributed by Jonah Kuo ) 1998/12/16 本ドキュメント修正(6.4.2 に反映済)． * Makefile.custom で MB=EUC_JP などと設定する方法は 6.4 以降 サポートされていないので削除した． * 文字コード → エンコーディング，クライアント→フロントエンド サーバ→バックエンド にそれぞれ語句を修正． 1998/12/15 6.4 向けバグ修正パッチリリース(6.4.2 に反映済)． * SQL_ASCII サポートのバグ修正 1998/11/21 6.4 向けバグ修正パッチリリース(6.4.2 に反映済)． * BINARY CURSOR の問題を修正 * pg_dumpall のバグ修正 1998/11/5 6.4 リリース． * pg_database の encoding カラムが MB が有効でないときにも 追加されるようになった．そのため，MB が有効でないときには， ASCII のエンコーディングを表す SQL_ASCII を新しいエンコーディング として追加した．これにともない，エンコーディング名に対応する エンコーディングIDが SQL_ASCII を 0 とする番号に変更になった． 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 をリリース 以上．