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 <phd@sun.med.ru> 氏の
	  リクエスト及び協力により実現しました．これは，従来からある
	  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 <jonahkuo@mail.ttn.com.tw>)

  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" <hong@lunaris.hanmesoft.co.kr> さん提供)
	* 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 をリリース

以上．
