PHP4でのコンストラクタの挙動の覚書(2)

2010/04/23 | PHPの基本

PHP4のコンストラクタのメモをもう一つ。継承先のクラスにコンストラクタがなかった場合の挙動。使用するコードは同じもので、継承先のコンストラクタをコメントアウトした。

class hoge
{
function hoge(){print(‘hoge’);}
}
class fuga extends hoge
{
//function fuga(){print(‘fuga’);}
}
$obj=new fuga;

実行結果はこうなる。

hoge

「こういう仕様である」と理解して使えば問題ないのだろうけど、まともな発想に立てば使いにくい。他の言語はどうなのか全く知らないけれど、とまどう人も多いのではなかろうか。

といっても、PHP4はかなり駆逐されてしまっているので、こういう話題もほとんど出てこないだろうけど。

PHP4でのコンストラクタの挙動の覚書

2010/04/21 | PHPの基本

PHPはバージョン5からクラスのコンストラクタを__constructと記述できるようになった。もちろんバージョン4の時と同様に、クラス名と同じ名前のメソッドでもOKだ。PHP4の時のクラスを拡張した際のコンストラクタの挙動について、毎回忘れることがあるのでメモしておく。

class hoge
{
function hoge(){print(‘hoge’);}
}
class fuga extends hoge
{
function fuga(){print(‘fuga’);}
}
$obj=new fuga;

このコードを実行した際にhogeクラスで用意したコンストラクタhoge()は動作しない。実行結果はこうなる。

fuga

parent::__construct()みたいに呼び出すのと同様に$this->hoge()と呼び出す必要がある。

いつも「どうだったっけ」となるのでメモしておく。

Smartyで配列のキーが配列の時

2010/04/18 | Smarty

Smartyで配列を処理するときはこんな具合に書く。

PHP内でこんなとき・・・$vars[‘hoge’]
{$vars.hoge}

PHP内でこんなとき・・・$vars[$hoge]
{$vars.$hoge}

PHP内でこんなとき・・・$vars[‘hoge’][$fuga]
{$vars.hoge.$fuga}

さして難しいわけではないけれど、配列のキーが配列になる場合の記述がわからなかった

PHP内でこんなとき・・・$vars[$hoge[‘fuga’]]

答えはこんな感じ

{$vars[$hoge.fuga]}

環境変数に値をセット

外部から値を渡したいことがある。すぐに思いつくのは以下の方法だ。

  • $_GETや$_POSTで渡す
  • 設定ファイルに記述し、それを呼び出す

前者の場合、その値を引き回したいときには不便だ。毎回リクエストに値を付与してやらなければいけない。後者の場合は、当該ファイルをその都度呼び出さなくてはいけない。例えば特定のディレクトリ内では、常に同じ値を与えたいという場合は、どうすれば簡単に実現できるだろうか。

SetEnv ENV_NAME env_value

これが一番簡単。.htaccessファイルに上記のように記述すると、PHPから$_ENVを参照すれば、設定した値を取得できる。これ便利。

メールヘッダを自前でエンコードするときに

PHPからメールを送信するのはよくあることだけど、いろんな方法がある。mail関数、mb_send_mail関数、PEAR_Mail、fsockopen・・・。普段はmb_send_mail関数で十分だけど、いろいろな状況下でメールを送信することがあるわけで、複数のやり方を知っておくと非常に役に立つ。日本語でメールを送信するときは、いろいろ問題はあるにせよmb_send_mail関数で十分。実際に送信する前に以下の指定さえしておけば問題ない。

mb_language(‘ja’);
mb_internal_encoding(‘utf-8′);

正しい言語指定と正しい文字コード指定をしておけばよい。ただし、この関数を知っているだけでは、例えば添付ファイル付きのメールを送信することはできない。実現するためには、関数の使い方以前にメールのお作法を知っておく必要がある。今回はいろいろあって、mail関数を使い、自前でヘッダや本文をエンコードして送信するプログラムを作ったので、それについてメモしておくことにする。

  • mb_encode_mimeheader関数
    メールのヘッダを自前で準備する際(特にマルチバイト文字を含む場合)、お世話になるのがこの関数だ。今回自前でヘッダを用意するので、いくつか覚えたことをメモしておくことにする。
    ヘッダに日本語で記述したい内容といえば送信者名(from)とタイトル(subject)だ。from句は以下のように記述するのが一般的。
    From: 送信者名<メールアドレス>
    ここで送信者名は上記関数を使ってエンコードする必要があるのだが、一工夫しておく必要がある。mb_encode_mimeheader関数の第一引数はエンコードしたい文字列だが、第二引数には文字コードを指定する(オプション)。マニュアルにはmb_internal_encodingと同じエンコードにしなければいけないと書いてある。これはちょっと気にくわない。だったら最初からこんな引数いらないじゃない。
    ここで問題がでる。基本的に文字コードUTF-8で記述しているのだからmb_internal_encoding(‘utf-8′)で処理しているはずだ。でもマルチバイトのメール送信ってISO-2022-JPじゃなかったっけ。っていろいろ考えていたら訳がわからなくなってくる。だからこう記述した。

    $fromName=mb_convert_encoding($fromName,’ISO-2022-JP’,’UTF-8′);
    mb_internal_encoding(‘ISO-2022-JP’);
    $fromName=mb_encode_mimeheader($fromName,’ISO-2022-JP’);

    文字列は変数に格納されているわけで、それらをいったんISO-2022-JPに変換しておく(メール関連の情報は全て変換すればよい)。その後mb_internal_encodingでISO-2022-JPを指定し、それにしたがってmb_encode_mimeheaderするという手順だ。これでいちおうお作法通りのヘッダを作成することが出来ている(と思う)。

しかし、わからないことがある。mb_encode_mimeheaderの第2引数の指定だ。そもそもmb_internal_encodingと同じ指定をすることが前提なら、そんな引数は必要ないだろうと思う。内部エンコードの指定はあってもいいかもしれないけれど、変換後の文字コード指定があったほうが親切だ。絶対その方がいいに決まっている。

でもなぜ今のような状況なのか。きっとなにか理由があるはずだ。そのうち理解出来るだろうか・・・。あえて探ろうとはしないけどね。


守谷市(まちの情報ポータル) 無料アンケートレンタルjpForm.net