カテゴリ： php

Apacheが共用サーバなのでPHPモジュールを切り替えるとユーザ全員が切り替わるという。
只今、7.4を利用中。7.4を使い続けるなら別プロセスを起動するCGI版にせねばならないがこれは勿論遅い。
非互換は https://www.php.net/manual/ja/migration80.incompatible.php に記載されているが、自作部分は特に引っかからなそうではあるが何が起こるか分からない…。
まぁ一旦8.1CGI版に切り替えてテスト、その後7.4モジュール版に戻して、モジュールが8.1に切り替わるのを待つ…のがいいのかな。

いちばんやさしいPHPの教本 第3版 PHP 8対応 人気講師が教える実践Webプログラミング (「いちばんやさしい教本」シリーズ)
いちばんやさしいPHPの教本 第3版 PHP 8対応 人気講師が教える実践Webプログラミング (「いちばんやさしい教本」シリーズ)
有限会社アリウープ
インプレス
2021-11-22



このエントリーをはてなブックマークに追加 mixiチェック

結局、SQLite3クラスではなくPDOを使った。
SQLite3は意外に速い。しかしSQLをprepareしてもそのままexecuteしてもあんまり変わらない感じ。本当に実行計画をキャッシュしてるか非常に怪しい気がしないでも無い。まぁMySQLですらなんちゃってprepareだしな。真面目にキャッシュしてるのはOracle DBくらいじゃなかろうか。
ともあれ、http://nekora.main.jp/comic/thumb/Ranking/all/　←このように左のメニューの「New」の付き方が一ヶ月ぶりに正常化した。今までは各ジャンルのデータファイルの更新時刻から割り出していたんだが、６月初頭に良さげな作品を上に持ってくる処理を定期実行するようになってからは、新作追加が無いのに「New」が付いてしまい訳が判らなくなっていたが、DBで別管理にしたからもう大丈夫。

このエントリーをはてなブックマークに追加 mixiチェック

すっかり忘れてた。今試しに.php5でテストしてみたら左のサイドバーが文字化けするんだけど…。
あのあたりは随分弄ってないから完全に忘れてる。

ねこらった(拙作)
　↓
縺ｭ縺薙ｉ縺｣縺・諡吩ｽ・

このパターンは何だっけかね。本当はShift_JISになって欲しいのに豆腐にならずにやたら難しいこれは…UTF-8をShift_JISとして表示してる感じ。
行ってるのはsubindex5;か。
んー、xmlファイル(shift_jis)からタイトルだけ抽出してるな。

xml_parser_create()

を使ってる。ここで文字コードを指定してないのがまずいのかな。

パラメータ
encoding
PHP 4 では、オプションの encoding で入出力の エンコーディングを指定します。PHP 5 以降では入力のエンコーディングは 自動判定されるので、encoding パラメータは 出力のエンコーディングのみを指定することになります。PHP 4 では、 デフォルトの出力エンコーディングは入力の文字セットと同じです。 もし空の文字列が渡された場合、先頭の 3 あるいは 4 バイトの内容をもとに パーサがエンコーディングの判別を試みます。PHP 5.0.0 および 5.0.1 ではデフォルトの出力文字セットは ISO-8859-1 で、PHP 5.0.2 以降では UTF-8 です。サポートされるエンコーディングは ISO-8859-1、UTF-8 および US-ASCII です。

http://php.net/manual/ja/function.xml-parser-create.php

…Shift_JISは？
つか私これ、昔調べたよ。。http://d.hatena.ne.jp/nekora/20090210/p5　そのあと「ファイルを全部UTF-8にしたら治った」のでhttp://d.hatena.ne.jp/nekora/20090211/p1 でそっちの方向に倒してそのうちやろうと忘れてたんだっけ。
つまり現在どうなっているか？というとおそらく
・xml_parserへの入力：自動判定でShift_JIS
・xml_parserからの出力：デフォルトでUTF-8
で、HTMLな画面全体はShift_JISなのでブラウザ側でUTF-8をShift_JISとして表示しようとして文字化け。化け方の感じからしても多分こうなってる。
つまりxml_parserの吐く文字列(多分UTF-8)をどこかでShift_JISに変換してやれば良い？

mb_convert_encoding($data, "Shift_JIS");

すると何か実行時にエラーが発生していて処理が止まる。プラウザには何も出ない。
→php.iniに display_errors = On にしてApache再起動で出るようになった。

Fatal error: Call to undefined function mb_convert_encoding() in なんとか.php on line 51

mb_convert_encoding()って標準関数じゃないの？

php.ini ファイルはいくつかあると思いますが、xampp\apache\bin\php.ini を編集しましたか？
別のファイルを編集しても反映されません。
あと、以下の行がコメントアウトされていないことを確認してください。
extension=php_mbstring.dll
これでアパッチを再起動すればOKです。

http://q.hatena.ne.jp/1202326856

この辺？
xamppは使っていないのでc:\php\php.iniの方を修正したところアパッチ起動時に

PHP Warning: PHP Startup: Unable to load dynamic library './php_mbstring.dll' -
指定されたモジュールが見つかりません。
in Unknown on line 0

でもロリポップ側サーバでは正しく設定されている可能性が高いが。というかロリポップ側のphp.iniの設定項目でmbstring関係のがいくつかあるので設定済みなのだろう。
http://kemuri-net.dip.jp/~server/php/bbs/read.php?FID=5&TID=39
PHP.iniに以下を設定

extension_dir = "C:\PHP\ext"

→よし、上記の

$data = mb_convert_encoding($data, "Shift_JIS");

を追加することで文字化けは治った！(ローカル環境では)。実際にはmbstring関係の設定が他にもあるのでそれも設定。
でも休日の夜はアクセスが多いので安全のためPHP5への切り替えは明日だ。明日は一時的にサイドバーが文字化けすることになるだろう。
ちなみに上記改造を施したモジュールをphp4で動かそうとすると愚かにもShift_JIS→Shift_JISの変換しようとして「？？」だらけに。
多分「コンテンツも内部コードも最終出力するHTMLも全部UTF-8に統一」方式ならPHP4,PHP5どっちでも動くのだろうけど、今となってはまぁいいや。
それにしても今宵のロリポップの管理画面は遅いなー。

このエントリーをはてなブックマークに追加 mixiチェック 

echo "更新\n".date("Y/m/d H:i:s",filemtime($datafile));

の前後で$datafileの中身が空になるという怪現象に遭遇。

	$datafile="./test.php";
	print "Before ".$datafile;
	echo "更新\n".date("Y/m/d H:i:s",filemtime($datafile));
	print "After ".$datafile;

まで削るとさすがに大丈夫。まぁ再現するので差分を見ていけば大丈夫だろう。マルチスレッドって訳でも無いので多分単純ミスと思われる。

このエントリーをはてなブックマークに追加 mixiチェック

↑このページのトップヘ