[前][次][番号順一覧][スレッド一覧]

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>]