河田です。

takeshi@xxxxxxxxxx writes:
 > 4.1.2 の問題なので、スレッド変えました。
 > 
 > TAKT Co.,ltd. wrote:
 > > データはそのままで、サーバ側プログラムのみのUPだったのですが、
 > > どうやら3.23.58で、char(8)などとしているカラムがあると、
 > > 4.1.1-alphaにUPすると
 > > 自動的にchar(2)に変換されてしまうようです。

同様の問題と思いますが、
4.1.1だと dump/restore する場合に外部参照
キーのvarchar(x)のxが勝手に変換されて解釈
されてしまい、restoreに失敗してお手上げ
状態でしたが、4.1.2 だと改善されているよ
うで、dump/restore が何の問題もなく、すん
なりうまく行くようになりました。

 > + 4.1 から、char() はバイト数ではなく、文字数に仕様変更された。
 > + EUC-JP は、最大で 1 日本語文字に 3 バイト使用する。
 > なので、 int(8 / 3) = 2
 > 
 > うーむ……

なので、3.23.xx から4.1.2へ移行する場合に
は、一度 dump/restore する必要があります
よね。

takeshi@xxxxxxxxxx writes:
 > mysqld サーバーの default-character-set は、Version 4.1.2 の場合、
 > 
 > CREATE TABLE ..... DEFAULT CHARSET=
 > に反映されるので、これは、テーブルのキャラクタセットと見ることができるとすると、

どうも、
CREATE DATABASE CHARACTER SET xxx

が一番強そうで、database に encoding を
きっちり指定するのが良いと思ってます。

 > ■2. 他のクライアントも問題
 > PHP は、mysql_option() 関数をコールしていないので、
 > default-character-set オプションが使えない。
 > # PHP の mysql モジュールのソースを変更すれば OK

多分、mysql_option ってlocalhostの my.cnf を
見に行くだけ? なので、他の remote ホストに
connect に行く時には期待できないでしょう。
アプリケーション的には、database の default
encoding をゲットして、SQL文で set character
してかかるのが良いのでしょうね。

 > ■3. どうすべき/どうあるべきか？
 > a. 自動変換はいるのか要らないのか

個人的には、なんだかとても便利な気がして
きました。うまく動いてくるなら database
は、utf-8 にしておけば encoding のことは
忘れられるのではないかと...

 > b. デフォルトで自動変換を ON にすべきか否か
 > c. mysql, myswldump 等のデフォルトの振る舞いをどうすべきか

mysql_connect to database で、
database の encoding が返ってくるなんて
のが良いような...

 > ■1. mysqldump の問題

mysqldump でフィールドだけ変換されて

) ENGINE=MyISAM DEFAULT CHARSET=xxx;

が、そのままなのはいかがなもんなのでしょ。

 --------------------NON-BREWED-CONDIMENT----
 FUJI PHOTO FILM Co.,Ltd.  Electronic Imaging
 Development Div.
 Yukihiro KAWADA