mysql:63
From: <takeshi@xxxxxxxxxx>
Date: Wed, 25 Feb 1998 09:26:46 +0900
Subject: [mysql 63] Re: join and jp (Re: MySQL 3.21.24 released)
From: 民斗 <tommy@xxxxxxxxxx> Subject: [mysql 62] Re: join and jp (Re: MySQL 3.21.24 released) Date: Tue, 24 Feb 1998 13:01:03 +0900 Message-ID: <199802240359.MAA08412@xxxxxxxxxx> tommy> おそらく、内部コードというのはなくて、単にあるコードからあるコードへの tommy> 変換テーブルを持てばいいだけだと思います。 tommy> tommy> 例えば SJIS と EUC なら、SJIS→EUC, EUC→SJIS の変換テーブルを作って、 tommy> set option character set euc_sjis とした時に、そのテーブルを使用する tommy> ように書いておくだけでいい…と思います。 tommy> tommy> ただ、標準の convert.cc は1バイトコードのことしか考えられてないので、 tommy> 実際にはもうちょっと色々しないといけないと思います。 ありがとうございます。 なるほど、そう動いているんですね。 だんだん見えてきました。 もっと convert.cc まわりを追っ掛けてみます。 tommy> > そのフラグは、もしかして、<MYSQLDIR>/share/<language type>/ tommy> > に関係を持つのであれば、これまたメッセージまで ja_JP.{EUC,SJIS} 化 tommy> > が一気にできるのかな??と、連想しました。 tommy> tommy> 多分、サーバ−クライアント間の全てのテキスト文字について変換される tommy> のではないかと思うので、メッセージも大丈夫でしょう。 すばらしい。この方向(convert.cc)で SJIS 対応探っていきましょう # 誰に言っている? tommy> ところで、--with-charset= で指定する charset と、share/ の下のメッセージ tommy> ファイルとは直接は関係ないので、japanese/errmsg.txt を作ってしまえば、 tommy> (たとえ jeuc パッチをあてなくても)メッセージは日本語になるはずです。 あら、そうでしたか。ずっと charset に支配されるものだと思い込んでいました。 これまた不勉強が暴露されてしまいました。 ではしつれいします。 ========================================= 村上 毅 takeshi@xxxxxxxxxx
62 1998-02-24 13:01 [民斗 <tommy@xxxxxxxx] Re: join and jp (Re: MySQL 3.21.24 released) -> 63 1998-02-25 09:26 ┗[<takeshi@xxxxxxxxxx>]