PHP5に再挑戦してみる。PCについてはインストーラで簡単にインストールできるのでここでは書かないけど。自動でスワップ領域の大きさを調べておき、スワップ領域とルートのみにしておいた。apacheをパッケージインストール???時間短縮でapacheをパッケージインストールしようとしたら・・・無いじゃん。CDとりあえず必要なものをパッケージインストールapacheはあきらめて、他に必要っぽいものをパッケージインストール。インストールするつもりだった。SC430の時のスクリプトを利用してコンパイル。SC430の時のスクリプトを利用してコンパイル。MySQLは指定だけしてみる。php.build.shconfigureエラーやはりMySQLは外部のクライアントライブラリがないと駄目みたい。・・・ん?そういえばインストーラCDのパッケージ集にクライアントが無かったか?ところで、configureって「コンフィギャ」?「コンフィギュア」?。MySQLのマニュアルでは「コンフィギャ」って訳されていたけど。パッケージ追加ありました、ありました!mysql-client-5.0.27.tbz。distcleanをしてからインストール再実行。今度はコンパイルエラーあいやー、「メモリが足んねぇぞゴルァ!」というエラーでコンパイル中止。しまった、32Mじゃ足りないか。振り出しに戻り、仮想マシンのメモリは64M、FreeBSDをスワップ領域512Mとルートのみで最小インストールからやり直し。(泣)make直後の不思議なメッセージやっとでPHPインストール終了まで戻ってきた。仮想マシンは非力だからコンパイルに2時間程度待つのよね。test'.ん?なんだこれ。test’の実行を忘れるなよ」・・・こんなメッセージ&makeオプションあったっけ?・・・とりあえずそれは後にしてWeb動作テストしてみる。・・・orzやっぱりうまくいかない。スクリプトを全てUTF-8にて保存し、php.iniを設定し直してあるのだが。none当然、php.iniファイルを変更したらapacheを再起動する。パスは通しておいたし。文字化け」で調べても、大概はスクリプトファイルの保存エンコーディングとエンコーディング設定の食い違いによって表示が文字化けする場合の情報だ。目の前の状況はというと、表示はうまくいっているのだがフォームからの入力(HTTPクエリ)が文字化けするのである。CPUの使用率が異常になるのは明らかに他の場合とは違うようだ。・・・ということは、設定が原因ではなくてやはりコンパイルされたバイナリがおかしい状況なのかもしれない。思った時、あのコマンドを思い出したので試してみる。testの罠あれ?またコンパイルが始まった・・・。cleanをやった後だったので(コンパイルスクリプトを参照)、またコンパイルから始まってしまうのか・・・。2時間待たされることに。(泣)散々な結果3000弱ぐらいのテストで1時間ほどかかりました。こんなにたくさんテスト項目があったとは・・・。それはさておき、失敗「FAIL」の割合が10%近く・・・いいのか?!コレ。普段使いそうな関数でも失敗しているみたいだし。試しにWeb動作テストしてみたらやっぱりおかしいまま。するとひょっとするとコンパイラオプションで最適化しすぎなのかな?やりすぎると実行時に不具合が出ることがあるってどっかで聞いたことあるし・・・。思って-O3を-O2にしてコンパイルし直してみる。cleanをコメントアウトして。ハッハッハッハ、さっっぱりわからない。学それでもWeb動作テストの結果は同じ。testの結果は成功「PASS」の割合が99%まで上がった。最適化オプションが原因なのかphp.iniを一旦消したのが原因なのかよくわからなくなってしまったのだが、まぁいいや後にしよ(お)。現象には必ず理由がある。学そういえばXREAはPHP5なのにこんな現象起きていないんだよなぁ・・・。いうことは設定ファイルをもう一度見直してみる必要が出てきた。自分の頭の中だけでは固定観念があるかもしれないので、XREAのphpinfo()結果とにらめっこしながら、関連部分の設定をそのまま写してみる。写してみたものの、Web動作は全く変わらない。一度設定ファイルをにらめっこする。タブが含まれていたのでスペースに置き換えてみたり、全角スペースがないか探してみたりもした。phpinfo()や非マルチバイトなスクリプトだけは動作するので、XREAのものと比べてみたりもした。コンパイルオプションには--enable-i18n--with-gettext=/path/--with-iconv=/path/なんてのもあったが、やっぱり変化無し。んぉ?phpinfo()結果をよーく見比べてみたら。Onなんだコレ?見たことないやつだな・・・と思って調べてみた。マニュアルに載っていないし、php.ini-reccomendやphp.ini-distにも記述されていない!。試しに明示的に解除してみた。Off!!!あっ!・・・できた。CPU喰いまくっていたテストスクリプトはすぐに反応が返ってきて、フォームからの入力も正常に反映されているようだ。本番と同じスクリプトを動作してみても、今までの不具合が何事もなかったように動作している。若干フォントやレイアウトが崩れているのが気になったが、これはUTF-8に揃えた時にスタイルシート等のエンコーディングに間違いがあるからだろう。detect_unicode」で調べてみたが、MLで別の事例で取り上げられているぐらいで、今回の事例は一般的でないかもしれない。apache2のビルドや設定も関連しているかもしれないが、調査するにはもっと時間がかかるだろう。あらっ?!・・・と思ったのもつかの間。detect_unicode以外の指定をシフトJIS向けに戻してみたら・・・やっぱり異常動作になってしまった。どっかで見たけど、自動変換をあてにしないほうがいいのかもしれない・・・。(泣)ていうか、まさかapache2だからか?・・・なんて思考さえ出てくる始末だ。振り出しに戻ってしまった。忘れた頃に?ふと思い出したので再々チャレンジしてみる。目的のPHP・HTML・CSS・JSをUTF-8にし直してみる。php.iniも設定しなおす。On・・・ぁ、でた一応、文字化けしないで表示はされている。Firefoxだどいいんだけど、InternetExplorerだとフォントが得体の知れない設定になっているようで、日本語は日本語フォントに、英数字は欧文フォントになっているのよね。スタイルシートで設定してみたが、あまり気持ちの良いものではない。甘くは無かったしかし、データを入力してみると、返ってきたのはやっぱり文字化け・・・というか、変換に失敗して数値表示になっている(前述のphp.iniの設定参照)。PHPからの出力がおかしいわけではないようだ。テスト1・UTF-8UTF-8でテストスクリプト・・・フォームからPOSTで受け取り、ファイルに保存、ファイルから読み直して表示するスクリプトを動かしてみる。表示も入力も問題ない。テスト2・Shift_JISシフトJISでテストスクリプトを動かしてみる。ページは文字化けした。データは文字化けしてない?テスト3・Shift_JIS受け取ったデータをmb_detect_encoding()に突っ込んだ結果も表示させてみる。php.iniの変更2ちょっと気になってphp.iniを設定しなおす。autoテスト4・Shift_JISシフトJISのテストスクリプトを動かしてみる。ん?うまくいってるよ・・・?。データはUTF-8だ。テスト5・UTF-8同じくUTF-8のテストスクリプトを動かしてみる。ん、これもうまくいってるよ・・・?。いうことは、script_encodingの設定もちゃんと効いているってことかな?。php.iniの変更3その気になってphp.iniを設定しなおす。SJISテスト6・Shift_JISシフトJISのテストスクリプトを動かしてみる。ん?うまくいってるよ・・・?。データはUTF-8だ。欧文フォントが混じらなくなった。テスト7・UTF-8UTF-8のテストスクリプトを動かしてみる。ん?これもうまくいってるな。データはUTF-8だ。こっちも欧文フォントが混じらなくなった。それならばそれじゃあ本番のスクリプトを、と思ってオリジナルからシフトJISのスクリプトをコピーして動かしてみた・・・。あっっ!いけてるじゃん。それならばじゃあデータの入力は?・・・げっ!やっぱダメじゃん。どこが違うのかな・・・マニュアルを読み返してみるか。