村上です。

At Tue, 22 Jun 2004 00:36:44 +0900,
HIROSE, Masaaki wrote:

> A sjis の database を mysqldump でダンプして、mysqld
>   --default-character-set=utf8 なサーバーにレストアした。database の文
>   字コードが sjis になっているつもりで、文字コード指定を省略して
>   CREATE TABLE したら table の文字コードが sjis ではなく、utf8 になっ
>   てしまった。[8]
>   → 無用なトラブルを回避するために、4.1 での CREATE TABLE には
>      DEFAULT CHARSET をつけるようにした方がいい?

dump と default-character-set が違う場合の他の対策は、
CREATE DATABASE ... DEFAULT CHARACTER SET sjis としたデータベースを作ってそこに流し込む
ぐらいですかねぇ、思いつくのは


> B database mysql と test には db.opt がないので、これらの database で
>   DEFAULT CHARSET なしで CREATE TABLE した場合の table の文字コードは
>   変数 character_set_database の値によって恣意的に決定されてしまう。
>   [6,9]
>   → character_set_database を変えたりしない、mysql の table に入れるデー
>      タは専ら us-ascii だけ、test はあくまでテスト用の database である、
>      という理由で、実際に問題になる局面は少ないかも?

> C db.opt がない database で DEFAULT CHARSET を省略した CREATE TABLE で
>   作った table の文字コードは、SHOW CREATE DATABASE で表示される
>   database の文字コードと異なる場合がある。[5,9]
>   → 無用なトラブルを回避するために、4.1 での CREATE TABLE には
>      DEFAULT CHARSET をつけるようにした方がいい?

想像ができなかったので、現象が起きる例をみせていただくと
ありがたいです

> 結局、
> db.opt がある/ないに関わらず、database の文字コードには依存しないよう
> に、CREATE TABLE には DEFAULT CHARSET をつけるようにする、というのが安
> 全ということでしょうかね。

3.X, 4.0 と同様に、
サーバー、クライアントは同じ character set を使うようにして
運用するのがトラブルが少ないかと。扱う文字コードも固定。
色々なcharacter setを使ったり、文字コードの変換を使うのは
特別な場合に限るような運用の方が、トラブルや現アプリの移行の
手間は少ないでしょうねぇ。

これに加えて client が binary で接続すれば、さらにトラブルは
減るでしょう。


それと
"character_set_* 変数をいじらないといけないの？面倒だね"
というように思ってしまう人が もし出てきてしまったら嫌なので
言いますが、
character_set_* 変数は --default-character-set や
SET [CHARACTER|NAMES]文によりセットされるので、
character_set_* 変数は、通常は忘れます。私は忘れています。それで良し.
トラブルの時にだけ、character_set* 変数を見るだけです。
サーバー、クライアントの --default-character-set だけを
使う運用(SET文も使わない)が単純。

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