PHPでのメールでの添付ファイルの読みだしに QdmailReceiverを使っているのですが、Gmailからのメールのみ添付ファイルが取り出せないという現象に少し悩みました。
ググったところ配布サイトのほうで質問があがっており、まさにドンピシャでした。
http://hal456.net/qdmail_rec/stdin_base
原因はGmailで添付ファイルを送信するとき時にboundary=をダブルクオーテーションで囲ってくれないというGmailの変な仕様？のせいでした。
対策は
> qdmail_receiver.phpの４６１行目あたりを
> preg_match( ‘/boundary\s*=\s*”*([^”]+)”*/is’ , $this->header[‘content-type’] , $matches );
に書き換えるとのことで、こちらで試したところ確かに大丈夫でした。
PEARのCrypt Browfishライブラリの挙動がローカル環境とサーバ環境で違うのでなんだろうと思って解析してみた。
結果、Windows版とLinux版で排他的論理和の挙動が違っていることが原因と判明。
echo ((-21474836470) ^ (2147483647));
Windows版ver5.2.9
echo ((-21474836470) ^ (2147483647));
結果→ 2147483637
Linux版PHP ver5.1.6（CentOS5付属）
echo ((-21474836470) ^ (2147483647));
結果→ -1
そもそも、ライブラリ内で扱っている初期値での演算で32ビット超えしちゃっている時点で、ライブラリの実装として間違っているような気がするが…。
それはさておき、上記の違いがマシンの64ビットと32ビットという環境の違いが原因かと思ったけど、いくつかの環境で試してみたところそうではないみたい。同じ環境内であれば暗号化、復号化とも問題ないようですが、暗号化データを移行する時は注意が必要ですね。
CentOS5にPHPUnitを導入するついでにxdebugもインストールする際、ちょっとはまったのでメモ。
# yum -y install php-devel (<-xdebugをpeclでインストールする場合に必要) # pecl install -a xdebug
ところが下記のエラーで止まる。
Fatal error: Allowed memory size of 8388608 bytes exhausted
pearのバグらしいので設定ファイル(/usr/share/pear/pearcmd.php)を修正する。
以下のコードを適当な場所に追加する。
@ini_set('memory_limit', '16M');
これでコンパイル＆インストールは通った。
xdebugの設定ファイル(/etc/php.d/xdebug.ini)を作成する。
下記の内容でxdebug.iniファイル作成する。
zend_extension=/usr/lib/php/modules/xdebug.so
インストールが成功したかどうかは下記のコマンドで確かめる。
$ php -i | grep -i "xdebug support" xdebug support => enabled
参考URL
http://d.hatena.ne.jp/snegishi/20071212/1197422664
http://winofsql.jp/VA003334/php051120172152.htm
http://gihyo.jp/dev/feature/01/php-test/0003?page=5
最近CakePHPなどのフレームワークについて勉強して遊んでいるのですが、最近はViewの部分でSmartyを利用せずに生のphpファイルを利用するのが主流なんですね。（Smartyをオプション的に利用することは可能なようですが）
仕事で何度かSmartyを利用しているのですが、正直メリットよりもデメリットの方が大きいような気がしていましたのでこの方針は結構なことです。
そもそもテンプレートエンジンというものは、デザインとロジックをきれいに分離するために存在するわけです。
で、PHPの場合は require なり includeなりで、内部の処理に合わせて動的にインクルードするファイルを切り替える機能を言語として持っています。
したがって、実はわざわざロジックとデザインを分離するためにテンプレートエンジンに頼る必要はなくて、「ロジック用のphpファイル」と「デザイン用のphpファイル」を最初から分離してコーディングすればOKなわけです。
だいたい、生のPHP自体がテンプレートエンジンとして十分に簡潔な記述力があります。
生PHP : <?= $name ?>
Smarty : {$name}
上と比べて下の方が確かに書きやすいかもしれませんが、まあ大した違いはないですよ。
デザイナーに優しいというけれど、ループ処理のあの妙ちきりんな記述方法を普通のデザイナーさんが理解してコーディングしてくれるとは思えません。
結局PHPプログラマがSmartyの記述法を覚えて、デザイナーに指示をする、あるいはプログラマが直接HTMLに手を入れるしかないわけです。だったら始めからPHP言語で書いたほうが（新しい言語を覚える手間がない分）ベターでしょう。
Smartyの場合、デザインを分離するというより、表示にあたってhtmlを加工する機能がいろいろあることが便利だと受け取られているような気がします。
しかしこれらは単なるライブラリ的な機能ですからテンプレートエンジンであるところのメリットではありませんね。
それより問題なのはテーブルを何重か入れ子にするような複雑なテンプレートの場合、Smartyを使うとデバッグがえらく大変になることです。PHPのデバッガがSmartyの吐き出す複雑怪奇なキャッシュファイル上の行番号を教えるため、間違いの場所を探すのが非常に骨が折れます。
あと、スペルミスなどでassignに失敗したデータを表示しようとするとエラーにならずに単なる空白表示になるのもミスを見落とし易くなり問題だと思います。
まあ今どきはHTML自体はなるべく簡潔にして、デザインはcssで記述するというスタイルが主流です。PHPに限らず、今後はテンプレートエンジン自体の必要性は自然に低下していくのでしょう。
ともかく、私にとって今のところはSmartyを積極的に利用する必然性を見出せません。まあ表示用変換機能の部分は確かに便利なので、誰かがその部分だけを切り出してライブラリに仕立て上げてくれたらいいのになあと思います。（自分がやればいい話かな）
今、データベース間でデータをコピーをするというプログラムを作っているのですが、今日ちょっとハマってしまいました。
一見動いているようなのに実はデータが全然コピーされていない…。
いろいろ調べた結果、mysql_connect関数の問題であると判明しました。
マニュアルでは
int mysql_connect([string server [,string username [,string password]]])となっていますが、注意として
同じ引数で2回mysql_connect()をコールした場合、 二回目は新規のリンクが確立されるのではなく、代わりにすでにオープンされた リンクのリンクIDが返されます。
と書いてあります。
今回、コピー元とコピー先のデータベース名は違いますが、同じサーバ、同じユーザ、同じパスワードで接続していました。
ですので（違うコネクションだと思っていたものは）実は同じコネクションであり、同時に使う処理は当然できないのでした。
で解決法ですが、簡単でした。
（なぜか私のマニュアルには説明がありませんでしたが）４番目のパラメータがあり、それにtrueを渡せば必ず新しいコネクションを返してくれます。
$cn = mysql_connect('localhost', 'user', 'passwd', true);
まあ一種のフールプルーフとしてむやみにコネクションを張らせないようこういう仕様になっているのでしょうが、知らないと動かした時に？？？となってしまいます。
というわけで、ちょっといただけない仕様ですね。