2008/8/25 月曜日

PHP5+MySQL5でのEUC-JP運用

Filed under: サイト関連 — mera @ 12:37:08

折角長文書いてたのにミスで全部消えた(´Д⊂
でも折角なので気を取り直して再び…うぅ…

事の発端は去年のサイト運営でCCFF7~年末のFF4などでのサイト来訪者のユーザー数増加に伴う負荷の増加。
phpの負荷や転送量が許容量を超えることもしばしばで帯域制限が多少入った結果最近掲示板がやや重いという結果をもたらしています。
そして現在EX-POTIONはXREA+サービスを利用していて、PHP4+MySQL4.1未満のサーバーで運用されています。
そのXREAですが、丁度1年ほど前にCORESERVERという上位サービスがスタートしています。
負荷上限などもXREA+よりも大きく、サーバー移転先などとして利用できるかな?というのもあり、お試し期間があるのでアカウントを取って運用できるか試用してみました。
しかし、去年の時点では上手く行きませんでした。
理由は文字化け。
通常ページの運用は問題ないのですが、データベースを活用する部分がどうしても上手く行かなかった。
DB作成画面でEUC-JPでデータベースを作成してもどうしてもEUC-JPでの運用が出来ない。
そもそもphpMyAdminの文字コード設定がJapaneseだけでutf-8しか選べない…。
ネットで情報を収集したモノの、その時点では打開策もなく、結局移転などは保留。
年末のFF4はex-potion.netドメインを活用した2鯖運用で無理矢理乗り切って今に至ります。

それから1年。
今年に入ってからは攻略自体はほとんどやらずサイトも保守管理+多少プログラミングした程度でしたが、時間がある今だからこそと再度PHP5+MySQL5でのEUC-JP運用に挑戦してみることにしました。
そしてこの2日でついに解決法が見つかりました。
この中で分かったことは大きく分けて3つ。

1.phpMyAdminのデフォルト設定が最近のバージョンなどではutf-8だけで、EUC-JPで利用するにはソース修正する必要がある
2.MySQL4.1以降で仕様変更により文字化け問題が発生しやすくなっている。理由は文字自動変換機能などで内部で変換がかかったりしている為
3.PHP4.2以降で仕様変更によりregister_globals = Offがデフォルトになり、urlでの変数渡しが直接的にできなくなっている

と言うわけで以下にこの3つの点についてちょっと書いておきます。

1つめのphpMyAdminについて。
別にコレを必ずしも使わなくてもいいんですが、内部的にちょっとデータ修正するときや、SQLクエリ発行など便利な点もあります。
で、コレの何が問題かというと、MySQLの仕様変更も関連するのでしょうがバージョン違いでphpMyAdmin自体も変更点がいくつかあるためです。
EX-POTIONのサーバーではphpMyAdminは2.6.4-pl3です。
MySQLも4.0.26で文字コード関連では特に問題なく使用できていました。
このバージョンでは基本的にphpMyAdmin自体の文字コード選択があるだけで、選択肢もちゃんとJapaneseで3つ(S-JIS、EUC-JP、utf-8)がありました。
しかし今回試しに使っているサーバー仕様ではPHP5、MySQL5.1.22-rc、phpMyAdmin2.10.1となっています。
ここではデフォルト設定ではphpMyAdmin自体の文字コードがJapaneseなんですが、1つしか無く、utf-8以外を選ぶことが出来ません。
更に、以前のバージョンでは無かったMySQL の接続照合順序という選択できるモノが増えています。
そこで、まずphpMyAdmin自体をEUC-JPで使うにはどうすればいいかと調べたところ、このような記事が見つかりました。

MySQL 4.1.x な環境で phpMyAdmin を EUC-JP で使う方法

どうやら./libraries/charset_conversion.lib.phpを読み込ませる必要があるようです。
このページを参考にしつつphpMyAdminのファイルを弄って見たところ、無事にphpMyAdmin自体の文字コード選択でJapanese3つを選べるようになりました。
と言うわけでコレでphpMyAdmin自体の文字コードはEUC-JPにすることが可能になりました。
じゃぁこの状態でEUC-JPのDBテーブルを挿入すれば行けるはず…と試してみたのですが…
それ以前で?????だらけでヒドイ状況だった文字化けよりはましになったものの、まだ半分程度文字化けしていました。
どうやらこれだけでは解決では無かったようです。

と言うことで2つ目のMySQL4.1以降の仕様変更に伴う話へ。
更に検索を進めたところこのようなページが見つかりました。
実際に参考にしたページは別だったかと思うのですが、ちょっとそのページ自体を失念してしまったので似たようなコトが分かる記事と言うことで…

MySQL 4.1 にて XOOPS 2.0.16a JP を動かす

どうやらMySQL4.1以降からデータベースへの入力において言語変換を行うようになったことが理由なようです。
それ以前はDB自体の文字コードを設定していれば問題なかったのですが、今のバージョンではクライアント、DB自体、テーブルなどとそれぞれ文字コートが変わってきたりします。
DB自体はEUC-JPだったりutf-8だったりと好きな文字コードで作成できるのですが、実際にDB自体に格納される時点では、EUC-JP→latin1に変換されているということらしいのです。
つまり入力やら出力やらは自分が決めた文字コードでやりとりできるのに、DBの内部で更に変換が行われていると言うこと。
ここの自動変換機能が悪さをしているようです。
どうやらその内部的なデフォルトの文字コードがlatin-1ということみたいです。
このページを参考にした訳じゃないのでここには載っていませんが、どうやらphpMyAdminにある「MySQL の接続照合順序」がここで重要になってくるようです。
当初は全部EUC-JPにしなければならないだろうと思っていたので、MySQL の接続照合順序も当然ujis-japanese-ciにしていました。(ujisがEUC-JPのコト)
しかし、上記の通り内部のデフォルトコードはlatin1と言うことで、MySQL の接続照合順序をlatin1_general_ciにしなければならないと言うことを見つけました。
そしてその設定にしてみると…無事にEUC-JPでテーブル挿入しても文字化けしない!!
こうしてphpMyAdmin、MySQLという両面についての設定などをすることでPHP5+MySQL5でのEUC-JP運用することに成功したのでした。

コレでようやくPHP5+MySQL5でのEUC-JP運用も完璧だなーと思いつつ、ちゃんとphpで作ったモノが動くかどうかしりとりで動作を試そうとしたところ…
エラーで投稿できない…
ちゃんと文字記入しているのに、一言欄が空欄だと怒られました。
その日の時点ではその理由は分からず、この問題は翌日に持ち越しとなったのでした。
そして翌日。
しりとりの表示自体は上手く行っているので問題点が何処にあるか調べるために交流コンテンツじゃないデータ関連のページで試してみることにしました。
データ関連の場合、urlに変数を渡してカテゴリ別の単独表示などをさせているのでコレがちゃんと動くかな、と。
結果は×。
デフォルト状態の全表示は上手くいくのに、個別表示が上手く行かない。
url上では変数は渡されているはずなのにその結果が付いてきていない…
そこで、コレはもしかしてurlでの変数引き渡しが出来てないだけではと思い試してみると、案の定その通りでした。
urlに入力して渡したつもりがphp上では変数が認識されていませんでした。
いろいろと調べたトコロ結果が判明。
Register_global = Offがphp4.2以降でデフォルトになった結果、urlから変数をGET送信する場合、直接変数として受け取れなくなっていた為でした。
じゃぁコレをOnにするにはどうしたらいいんだろう、とまず調べていたんですが、php自体の設定は共有サーバーの場合は基本弄ることはできず、CGI版PHPとして認識させた上で設定ファイルを弄るぐらいしか無いと言うことが判明。
phpをCGIとして動かすんじゃphpの意味が無いじゃん…ということで更に調べを進めることに。
よくよく調べていくと、なぜRegister_global = Offがデフォルトになったのかというとセキュリティ面を考えてのことだったようです。
Onの場合はurlから変数を何でも送り込むことが出来る=外部からphpアプリを操作されたりする危険性が高い、ということですね。
使われそうな変数などをurlにぶち込んで本来想定されない操作を外部から行ったりして内部の情報を得たりすることができたり、ということ。
ここでRegister_global がOnの場合とOffの場合の違いを調べてみるとコレは簡単なことでした。
Onだと、urlに~~.php?oo=xx と入れれば、php内部で $oo=xx と変数を認識させることが出来ます。
非常に簡単です。
それに対してOffの場合はどうかというと、urlに~~.php?oo=xx と入れることはphpに対して $_GET[‘oo’]=xx という情報を与えることになります。
コレがフォームなどからの送信でPOST送信なら同様に$_POST[‘oo’]ですね。
coockieも同様な形式でした。
コレの利点は、内部で$_GET[”]を用意していない限り、urlに変数を突っ込まれてもphpとして変数を認識できないので危険性が大分減ると言うことなんですよね。
php6ではRegister_global の設定自体が無くなり、offが完全デフォルトになるようです。
Webプログラミングで危険性の回避は必至な事項ですし、コレはきっちりOffに対策すべきでした。
と言うわけでソースの変数部分を改変して無事にしりとりやDB連携データページの表示も成功。
ここまでの3つの課程を経てようやく無事にPHP5+MySQL5でのEUC-JP運用が完成したのでした。
ただ、しりとりはともかく掲示板の方はファイル数自体も多く修正には手こずりました。
こういった情報はもっと早い時期から知っておくべきでしたね…
いつまでもphp4相当でやるにはいかないということですね。

今回の点をまとめると、
1.phpMyAdminをutf-8以外で使いたいなら、ソース改変して選べるようにすること。
2.MySQL4.1以降では内部文字コードの自動変換などがあり、基本はデフォルトlatin1であることが多いため、MySQL の接続照合順序をlatin1_general_ciにすること。
3.PHP4.2以降ではRegister_global = Offがデフォルトになっているため、フォーム等で変数を送る場合は$_GET[”]や$_POST[”]で受け取るようなプログラミングをすること。
大体こんなところですね。
基本独学でまだまだ知らないことも多いので、これからもまだまだ新たな発見などが出てきそうです。
まぁ、何かやるたびに新しい知識・スキルが身についていくのは嬉しいことなんですけどね。

そんなところで滅多にない番外編でした、と。
次回は未定です。
というか、そもそも人に見せる目的じゃないからこういう記事自体滅多に書かn(ry

コメントはまだありません

コメントはまだありません。

この投稿へのコメントの RSS フィード

現在、コメントフォームは閉鎖中です。

HTML convert time: 0.330 sec. Powered by WordPress ME