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

[Tatsuo Ishii]

石井です．

> 片岡です。
> 
> Morita Kazuro wrote:
> > PostgreSQLの SJIS-EUC の変換で、ドコモの特殊文字はいまのところ
> > うまく出来ているように見えます。
> 
> 　ドコモの絵文字はSJISの外字領域を使っています。PostgreSQLのSJIS⇔EUC_JP
> 変換は外字領域に対応していますので、相互の変換が可能です。ところが
> SJIS⇔UTF8変換は外字領域に対応していませんので、相互の変換ができません。

EUC_JP <-> UTF_8も対応していません．SJISとEUC_JPの外字領域はほぼ日本国
内で使うデータでしか使わないことが予想されるので，勝手に外字領域を使っ
ても問題ありませんが，UTF_8とというか，Unicode(ISO/IEC 10646, JIS X
0221)の外字領域はSJIS/EUC_JP以外のエンコーディングとの関係もあるので，
勝手には決められないような気がします．

> 　UTF8（というかUNICODE）にも外字領域がありますので、SJIS外字領域とUTF8
> の外字領域とを一対一に対応させる変換マップを追加してあげれば、PostgreSQL
> 上でSJIS⇔UTF8変換が可能になります。ただしUTF8の外字領域（6400文字以上）
> の方がSJISの外字領域（1880文字）よりもはるかに広いので、UTF8側は外字領域
> の先頭から1880文字のみをマッピング対象にします。
> 
> 　SJIS外字：F040〜F9FC 1880文字
> 　UTF8外字：E000〜E757 1880文字
> 
> 　さて、このマッピングならドコモの絵文字に限った話ではないので（外字利用
> 者全般の利便性につながるので）、PostgreSQLの変換テーブルに追加しても問題
> ないように思いますが、いかがでしょう？＞詳しい方

詳しくはないですが...

懸念点としては，

1) 外字領域のSJIS<->UCSの標準マッピングが存在するのであればそれを採用
   する方がよいのでは?

2) 上に書いたように，他の文字コードがUCSのE000〜E757を使うことも考慮す
   る必要があるのでは?

3) SJIS<->UTF8の外字領域マッピングを決めたら，EUC_JP<->UTF8のマッピン
   グも決める必要があるのでは?

4) 2)が決まったとして，たとえばUTF8->SJIS->EUC_JP->UTF8の変換を行って
   矛盾が出ないようにしなければならない

があります．これらがクリアできればよろしいかと思います．

もしこれらの問題が解決できない場合は，PostgreSQLの組込みデフォルト変換
テーブルには採用できませんが，CREATE CONVERSIONによる「ユーザ定義変換
テーブル」として作っていけば良いと思います．
--
Tatsuo Ishii
SRA OSS, Inc. Japan