今回、メーラーによっては、日本語の本文が文字化けするという現象を確認。
調査したところ、通常、本文はPrintableでエンコードされて送信されていました。
なので、ここをbase64にてエンコードするように修正して解決。
$mail->setBodyText($text):
と書いていた部分を以下のようにエンコード形式を指定して設定します。
$mail->setBodyText($text, null, Zend_Mime::ENCODING_BASE64);
文字化けってほんとやっかいです。
select
t1.column_a,
t2.column_b
from
table_a as t1
left join table_b as t2 on (t1.hoge = t2.hoge and t2.make_date <= 'xxxx')
where
t2.column_b is null
こんな感じで、left joinしたテーブルに対しての条件を、
更にwhere句で追加できるとは知らなかったです。
勝手にできないものだと思っていました。
この場合、t2.column_bがnullではないものは、left join on で指定してしまえばOKなのですが、
nullの場合、カラムの値がnullでなくても、make_dateの条件に合致しなければ、nullが
取得されるので、今までは取得結果をループで回してnull以外のデータをはじいてました。
これで、無駄なソースが減る場所がいくつかあったので、メモです。
マニュアルはこちら
http://dev.mysql.com/doc/refman/4.1/ja/control-flow-functions.html
left joinでNULLのときの表示値設定や、カラムの値によって、レコード数をカウントしたり
使い勝手はいいと思うし、実際に使ってみたらとても便利。
case ～ then もいいけど、elseが必要になる場合ってあまりないから、
ifの方がSQL文も短くですっきりしますね。
array_pushのマニュアルに書いてありましたが、知りませんでした。
【注意: もし配列にひとつの要素を加えるために array_push() を使用するなら、
関数を呼ぶオーバーヘッドがないので、$array[] = を使用するほうがいいです。 】
忘れないようにメモ。
findManyToManyRowsetの説明は、こちらを読んでください。
つまり、例をあげると、
アカウント【Accounts】、ブログ記事【Articles】、コメント【Comments】
というテーブルクラスがあり、$account(Zend_Db_Table_Row)があった場合、
$account->findCommentsViaArticles();
とやると、コメント情報(Zend_Db_Table_Rowset)が取得できます。
リンク先のマニュアルに書いてあるのはここまでです。
今日、このメソッドを使っていて発見したこと。
このメソッドで取得される情報には、中間テーブル（今回はArticles）の
データも含まれていることです。Commentsの情報しかないと思っていたので意外。
データの更新は、Commentsのカラムしかできませんでした。
中間テーブルのデータは参照だけできます。更新しようとするとエラーになります。
どういうときに便利かはわかりませんが、忘れないようにメモ。
Zendのソースを見ているときに見つけたこれらの関数。
今まで正規表現でチェックしてたところに使えるので、メモ。
正規表現でやればいいと思ったりもするけど、慣れない人には
正規表現ってすごく分かりづらい。
だから、こういう関数を使うのはいいと思っています。
ctype_ alnum 英数字
ctype_ alpha 英字
ctype_ digit 数字
ctype_ lower 小文字
ctype_ upper 大文字
前回の記事で以下のようなディレクトリ構成でやってますって書きました。
web/index.php
lib/models/xxxxModel.php
lib/validates/xxxxValidate.php
lib/dbs/xxxxxDb.php
lib/controllers/xxxxxController.php
そこにコメントをいただき、調べてみたところ、
以下の構成にしたら、Zend_Loader::registerAutoload()を生かせるのかなと思った。
web/index.php
lib/models/xxxx.php
lib/models/Dao/xxxxx.php
lib/models/Validate/xxxx.php
lib/controllers/xxxxxController.php
もともとmodelってのは処理クラスの集合体があることがイメージされているのかも。
そうだとしたら、私は勘違いしてた。
もうちょっと考えてみる。
偶然見つけたメソッド __autoload。
最近までphp4ばかり使ってたので、マジックメソッドには疎いのです。
たまたま見つけたサイトで、マジックメソッドについて読んでみて、
早速__autoloadから試してみました。結果は便利です。
私は、phpでプログラムを新規で作る場合は、Zend Frameworkを利用していますが、
だいたいこんなディレクトリ構造です
web/index.php
lib/models/xxxxModel.php
lib/validates/xxxxValidate.php
lib/dbs/xxxxxDb.php
lib/controller/xxxxxController.php
小規模なものしか作っていないので、この階層分けでなんとかなってます。
そこでindex.phpに以下のように __autoloadを追加したら、
各ファイルで、Zend_Loader::loadClassや、require_onceを
記述する必要がなくなってとても楽です。
function __autoload($className)
{
if (preg_match("/^Zend_/", $className)){
Zend_Loader::loadClass($className);
return;
}
if (preg_match("/Model$/", $className)){
require_once('models/' . $className . '.php');
return;
}
if (preg_match("/Db$/", $className)){
require_once('dbs/' . $className . '.php');
return;
}
if (preg_match("/Validate$/", $className)){
require_once('validates/' . $className . '.php');
return;
}
}
以前、https://life.co-hey.com/2008/03/zend-mailfrom.htmlという記事を書きました。
ヘッダーをエンコーディングする際の処理を変更しようという内容でしたが、
今回追記しておいた方がいいなということあったので追記です。
mb_encode_mimeheaderでは、mb_internal_encodingの文字コードと、
mb_encode_mimeheaderの第2パラメタで指定した文字コードが一致しないと
正常に変換されない場合があるようです。
なので、以下ように書いておいた方が無難ですね
mb_encode_mimeheader('"'.$name.'"', 'ISO-2022-JP')
↓
$encode = mb_internal_encoding();
mb_internal_encoding('ISO-2022-JP');
mb_encode_mimeheader('"'.$name.'"', 'ISO-2022-JP');
mb_internal_encoding($encode);
久々で忘れていたので、ここにメモっておきます。
文字コードを検出するメソッド。
mb_detect_encoding