関係 - お疲れモードmk2

後で投げるための下書き。

http://groups.yahoo.co.jp/group/Firebird-jp-general/message/1147

すでに一部の有志の方によってFirebird 1.0/1.5のSJIS<->UNICODE_FSS(UTF-8)のマッピング検証が行われており、NEC特殊漢字、IBM拡張漢字の取り扱いが正しくできないのが判明しています。

「正しくできない」と言うのは不正確ではないでしょうか。
「いわゆる機種依存文字が扱える」=「正しい」ことでは有りません。

* * *

[SJIS_0208←→UNICODE_FSS変換の必要性の問題]

そもそも根本的な問題として、変換する必要がありますか?必要のある人がどれだけ居ますか?というのが問題です。

クライアント側がUNOCODE_FSSで欲しい場合というのはかなり考えにくいのでクライアント側SJIS、DBがUNICODE_FSSと言う状況を想定していると思います。が、何のためにDBをUNICODE_FSSにする必要がありますか?

(a)「order byで並び替えるとき、文字をUnicode順に並べたい場合」
※コレーションオーダーとしてのUNICODE_FSSの利用
(b)「UNICODEにしか存在しない文字もDBに登録したい場合」
※キャラクターセットとしてのUNICODE_FSSの利用
程度しか思いつきません。

(a)Unicode順に並べたい、と言う要求が無いとは言い切れませんが、本当にそんな順に並べたい場合が果たしてあるかどうか、非常に疑問です。
(ちなみに仕事で扱ったことのある某O社のDWHソフトは、データをUnicode順に並べる仕様になっていて、お客さんから使いにくいと大評判です…。私も使いにくい。)

とりあえず(a)は個人的に無視しておくとして…

(b)UNICODEにしか存在しない文字を扱うなら、クライアントもUNICODE_FSSで要求しないと、どちらにせよ扱えません。「(機種依存文字を含む)Shift_JISの範囲内の文字をDBに登録する」のであれば、
クライアントもDBも SJIS_0208 でいいですし、UNICODE_FSSを使う意義が無いというか…

それ以前に、現状ではまずキャラクターセットの必要性すら理解され得ない状況です。(ドキュメントがほとんど無いから)。
まずサーバ・クライアントの環境、開発言語などにより適切なキャラクタセットを選択する必要があるのですが、「適切かどうか」を考えればクライアントとサーバで、SJIS_0208とUNICODE_FSSのように別にする事が「適切」な状態とは考えにくいです。

できれば「キャラクターセットはこう使う」と言う指針、環境ごとのケーススタディを作り、「この場合はどうしてもDBをUNICODE_FSS、クライアントをSJISにしなければならない」環境があるかを考えてみてはどうでしょうか。
私の想定では、そういう環境は非常に考えづらいです。

* * *

別にキャラクターセットの種類を増やすこと自体に反対はしませんが、とりあえずは現在のキャラクターセットの必要性が充分理解されていない状況、指針・ケーススタディが無い状態、と言うのをまず打破しないといけない気がします。
(十分理解されていない例：http://pc5.2ch.net/test/read.cgi/db/1057050009/314- )