@ゆたか ちひろ さん
報告ありがとうございます。
私が実験したのと同じ事態が現れているとすると、WordPress の不具合となりそうです。開発者にはまだ伝わっていません。似たような例は報告されていますが、別の問題です。このまま放置すると、ずっと直らないままになってしまうので、次回リリースで修正されるように何とかリポートを出そうと思いますが、まだコードを読み切れていないのと、他の要素がからんでいる可能性を排除できないので、少し時間がかかるかもしれません。また、上の修正が最終的な解決方法というわけではないことも、ご承知願います。どちらかというと、弥縫策に近いです。また、別の不具合が生じていないかどうか、教えていただければ、助かります。
原因は、MySQL のサーバ文字コードと、データベース、テーブル、カラムの文字コードの違いが開発者にわかっていない、もしくは、勘違いしている、あるいは、想定から抜けている、といったところです。これらを同一視した結果、プログラムの中で混同が生じています。
以下、不安が解消されるかどうかはわかりませんが、状況を説明しておきます。
データベースが ujis (EUC-JP) になっているサイトがどのくらいあるかわかりませんが、WordPress の必要要件を考えると、そういうサイトでも、サーバとの通信には utf8 (UTF-8) を使っているはずです。OS の環境が UTF-8 になってしまっているということもあります。一方、古くから WordPress で運用しているサイトなら、これも高い確率で、EUC-JP のテーブルを使っているはずです。このとき、EUC-JP で表現できない文字が含まれていないなら、何もせずに UTF-8 で通信すれば、MySQL が内部で変換をしてくれます。
これは、「文字コードの混在」ではありませんし、MySQL にとっても別に異常な事態でもありません。こういう風にして使えるデータベースなのです。wp-db.php の今回の変更は、テーブルの文字コードで許容できない文字をあらかじめチェックしようというものです。文字コードの違いを利用した SQL インジェクションを予防するという目的もあるかもしれません (コア開発者の議論が読めないので想像です)。
EUC-JP テーブルを持った MySQL と WordPress との通信は、おおよそ下のようになっています。
+-------+ +-----------------+ +-------------+
| table | <- ujis -> | Database engine | <- utf8 -> | PHP library |
+-------+ +-----------------+ +-------------+
^ ^ ^
| | |
+------ MySQL ------------+ WordPress
断言はできませんが、不具合は、テーブルの文字コードが ujis なら、WordPress と Database engine との通信も ujis のはずと決めてかかっていることからくるようです。ユーザにとっても内部の状況が掴みにくい状況であることは確かです。MySQL の文字コードを聞かれたときに、普通に外から見たら、utf8 と答えるでしょう。また、そう考えていて、問題はありません。通常ならば、と付け加えなければなりませんが。
あらためて述べると、「データベースの文字コード」と言ったときには、phpMyAdmin が使えるなら、データベースやテーブルをクリックして、そこに表示されているものを見る必要があります。wp-config.php の DB_CHARSET は、utf8 で問題ありません。ですが、これは「データベースの文字コード」ではありません。
さて、この状況でデータベースを utf8 に変換する必要があるかどうか、ですが、個人的な見解では、よくわからない場合には必要がない、と思っています。特に、現状の運用で問題がないなら、なおさらです。変換は、SQL 文を発行することでできますし、ujis から utf8 の変換は、その逆に比べれば容易ともいえますが、環境も調べず、バックアップも取らず、むやみに実行されても困るので、ここに書くのは控えます。ただ、変換することは、いつでもできると思ってもらってかまいません。
EUC-JP は、文字データを1バイトと2バイトで表現しますが、UTF-8 は、規格上では1～6バイト、現実には1～4バイトで表現します。4バイト文字は、今回のアップデートで WordPress にコードが追加されましたが、MySQL 5.5.3 以降でしか扱えません。PHP の正規表現で扱えない文字を判定するというところが、ちょっと危うい感じはしますが、とにかく、そうなっています。ご存知かもしれませんが、扱える文字の範囲は、
EUC-JP < UTF-8
となります。EUC-JP では扱えない文字が UTF-8 には大量に存在するわけですね。上の条件で、もし、EUC-JP で扱えない文字が MySQL に渡ったら、どうなるでしょうか? MySQL は、エラーを返しません。変換できない文字を ? に変えて、テーブルに保存します。変換できない文字が飛んでくるたびにエラーになったり、止まったりしていてはサーバとしての役割が果たせませんから、当然の仕様です。
EUC-JP で運用している WordPress サイトでこれがあまり問題にならないのは、たぶん、日本語しか入力されていないからです。通常使う現代日本語なら、EUC-JP で充分にカバーできてしまうのです。半角カタカナでさえ扱えます。広東語の「粵語」は「?語」となりますが、中文の「你好」やドイツ語の “Die fröhliche Wissenschaft” くらいなら、正しい文字が入力されます。
これで、問題になるのは、EUC-JP で表現できない文字が、入力に含まれる場合ということになります。どうしても、UTF-8 でしか表現できない文字を使いたい、たとえば、4バイト文字の絵文字をそのまま保存したい、というような場合は、当然ですが、データベースの変換が必要になります。そうではなくて、現状で満足ならば、無理をする必要はないと思うわけです。それよりは、バックアップをこまめにとることの方が重要だと思います (ダンプデータは UTF-8 で保存されます)。
また、データベースの変換を勧めたくない理由は、他にもあります。
別の問題で、バグリポートを処理した pento さんが、もう utf8 だけをサポートすればいいのではないか、と言われたときに、こう述べています。
utf8 が最良の解決策であることは認める (実際、WordPress サイトの大多数は utf8 を使っている) けれども、後方互換性を破壊して、それを使うように強いることは断じてありえない。何年も前に作られた多くのサイトがあって、それらは MySQL のユニコードサポートが不十分だったときに作られたものだ。WordPress をアップグレードするために、それら全てのサイトの文字コードを強制的に変更させることが、われわれの選択肢になることはない。
nacin さんをはじめ、WordPress の開発者たちは、ことあるごとに、この「後方互換性 (backward compatibility)」といいます。あるいは、「現在稼働している WordPress のインストールを破壊しない変更しか許さない」とも言って、PHP 5.2.4 をサポートするために、ある意味、プログラムのスピードアップも、コードの可読性をも犠牲にして、既存のサイトを守ろうとします。反対意見もたくさんありますが、彼らは、WordPress が新たな技術を試すための場ではない、ということを肝に銘じているようです。
私自身は、そういう開発者たちの姿勢を信頼していますし、Philosophy (心打たれる文章ですが、日本語訳がありません) に書かれた原則に則って行動しているとも思います。頑固さに辟易することもありますが、それだけに、現行のサイトが影響を受けるときには、互換性を維持しつつ、ゆるやかに時間をかけて移行するはずだと思っています。
だから、公式に utf8 以外のテーブルをサポートしないとアナウンスがあるまでは、ユーザにデータベースの変換をするように勧めたくはありません。ただ、変換をしたいというユーザを止めるつもりもありません。
もし、ゆたか ちひろ さんが、utf8 に変換したいということでしたら、あらためて、トピックを立て直してください。データベースの詳細がわかれば、協力できるかもしれません。あるいは、できないかもしれません。個々のケースによって、違いますから、一般的な解決策などというものはないと思ってください。
