はずかしながら、以前のコーディングではうまくできたのに今回希望の処理が全く出来なくなってしまいました。
もとのソースがなくなってしまったので、原因を知りたく思います。
(ちなみに、サーバはXREAのものを使っています。)
mysqlのDBをUNICODEで作成して、phpMyAdminからUTF8で開き、テーブルを作成、データを挿入しました。
(データには日本語の全角文字も含まれます。)
そしてphpからmysql_connect->mysql_select_db->mysql_query->mysql_fetch_assocの順に処理して読み取りました。
読み取った日本語の内容をprintfで表示すると、?(はてな)に化けてしまいました。
ブラウザのエンコーディングをSJIS,EUC,JIS,UTF8、どれで表示しても全く同じ?(はてな)です。
そこで、mb_detect_encodingを実施してエンコードを調べてみましたら、なんとASCIIで返ってきました。
UNICODEで作ったはずのDBなのに、なぜASCIIで読み取られてしまうのでしょうか?
ちなみに、PHPの設定は、
mbstring.http_input=auto
mbstring.http_output=pass
mbstring.internal_encoding=UTF-8
です。
UNICODEで作ったはずのDBなのに、なぜASCIIで読み取られてしまうのでしょうか?
DB設定自体が UTF-8 でもクライアント側の設定しだいで文字コード変換がかかります。
リンク先にあるように、phpMyAdmin と作成したプログラムの両方で
SHOW VARIABLES LIKE 'char%';
を実行してみてください。
おそらく片方、もしくは両方の character_set_client が latin1 などの日本語の使用できない文字コードになっているはずです。
character_set_client が UTF8 になっていないプログラムでは SQL 文の発行前に、
SET NAMES UTF8;
を実行する必要があります。
更に、php.ini の中で mbstring.internal_encoding は、 mbstring.language の後に置く必要があるそうですが、スクリプト内でセットする際も同じではなかったかなぁ...
この辺りは大丈夫ですよね?
なぜうまくいっていないかの答えではないですが、auto でエンコードの判別をしようとすると、UTF-8 の場合よく間違えるのではなかったでしたっけ?
ascii よりも先に UTF-8, EUC を持ってくると誤検知が減ったような...
仕様自体は至極まともなもの。
MySQL4.0 以前がさぼりすぎてただけだし、PostgreSQL も似たような機能をだいぶ前から実装してる。
デフォルトが latin1 なのとちゃんとした使い方をみんな知らないだけ。