PostgreSQL 7.3 multi-byte (MB) support README 2002/10/21 作成 石井達夫 ishii@postgresql.org ■はじめに PostgreSQL におけるマルチバイトサポートは以下のような特徴を持っています． 1. マルチバイト文字として，日本語，中国語などの各国の EUC，Unicode， mule internal code, ISO-8859-* がデータベース作成時に選択可能． データベースにはこのエンコーディングのまま格納されます． 2. テーブル名にマルチバイト文字が使用可能 3. カラム名にマルチバイト文字が使用可能 4. データそのものにもマルチバイト文字が使用可能 5. マルチバイト文字の正規表現検索が使用可能 6. マルチバイト文字の LIKE 検索が使用可能 7. character_length(), position(), substring() などの文字列関数で のマルチバイトサポート 8. フロントエンド側のエンコーディングがバックエンド側と異る場合に， 自動的にエンコーディング変換を行ないます． 9. ユーザ定義のエンコーディング変換を作成可能． マルチバイトサポートが扱うことのできるエンコーディングは以下になりま す． 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 の不定長文字は サポートしていません． LATIN1 から LATIN10まで ISO_8859_1 から 16まで キリル文字 KOI8(KOI8-R), WIN(CP1251), ALT(CP866)をサポート しています．もちろん ISO 8859-5 も使用可能です． この場合，"LATIN5" として指定して下さい． WIN1256 アラブ諸国語Windows用エンコーディング. TCVN ベトナム語."ABC"や"VSCII"も使用可能. WIN874 タイ語. フロントエンド側ではさらに以下のエンコーディングが使用できます． SJIS シフトJIS(MS932とほぼ互換) BIG5 台湾や香港で使用されている中国語．EUC_TWと互換 性があります． GBK Windows-936 UHC Windows-949 WIN1250 Windows-1250 GB18030 GB18030 ■日本語を使用することのできるエンコーディング 選択の目安としては，英語と日本語しか使わない場合は EUC_JP(同様に，中 国語しか使わない場合は EUC_CN... などとなります)，その他の言語も使いた い場合は UNICODE もしくは MULE_INTERNAL となるでしょう． 注意：MULE_INTERNAL を選ぶと，たくさんの文字集合に対応できて便利です が，正規表現で複数の文字集合にまたがるような範囲指定(たとえば，[a-範] とか，[abc範囲]のような)は使えません．複数の範囲指定で異なる文字集合 を使うのは構いません(たとえば [abc][範-囲])．また，[^a] のような表現 は，"a" の属する文字集合(この場合，US-ASCII)において "a" 以外である ことを表します．決して漢字や平仮名など "a" 以外をすべて表すわけでは ないことに注意して下さい． ■インストール PostgreSQL 7.3からはconfigureのオプション指定の有無に関わらず，マル チバイトサポートが有効になっていますので，特にconifgure時にマルチバ イト用の特別なオプションを指定する必要はありません． ■initdb/createdb/create database におけるエンコーディングの指定について initdb では以下のオプションでエンコーディングが指定できます． -E エンコーディング --encoding=エンコーディング ここで指定したエンコーディングは，以後 createdb/create database でエ ンコーディングを省略した場合に設定されるエンコーディングになります． -E または --encoding オプションを省略した場合は，エンコーディングと してSQL_ASCIIが採用されてしまうので，日本語をデフォルトで使用する場 合は， -E EUC_JP あるいは --encoding=EUC_JP として必ず明示的にエンコーディングを指定してください． なお，PostgreSQL 7.3以降ロケールサポートが必ず有効になっていますが， これは日本語などを使用する際には何のメッリトもないばかりでなく，障害 の原因になったり，LIKE検索や正規表現検索でインデックスが有効にならな いなどの問題を引き起こすので，無効にしておくことをおすすめします．ロ ケールサポートを無効にするためには， --no-locale オプションを指定します． 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 postgresql.conf で設定する方法 フロントエンドのデフォルトエンコーディングを指定するには， postgresql.conf の client_encoding を指定します．指定例: client_encoding = SJIS o 環境変数 PGCLIENTENCODING を使う方法 (1) postmaster 起動時に環境変数を設定する方法 環境変数 PGCLIENTENCODING を設定することにより， postgresql.conf で エンコーディングを指定するのと同じ効果が得られます．ただし，これは歴 史的経緯から残されている機能で，今後はこの機能を利用しないことをおす すめします．設定例: export PGCLIENTENCODING=SJIS postmaster -S (2) クライアント，フロントエンド毎にエンコーディングを設定したい場合 そのフロントエンド(たとえば psql)を起動する前に環境変数 PGCLIENTENCODING を設定します． o set client_encoding コマンドを使う方法 SET CLIENT_ENCODING SQLコマンドを使って動的にフロントエンドのエンコー ディングを変更できます．例: SET CLIENT_ENCODING TO SJIS; ■現在設定されているフロントエンド側のエンコーディングを調べる 現在設定されているフロントエンド側のエンコーディングは show client_encoding; で参照できます(小文字で表示されます)． ■デフォルトのエンコーディングへの復帰 SQLコマンド: RESET CLIENT_ENCODING; は，デフォルトのフロントエンドエンコーディング設定に復帰させます． postmasterを立ち上げるときに postgresql.conf の client_encoding や環 境変数 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に変換して返します． 7.3ではさらにSQL標準のCONVERT関数が使えます．SQL標準のCONVERTは PostgreSQLのCONVERTと機能はほとんど同じですが，呼び出し形式が異りま す． SELECT convert(text using euc_jp_to_utf_8) FROM unicode_tbl; "using" の後の引数は「コンバージョン名」です．この例では，EUC_JP か ら UTF-8 に変換するコンバージョンを指定しています．定義済のコンバー ジョンについては，ユーザーズガイドの "String Functions and Operators" の表"Built-in Conversions" を見てください． ■エンコーディング変換不能の場合の処理 バックエンド側のエンコーディングとフロントエンド側のエンコーディング がいつも相互変換できるとは限りません．極端な話，バックエンド側が EUC_JP なのに，フロントエンド側が EUC_KR だったらどうなるでしょう． この場合 PostgreSQL は変換できないコードを 16進表現に変換します． たとえば，"(bdae)" のように．なお，この 16進表現は mule internal code のコードであることに注意して下さい．これは，直接フロン トエンド <--> バックエンドのエンコーディングを変換するのではなく，一 度内部表現である mule internal code を経由しているためです． なお，Unicodeとそれ以外のエンコーディングの変換だけは例外で，NOTICE メッセージが表示され，変換不能の文字は無視されます． ■デフォルトコンバージョン デフォルトコンバージョンは，バックエンドとフロントエンドとの間のエン コーディングの自動変換に使われる特別なコンバージョンです．デフォルト コンバージョンは各々の{スキーマ，ソースエンコーディング，デスティネー ションエンコーディング}の組み合わせにおいて，ただ一個だけ存在します． 上記で説明した組み込み済のコンバージョンは，pg_catalogスキーマにおい て定義されており，スキーマサーチパスの設定に関わらず必ず利用できるコ ンバージョンになっています． 逆に言うと， pg_catalog 以外のスキーマにデフォルトコンバージョンを作 成することにより，デフォルトコンバージョンを自由に選択することもでき るわけです．たとえば SJIS との変換において，PostgreSQL が用意してい る MS932互換 の変換ではなく，JIS 規格のシフトジスに相当する変換を行 うようなコンバージョンを作成することも可能です． ■ユーザ定義コンバージョンの作成 PostgreSQL 7.3以降，ユーザ定義のコンバージョンを作成できるようになっ ています．コンバージョンの定義は CREATE CONVERSION という SQL コマン ドを使って行います． CREATE [DEFAULT] CONVERSION conversion_name FOR source_encoding TO dest_encoding FROM funcname 詳細はリファレンスマニュアルをご覧下さい． ■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 区」の記述はここからきています． --- -------------------------- 引用ここまで --------------------------------- 改定履歴： 2002/10/21 * マルチバイト対応がオプションではなく，固定で必ず組み込まれる ようになりました． * CREATE CONVERSION/DROP CONVERSIONの追加．これにともない，エ ンコーディング変換関数がローダブル関数になり，バックエンドの ロードモジュールサイズが7.2よりも小さくなっています．また， SQL標準のCONVERT関数を追加しました． * いくつかエンコーディングが追加されています． * 以上，7.3に反映されます． 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 をリリース 以上．