http://www.klab.jp/media/mysql/index6.html
この辺に綺麗に情報が集まっていますね。
今までよく検証したことがなかったのですが、 set names ではクライアント側となるphpの認識が変わらないので本件では意味が無いのかもしれません(要確認)。
my.cnf を触れる&システム全体で文字コードを統一して良い環境ならば、my.cnf に
コード: 全て選択
[client]
default-character-set=utf8
で問題を回避できる(要確認)。
コード: 全て選択
[mysqld]
default-character-set=utf8
skip-character-set-client-handshake
は今では推奨されないようですが、問題になるのはutf8以外の環境のみでしょうかね。。。今まではこれで回避していました。
my.cnfを触れず、上記の設定もされていない場合、
php5.2.3以降ならばmysql_set_charset を指定する(現1.0.5Jのように関数が存在すればconnect時に指定する形で良さそうですね)。逆にmysql_set_charset が使えればmy.cnf側の設定がいらない訳ですが。
mysql_set_charset を使用できない場合はどうすべきか。。。
mysql_set_charset を使用できない場合でも、my.cnfが触れるならば問題を回避できるので、eucjp-win変換はして欲しくない。
この判定をどうするか。。。どのようにして対処するか。
という流れでしょうか。
(connect時にmysql_set_charset を使用する部分を加えるだけの前提で)
- ・インストール時にまずはmysql_set_charset が通るならばオリジナルのままにする。
・通らない場合は、状況の確認を行う(テーブルへの書き込み&確認)
・問題ないようならばオリジナルのままにする。
・問題がある場合、置き換えファイルで置き換える。置き換えのためには事前にパーミッションの確認も必要ですね。。
置き換えの場合は、本家からも期待されているとなると日本語だけの対応では駄目なので、今の方法と別の解決方法を考える必要があるでしょうね。
または、言語別に対応を用意するのか(この場合、ここに落ちると各言語範囲しか使用できないということになりそうですが)・・・
php公式マニュアルの mysql_real_escape_string のコメントにある
コード: 全て選択
function mysql_escape_mimic($inp) {
if(is_array($inp))
return array_map(__METHOD__, $inp);
if(!empty($inp) && is_string($inp)) {
return str_replace(array('\\', "\0", "\n", "\r", "'", '"', "\x1a"), array('\\\\', '\\0', '\\n', '\\r', "\\'", '\\"', '\\Z'), $inp);
}
return $inp;
}
上記のような代用コードを使用したファイルに置き換える(上記コードの妥当性は確認していません)。でも、これをデフォルトとはせず、基本は素直に mysql_real_escape_string を使用して、可能ならば mysql_set_charset を使用するコードをデフォルトとするのが良いと思います。
----------------------------
1.0.4-r5以降からの新規インストールならば「日本語しか入らないんだ。」という認識もあり得ると思うのですが、どうにも気になるのは、アップグレードだった場合、今まで問題がなかった環境においても、ページの再保存時などに触っていないはずの入力済みのデータが抜け落ちる可能性が出てきた点です。
対応はしたほうがいいと思いますが、日本語版が特定の環境(PHP5.1.6以下)で中国語や機種依存文字が使えないのはいわゆる「事故」に相当するほどの問題ではないと認識しています。エスケープまわりは失敗すると大事なデータが消えて大変なことになるので、今は安定しているので逃げておきたいなというのもちょっと本音としてはあるのですが・・解決できれば解決したいので、もしよければお願いします。このへんの解決は本家開発チームからも期待されています。
とあったのですが、現状は前述のようなケースで逆に大事なデータが消えて大変なことになる可能性の方が大きい気がしています(特に1.0.4-r5以前からのユーザ)。
よく問題になる「~」の件とかは大丈夫なようですが(sambaの件が参考になりますかね
http://www2d.biglobe.ne.jp/~msyk/charco ... JP-ms.html )、日本語版が(環境にもよるわけですが)「本当に日本語しか使用できない」バージョンだと考えているユーザは少数で、「いざとなれば中国語はもとより、タイ語でもベトナム語でも入力できますよ」と思っているユーザの方が多いのではないでしょうか。そうなると今は良くても後々問題になるケースもあり得ますし、何より現状は問題が発覚しづらいのも気になります。
二重エスケープが発生すれば直ぐに気づきそうですが、偶々入力したeucjp-win範囲に無い文字が落ちるなどは見た目気づきづらいのではないでしょうか?
少し古いCentOSだと、日本語環境というとeuc-jp(ujis)基準でデフォルト値が提供されていたりしないでしょうか。
mysqlやphpの関係で、MODxをRHEL系列で使おうと思えば、基本的にはRHEL4相当以降になると思いますが、RHEL4以降はOSとしてはutf8が基本だと思います。付属のlibmysqlclientがlatin1でコンパイルされているのがネックになるわけですが。
逆に今でもeuc-jp(ujis)が基本のサーバは最近見ない、というかMODx含めUTF8が基本になってきたCMSなどを使う場合、このようなサーバは出来るだけ避けているから、かもしれませんね。。。そういうユーザの方が多いと思っていましたが。。。他のユーザのご意見もないと何とも言えませんね。