&と#と数字と;とで、文字を表すことができる。これは当たり前のことなのだけれど、なんと言っていいのか知らなかった。数値文字参照というらしい。中国語の表示を調べていて偶然見つけた（昔からずっと気にしていた）。でもって、普通の文字列を、いかにして数値文字参照に変換するか、その方法をずっと知らなかった（困ることもなかった、といえば嘘になるが、放置していてもなんとかなっていたというのも事実）。そして今日ようやくそのやり方を知った。
mb_convert_encoding($str,’HTML-ENTITIES’,’UTF-8′);
もちろん逆もできる。他にも知らない関数を使うやり方を見つけた。
tidy_repair_string
こういう見たこともない関数でできるらしいけど、よくわからない。検索で見つけなかったら一生出会うことがなかった関数かもしれない。この関数については以下のサイトを参照。
大変勉強になりました。
move_uploaded_file関数を使っていて問題が起こった。この関数を使ってアップロードしたファイルを適切な場所に保存していたのだが、保存したファイルのダウンロードができない。Permission Errorが出る。調べてみたらパーミッションが600になっていた。おそらくオーナーがapacheか何かなので、apache以外の権限では操作できないことになっているようだ。
move_uploaded_file関数をcopy関数に置き換えてみるとこの問題は解決した（rename関数にすべきだったかな）。なぜmove_uploaded_fileとcopy関数で、移動されたファイルのパーミッションが変わってしまうのだろうか（変えるような仕様になっているのだろうか）。move_uploaded_file関数のマニュアルを読むと「セーフモードとopen_basedirの両者を考慮」とか「PHP を通じてアップロードされたファイルのみを移動できる」とか書いてあるので、このあたりの影響のせいだろう。本当のところはソースを読まないとわからないけれど。
最近は、メールの到達をトリガーにしたアプリケーションを組んだり、XML-RPCだったり、と通常の$_POSTや$_GETで取得できないデータを取り扱わないといけないことも多い。世に出ている各種ライブラリを使うのもいいが、汎用性も何も必要ないので、手書きで数行でプログラムを書いてその場をしのぐこともある。そのほうが「ライブラリの使い方」を勉強しなくていいからだ。
生データにアクセスするにはphp://stdinやphp://inputを使用する。具体的には以下のような記述がある。
$request=file_get_contents(‘php://input’);
昔はstdinを使っていたのだが、最近はinputを使うようだ。でもその違いがわからない。ちゃんとした解説を見つけられないでいる。今借りているレンタルサーバの一つで試したらinputではデータを取得できたけど、stdinではダメだった。基本的なセンスとして「動けばいい」というのが自分のポリシーなのでこれ以上詮索しなかったけど、実際問題としてどういう違いがあるのか、というところには興味がある。
解説ページを探そう。
基本的にメール送信はmb_send_mailを使っているが、いろんな事情でfsockopenによるメール送信を実現しなければならないときがある。それでも、マルチバイトなメール送信でない場合は、何も気にしなくてもスムーズにいくが、マルチバイトなメール送信となると、文字化け問題が常につきまとう。
今回fsockopenでマルチバイトなメール送信プログラムを書いたときに、文字化けせずに送信できたので、その例をメモしておく。
■タイトル
$subj=mb_convert_encoding($subj,’JIS’,’（元のエンコーディング）’);
$subj=mb_encode_mimeheader($subj,’JIS’,’B’);
■本文
$body=mb_convert_encoding($body,’JIS’,’（元のエンコーディング）’);
よく調べてないけれど、タイトルはいったんJISに変換してからmb_encode_mimeheader。本文はJISに変換するだけでいい。
結果オーライということで。
つい先日、クライアントさんに納品した案件で不具合があった。本番環境にて稼働させたところ問題が発生したとのことだった。まぁ、本番環境というのは得てしてテスト環境よりもアクセス数等が増加するし、想定外の操作をしてしまう人もいるはずなので問題が出てもおかしくはないのだが（もちろん想定外の動作などないように、各種想定をされたプログラムがいいのはいうまでもないけれど）。
今回のプログラムで、クライアントから「トラブル発生」の連絡を受けた際に想定したのは「max_execution_time」だ。つまり想定した数よりも多いデータ数を処理しなくてはいけなくなってしまったので、当然処理時間が増え、システム規定の時間では間に合わなくなってしまった、という場合だ。
実際、現地を訪れエラーの出る処理を試してみた。しかし、エラーは一定時間をおいて出るのではなくすぐに出る。しかも表示されるエラーはIEのエラー（ちゃんと確認しておけばよかったと後悔している）。
リンクをクリックして、すぐにエラーが出るのであれば、max_execution_timeの問題ではないはずだ（PHPのエラー画面が表示されるはずだし、システム規定の時間はプログラムが稼働するはずだから）。次に想定したのは、memory_limit。取り扱うデータ量が増えることは容易に想像できるから、ini_setコマンドで多めに設定してみた。これで見事解決した。
本番環境では、得てしてプログラムが想定外の動作をしてしまうことは多々あるが、今回はその典型となるような例だった。プログラムのエラーが発生しているのか、環境的な問題でエラーが出ているのかは判断がつきにくいところではあるが、相応の経験をしていれば意外と簡単に原因を突き止められるものだなぁ、と思った次第であった。