PHPのテクメモ

現在Mac版のMicrosoft Officeを使っている。今日はWordについて。ちなみにいま使っているのはWord 2011。

Windows版とメニューの位置とかが違うことが多くて、時々困ってしまうことがある。今日困ったのは、ヘッダーやフッターの記述について。ヘッダーやフッターを前のページとは違う内容にしたい場合「前と同じ」を解除する方法が一向にわからなかった。

最初はリボンの文書パーツを見ていた。ページ番号というボタンがあるので、それを見ると、当該ページからページ番号を振り直す、といったことはできるのだけれど、新たに「付録」とか「追記」とか文言を挿入する方法がわからない。あくまでページ番号を振り直すことはできるけど、その書式はおなじであるという前提のようだ。

そしていろいろ触ってようやく気がついた。フッター部分でダブルクリックすると、フッターの編集画面が出るのだが、なんとリボンに「ヘッダーとフッター」という項目が増えている！。それをクリックすると、リボン中に「前と同じヘッダー/フッター」というチェックを見つけることができた。これを解除することで、書式も変更することができた。

リボンのメニューを増やすなんて、UIとしては最悪だなーと思った。多分悩んでいる人多いだろうなー。

Kagoyaで借りているVPSに帯域制限がかけられてしまった。転送量が多すぎたのか一時的な不可が高すぎたのか・・・。

Kagoyaで借りているVPSは、毎日深夜に1回お名前.comで借りているKVMなVPSとrsyncで同期をとっているバックアップサーバだ。帯域制限はかかっているようだがファイルのバックアップはとれているっぽい。しかしメールが届かなくなってしまっている。何故だろう。

負荷がかかるのはデータの同期で、メールの送受信はそんなに負荷はかからないと思うのだが、結果として、同期OKでメール不可っぽい状態が発生している。原因を調べてみなくてはいけないな。

ちなみに同期元のお名前.comのサーバについては何も言われていない。ということで、お名前.comとKagoyaクラウドにおいて、Kagoyaにかけられた帯域制限の原因を考えてみるとこんな感じだろうか。

• お名前.comのインフラやハードウェア等がかなりステキでお名前.com側には何ら不可がかかっていない。ただしKagoyaはしょぼすぎてすぐに制限がかけられる。
• インフラやハードウェアは同等だが、お名前.comの管理が甘々で、チェックがかかっていないだけ（他人の影響をうけやすい）。
• インフラやハードウェアは同等だが、Kagoyaの管理がキツキツで、すぐに制限がかけられる（他人の影響はうけにくい）。

メールはシステムのヘルスチェックをかけるために使用しているだけだが、正しく動作しないと手動でチェックしなくてはいけないので不便。引っ越そうかな。

あー、もう厄介なサーバはほんとやだ。

Call to undefined function imagettfbbox() …

GD関数は使えるんだけど、imagettfbbox関数が使えない。何かコンパイルオプションが足りてないんだっけ、と調べてみたらfreetypeが組み込まれていない。phpinfoのGD欄に「FreeType Support」の記載がないのだ。

関数が使えなければ始まらないので、サーバ会社に依頼してみた。使えなければ、もう終わりだな。

MD5ハッシュ値を返すmd5関数とmd5_file関数。前者は引数としてハッシュ化したい文字列を受け、後者は引数としてハッシュ化したいファイルのパスを受ける。ここまではマニュアル通り。

とある仕事で、「UTF-16LE」のファイルをPHPで取り扱う際に、うまくいかない問題が生じている。「UTF-16LE」を使うのには理由があって、ファイルをエクセルでそのまま扱いたいからだ（エクセルで編集してアップロード、ダウンロードしてエクセルで編集）。

開発環境で用意したスクリプトを本番環境に移設してテストするのだが、これがなんともうまく動作しない。いろいろ探ったのだが、どうもそのサーバでは「UTF-16LE」で記述されたファイルをPHPで読み込むと、どういうわけか改行コード付近を勝手に変換しているように見受けられる。単にfile_get_contentsしているだけなのに！。

自分で借りているレンタルサーバ、VPS、自分のMacで、file_get_contentsした値をbin2hexして出力してみると、そのサーバでだけ値が異なってしまう。ひょっとしてサーバへの転送の時点で何らかの変換がかかっているのかも、と思ってサーバにあるファイルに対してmd5_file関数でハッシュを取るとそれは全て同じ値が返ってくる。つまりテストしているファイルは同じファイルであることに間違いはない。

そして冒頭のmd5。file_get_contentsした値に対してmd5すると当然md5_fileとおなじになるはずなのに・・・そのサーバだけ違う値。つまりmd5した結果とmd5_fileした結果が異なる値になっている。

いろいろ調べて、文字コードが「UTF-8」の場合は、そのサーバでも事象が発生しなかった。さーどうしようか。サーバ会社に文句を言えばいいのだが、たいていは「プログラムに問題があるんじゃないですか」で終わってしまう（既に別件で適当な嘘を疲れているのでこのサーバ会社は一切信用出来ない）。PHP5.2系の問題である可能性も捨て切れない。もうちょっと悩んでからクライアントに相談することにする。

この前新しく借りたKagoya Cloud。今日このサーバでnslookupコマンドを実行しようとしたら、やっぱりここでもインストールされていなかった。もはやnslookupなんて時代遅れでdigなのかね、と思って調べたらdigもnslookupもbind-utilsパッケージに含まれてるんじゃん。

「パッケージ全部入り」とかでインストールすれば当然入るんだろうけど、そういうことは常識的に考えてやらないので、普通にインストール（どういうパッケージ構成なのかは知らないけれど）すると、CentOSでは、5系から6系になって、bind-utilsはインストールされない方向になったのかなー。