[pgsql-jp: 37908] Re: EUC_JP を UTF8 に変換するには

2007年 1月 8日 (月) 21:09:36 JST

石井です．

> 片岡です。
> 
> Tatsuo Ishii wrote:
> > EUC_JP <-> UTF_8も対応していません．SJISとEUC_JPの外字領域はほぼ日本国
> > 内で使うデータでしか使わないことが予想されるので，勝手に外字領域を使っ
> > ても問題ありませんが，UTF_8とというか，Unicode(ISO/IEC 10646, JIS X
> > 0221)の外字領域はSJIS/EUC_JP以外のエンコーディングとの関係もあるので，
> > 勝手には決められないような気がします．
> 
> 　外字領域の使い方は利用者次第ですから、そこまで気を使う必要はないと思い
> ます。たとえば、ありえないですがSJIS→UNICODE→EUC_KRなどと変換した際に外
> 字が保存されていることにあまり意味がないように、外字に関して他のエンコー
> ディングとの関係を気にする必要はないと思います。

そうですか?そもそもいろんな国の文字を同じデータベースで使いたいから
Unicodeを使いたい，っていうことなのであって，そもそも日本語だけでよい
のならSJIS/EUC_JPだけで十分なわけですよ．

実際元記事の人も，

> いろいろな事情というのは、同じデータベースで他国語対応させ
> たいからです。ドコモの特殊文字を使うのはドコモの携帯だけな
> ので別のクライアントやブラウザを考慮する必要はないと思います。
> ドコモ以外の機種で日本語以外が入ったとき、UTF8 なら 
> PGCLIENTENCODING を変えるだけで済むのではないかと思った
> のですが。普通なら、そういう場合は別のデータベースを立てるの
> かもしれませんが、UTF8 なら１つのデータベースでできるのでは、
> と思ったのです。

と言ってます．

少なくとも，EUC-JP/EUC-KR/EUC-CN/EUC-TW(Big5)のユーザ定義文字領域(「外
字」っていう用語は不正確過ぎるので，「ユーザ定義文字」にしました)がお
互いに重なり合わない，というか潰しあわないようにすべきだと思います．
PostgreSQLは日本だけのものではないのですから，日本以外の国，せめて中韓
の事情くらいは考慮したいものです．

というわけで，あらためて下記URLの「3.4 日中韓のユーザ定義文字の共存に
ついて」を見てみると，

--------------------------------------------------------------------------
　まず考えられる方法は, PUA(UnicodeのPrivate Use Area:石井注) を各国ご
とに分割することである. しかし, PUA は 6400 文字に限られるし, 他国の標
準との関連や, 他のプラットフォームとの互換性の点から, 以下の問題点があ
る.
[中略]
　文字数の制限 (1) については, 3.2.3 の方法を使用することで解決できる
可能性がある. しかし, この方法でも依然として他の問題が残る. また, 他の
問題については, 他国や他の多くのベンダと協議をする必要があるため, 実現
はかなり困難であると思われる.

　したがって, 本 WG では日本における推奨のみを定めることとし, 各国のユー
ザ定義文字の共存は考えないものとする.
--------------------------------------------------------------------------

というわけであきらめモードなんですね:-)そうか，もともと6400文字しかな
いUnicodeの私的利用領域C/J/Kでユーザ定義文字のために共有するのは無理な
のかな?
# まったくなんのためのUnicodeなのか，気もしないのでもありませんが，これ
# に限らずUnocdeは出発時点から矛盾だらけで今さらいってもしょうがないか

また，「4.1 Windows NT 拡張漢字処理仕様書についての検討」を見ると，

--------------------------------------------------------------------------
    * 拡張されたユーザ定義文字のコードポイントが, Unicode のどの領域に
      変換されるのか不明である.

    * このユーザ定義文字を利用するためにはユーザ定義文字サーバとの通信
      が必要であるが, プロトコルが規定されていないため, UNIX からの接
      続は困難である.

以上の問題点から, 本 WG ではこの仕様について考慮しないこととする.
--------------------------------------------------------------------------

となっています．つまり，Windowsで作った，ユーザ定義領域文字を含むデー
タとの互換性は考慮していません．これでいいのかな?

この文書が書かれたのは1996年10月で，もう10年以上前の話です．私としては，
もう少しほかの情報というか，新しい情報も見てみたいです．

> > 懸念点としては，
> > 
> > 1) 外字領域のSJIS<->UCSの標準マッピングが存在するのであればそれを採用
> >    する方がよいのでは?
> 
> 　SJIS⇔EUC_JPと同様に、TOG/JVC CDE/Motif 技術検討 WG によるEUC⇔UNICODEの
> 案があります。すでにページがなくなっているようなのでarchive.orgの保管
> ページを紹介します。
> 
> http://web.archive.org/web/20060515012916/http://www.opengroup.or.jp/jvc/cde/ucs-conv.html
> 
> このページの中に次の記述があります。
> 
> 『マイクロソフト標準キャラクタセット仕様書で定義されている SJIS←→
> Unicode の外字マッピングテーブルでは, SJIS のコードポイント 0xF040 ～
> 0xF9FC (95区 ～ 114区) を Unicode の PUA 0xE000 ～ 0xE757 に割り付けてい
> る.』
> 
> この元の情報は見つけていないのですが、信用できる内容だと思います。
> 
> 　また、下記はドコモの絵文字の情報のページです。ここからたどれる絵文字一
> 覧ページには各絵文字のSJISとUNICODEのコードが記載されていますが、それを
> 見る限り変換規則は同じです。
> 
> http://www.nttdocomo.co.jp/service/imode/make/content/pictograph/about/e1.html
> 
> > 2) 上に書いたように，他の文字コードがUCSのE000～E757を使うことも考慮す
> >    る必要があるのでは?
> 
> 　これは先に書いたとおり、気にしなくていいと思っています。
> 
> > 3) SJIS<->UTF8の外字領域マッピングを決めたら，EUC_JP<->UTF8のマッピン
> >    グも決める必要があるのでは?
> 
> 　TOG/JVCの案でいいと思います。
> 
> > 4) 2)が決まったとして，たとえばUTF8->SJIS->EUC_JP->UTF8の変換を行って
> >    矛盾が出ないようにしなければならない
> 
> 　TOG/JVCの案では、外字領域に関しては矛盾無く相互変換が可能です。
> 
> > があります．これらがクリアできればよろしいかと思います．
> 
> 　というわけで、2）以外はクリアできると思います。
> 
> > もしこれらの問題が解決できない場合は，PostgreSQLの組込みデフォルト変換
> > テーブルには採用できませんが，CREATE CONVERSIONによる「ユーザ定義変換
> > テーブル」として作っていけば良いと思います．
> 
> 　いずれにしても、この件は需要が多いでしょうから、何らかの形で搭載したい
> です。
> 
> 　ちなみに、mapファイルのパッチはすぐに提供できます。:-)
> 
> -- 
> Hiroki Kataoka <kataoka ＠ interwiz.jp>
> 