From: 民斗 <tommy@xxxxxxxxxx>
Subject: [mysql 60] Re: join and jp (Re: MySQL 3.21.24 released)
Date: Tue, 24 Feb 1998 11:40:46 +0900
Message-ID: <199802240239.LAA05690@xxxxxxxxxx>

tommy> [Subject: [mysql 59] Re: join and jp (Re: MySQL 3.21.24 released)]
tommy> [Date: Tue, 24 Feb 1998 10:10:35 +0900  From:民斗]
tommy> 
tommy> > > 1.は mysys/,client/ あたりに コード変換突っ込めないかなと思っています
tommy> 
tommy> > どの辺に埋め込んだらいいのかはわかりませんが、コード変換方式にすると、
tommy> > UNIX と Win の両方のクライアントから同じデータベースが見れるという
tommy> > メリットがありますね。

それを狙っています。
また、libmysqlclient.{a,so} が client/ のソースから生成されるので、
クライアント側にも lib が変わることにより漢字変換が組み込まれるというのも
狙ってます。

実現可能かどうかが今一踏み込めていません。
この考えが良いか、無理があるか、、、、。


tommy> ふと思ったんですが、もしかしたら SET OPTION CHARACTER SET 命令と
tommy> いうのはこういう目的のためにあるんじゃないでしょうか。
tommy> 
tommy> これが使えるなら、実装はわりと楽かもしれません。sql/convert.cc を
tommy> 変更するだけですむので。
tommy> 

ありがとうございます。

sql/convert.cc を覗いてみました。
何の文字なのかわからないですが、とにかく変換テーブルを用意して
比較とかに 対応させているのかなー、と予想しました。
となれば、sjis<->euc のコードをいれて、フラグで対応させると。
内部は jeuc で決めておいて、外からの入力に対して jeuc 変換をかける。
(ここが不明。convert.cc を使用する場合、内部コードはどうなっているのでしょう？)

そのフラグは、もしかして、<MYSQLDIR>/share/<language type>/
に関係を持つのであれば、これまたメッセージまで ja_JP.{EUC,SJIS} 化
が一気にできるのかな？？と、連想しました。

あってますか？この考え？

=========================================
        村上 毅  takeshi@xxxxxxxxxx