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

[Hiroki Kataoka]

片岡です。

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

　その通りだと思います。

　逆に、1つのカラムにいろんな国の文字を混ぜて格納するのであればクライア
ントエンコーディングも含めてUNICODEを使うはずです。この場合はエンコー
ディング変換はないですから言語ごとのユーザ定義文字がバッティングする心配
はありません。

　一方、あるときはUNICODE⇔SJIS、あるときはUNICODE⇔EUC_KR、などと各種エン
コーディング変換を同じカラムで使い分ける場合が考えられますが、この場合に
ユーザ定義文字領域が重なっていることがどんな問題を引き起こすでしょうか。
日本語のユーザ定義文字を格納したカラムは日本語のエンコーディングでしかア
クセスしないでしょうし、韓国語のユーザ定義文字を格納したカラムは韓国語の
エンコーディングでしかアクセスしないでしょうから、そもそもバッティングが
表面化することはないと思うのです。

　強いていうなら、言語ごとに各種エンコーディング変換を使い分けてデータ登
録したカラムをUNICODEのまま取り出して表示する場合でしょうか。バッティン
グしたユーザ定義文字に、どの言語のグリフを割り当てたらいいのかが問題にな
りますが、UNICODEのまま表示する場合があるのであれば、ユーザ定義文字のグ
リフの登録もUNICODE環境で行うはずで、そうなるとユーザは常に空いている
コードポイントを使うはずですから、そもそも問題にはならないと思うわけです。

　理想的には石井さんのおっしゃるとおりなのですが、現実的には問題にならな
いだろう、というのが私の意見です。安易に考えすぎでしょうか…

# ちなみに、Windows版PostgreSQLを使うのであれば、日本語だけの場合でも
SJIS/UNICODEを選びたくなります。Windows上でなんでEUC使うの？っていう疑問
が…^^;

> というわけであきらめモードなんですね:-)そうか，もともと6400文字しかな
> いUnicodeの私的利用領域C/J/Kでユーザ定義文字のために共有するのは無理な
> のかな?

　UNICODEには13万文字、2百万文字、5億文字の3つのユーザ定義文字領域がある
らしいです。が、既存の多くのソフトウェアが対応していない（パススルーでき
ない）ため、現実的にはまだまだ使えないようです。

> また，「4.1 Windows NT 拡張漢字処理仕様書についての検討」を見ると，
> 
> --------------------------------------------------------------------------
>     * 拡張されたユーザ定義文字のコードポイントが, Unicode のどの領域に
>       変換されるのか不明である.
> 
>     * このユーザ定義文字を利用するためにはユーザ定義文字サーバとの通信
>       が必要であるが, プロトコルが規定されていないため, UNIX からの接
>       続は困難である.
> 
> 以上の問題点から, 本 WG ではこの仕様について考慮しないこととする.
> --------------------------------------------------------------------------
> 
> となっています．つまり，Windowsで作った，ユーザ定義領域文字を含むデー
> タとの互換性は考慮していません．これでいいのかな?

　これはユーザ定義文字を32767×65536個に拡張した「Windows NT 拡張漢字処理
仕様書」の仕様についてです（相変わらずやることが極端なMS）。互換性を考慮
しないといっているのは、その巨大なユーザ定義文字領域のことです。今問題と
している1880文字のユーザ定義文字領域の話ではないです。

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

　それは確かにいえます。しかし無いんですよね。

# この手の話では重要なページさえ404 Not Foundになる始末ですし…

　ただ言えるのは、現在のWindows標準のSJIS⇔UNICODE変換は、UNICODEのユーザ
定義文字領域を言語ごとに使い分けていないということです。

-- 
Hiroki Kataoka <kataoka ＠ interwiz.jp>