玉川です。

ちょっと間が開いてしまいましたが、MySQLに対して行った、以下のリクエストの
状況について中間報告をするのと同時に、MySQL側からの回答に対する
皆さんのご意見をお聞きしたいと思います。

（関連スレッド: http://www.mysql.gr.jp/mysqlml/mysql/msg/12372）

> a) 文字コードの自動変換に伴う文字化けへの対応（libmysqlclientの機能強化）

libmysqlclientで環境変数を読みこませるということについては、受け入れられていません。
「4.0と同様の振舞いをする--skip-character-set-handshakeオプションでは
なぜ不十分なのか」、「あると便利というレベルではなく、どうしても必要な機能なのか」
という点で説得材料が不足しているという状況です。

Q. 環境変数を読み込ませる必要性は本当にあるのでしょうか？

また、バイナリ版のデフォルトキャラクターセットをlatin1からutf8に変更する
という点については、「日本人以外のユーザーも影響を受ける」ということから
受け入れられていません。これについては、utf8でコンパイルされたバイナリを
既存の物に加えて別途用意し、「International Version」として提供してはどうか
という案を提示しています。

> b) JISコード範囲外の文字の処理

コード範囲外の文字の処理については、「スキップするかもしくは他の文字に
置き換えて処理を続行する」という案が、コード範囲外の文字がどれだけの
長さであるかが判別できないという理由で、受け入れられていません。

Q. この問題はそもそも、以前はなかったコード範囲のチェックが4.1以降で
導入されていることに起因しているため、以下のようなリクエストにするのが
妥当なところでしょうか？

「4.0の時と同様にコード範囲のチェックを行わないようにする」、もしくは
「コード範囲外の文字が含まれている場合には、エラー返す」

> c) Unicodeコンソーシアムのルールに基づいたsjis/ujisの変換ルール修正
> d) Unicode -> JIS系文字コードへの変換

これら2点については、MySQL内部にて現在協議中とのことです。

> e) sjisバイナリーデータのエスケープ処理
（バグとして報告: http://bugs.mysql.com/bug.php?id=15678）

この点につきましては、バイナリーデータを挿入する際にはmysql_escape_string()
を使用し、0x形式で挿入してはどうかとのことです。

なお、「クライアントのキャラクターセットがsjis/cp932であったとしても、
BLOB型のカラムにデータを挿入する場合には、エスケープ解除処理を行う」
という対処方法は「エスケープ解除処理が行われるのがパーサーレベルであり、
その時点ではデータがどのカラムに挿入されるか分からない」という理由で
受け入れられていません。

代替案として次の2点が挙げられています。

1. 新しくデータタイプ・イントロデューサーを追加し、データタイプに応じて
エスケープ解除処理を変える。

INSERT INTO t1 VALUES (C'escaped string');
INSERT INTO t1 VALUES (Z'escaped blob');

2. キャラクターセット・イントロデューサーに応じて、エスケープ解除処理を
変えるよう、パーサーを変更する。

INSERT INTO t1 VALUES (_sjis'escaped string');
INSERT INTO t1 VALUES (_binary'escaped blob');

Q. mysql_escape_string()を使用する方法と上記の代替案ではどれが
最も望ましいでしょうか？

> その他の点については「このような声もある」という形で報告致します。

その他については、以下の2点のみ、現時点で受け入れられています。

> * キャラクタセット名のエイリアスを使えるようにして欲しい
> * 自動変換を停止するセッション変数を追加して欲しい

Q. 自動変換を停止する組み合わせはsjis<->cp932,  ujis<->eucjpms以外に
sjis<->ujis, cp932<->eucjpmsについても必要でしょうか？

Q.の部分については、皆さんのご意見を頂ければと思います。

以上、中間報告でした。　

--
Shuichi Tamagawa
tamagawa@xxxxxxxxxx