CPA-LABテクニカル http://www.cpa-lab.com/tech/ ja CPA-LABを作成する際の技術上の覚書。日曜プログラマの戯れ言。 Copyright 2008 Sat, 30 Aug 2008 02:47:58 GMT Sat, 30 Aug 2008 02:47:58 GMT http://adiary.abk.nu/#1.44 http://blogs.law.harvard.edu/tech/rss デコメテンプレート変換はじめてガイド http://www.cpa-lab.com/tech/0172#tm1220064478 http://www.cpa-lab.com/tech/0172 デコメ Wed, 27 Aug 2008 10:33:35 GMT spok デコメ（デコメール）のテンプレートはキャリア毎に仕様が異なる。今回のqdmailバージョンアップでは、デコメテンプレート変換をできるようにした。
しかもテンプレート変換だけでなく、通常のメールや受け取ったデコメデータから、テンプレートを作成してくれるスグレモノ（のはず）。
なお、QdmailReceiverというQdシリーズのメールでコードソフトが必要です（使い方は簡単）。

使い方は、Qdmailデコメテンプレート変換マニュアルをご覧下さい。

これを使った試験サービス--デコメを3キャリ対応デコメテンプレートに変換

この記事の最後のQRコードを読み取って、携帯電話からメールを送ってみて下さい。
その際には、ご自分のＰＣメールアドレスにCCしてください（しなくてもいいけど）。
ＰＣメールから普通にメールしていただいても大丈夫です。なんとなく怖い方は（メルアドの収集なんてしていないですから安心はして欲しいのですが）、捨てアドから、以下のメールになんでもいいのでメールしてみてください。

すると。。。。

携帯アドレスとCcアドレスに、その送ったデコメが、ドコモ(Docomo)、au、ソフトバンク(Softbank)の３つのキャリアのデコメテンプレートに変換され、その変換されたファイルが添付されたメールが送られてくるはずです。

お試しあれ。
decotest987.jpg
うまく読み取れない方は、decotest987　 あっとまーく　hal456　ドット　netまでデコメを送ってみて下さい。


ちなみに、デコメでなくても、普通のメールを送っても、デコメテンプレートになって返ってきます。
このサービスのサンプルコードはこちら

続きを読む

■コメント（0件）

■トラックバック（0件）

]]> タイポが止まらない http://www.cpa-lab.com/tech/0170#tm1219190810 http://www.cpa-lab.com/tech/0170 未分類 Wed, 20 Aug 2008 00:06:50 GMT spok Qdmailでまたもやタイポミス。
相当長い間気づかなかった。
メールヘッダーのContent-type:の構築にて、attachmentとすべきところをattachementとしていた。。。。
これって、一番最初のバージョンからだよね。
このせいで、携帯端末のauでは添付ファイルが正常に認識されなかった模様。
指摘していただいたユーザーに感謝。指摘がなければずっと気づかなかっただろう。
でもだいぶすっきりした感じ。
ユーザーにおかれましては、最新版にアップデートしてください。
Qdmailは常に最新版推奨です。

■コメント（0件）

■トラックバック（0件）

]]> テストの限界 http://www.cpa-lab.com/tech/0169#tm1219068679 http://www.cpa-lab.com/tech/0169 未分類 Mon, 18 Aug 2008 14:11:19 GMT spok Qdmailの開発でえらいポカをした。
単純なテストを忘れたために、一番基本的な使い方でエラーがでるバグ。
複雑な指定ができるインターフェイスを設計した場合、一番複雑なパターンでテストはするのだけれど、今回は、最も単純なパターンでのテストを忘れていた。
今回のバグは、qd_send_mailの第１引数が配列でなく、単純なstringタイプの時にエラーが出ていた。
機械的にすべてのパターンを試すようなテストのためのプログラムを組めばいいのだろうけど。。。。。
今後の開発ツールとしては必要なのだろうけれど、おそらく大幅な改編はしないであろうQdmailにそこまでの労力を注ぎ込むかどうか。。。。
ぼちぼち本業サイトの繁忙期でもあるし、どうしましょう。

■コメント（0件）

■トラックバック（0件）

]]> メールのデータサイズを知る http://www.cpa-lab.com/tech/0168#tm1218639922 http://www.cpa-lab.com/tech/0168 未分類 Wed, 13 Aug 2008 15:05:22 GMT spok 高機能メールコンポーネントQdmailの1.0.3bから、メールのデータサイズ（バイト数）を取得できるようにしました。
http://hal456.net/qdmail/size

デコメなどでは、容量制限を守らなくてはいけない場合があり、メール送信前に、制限値を超えているかどうかを確認する必要もあるのかな、と思って実装してみました。

■コメント（0件）

■トラックバック（0件）

]]> エラーの隠蔽 http://www.cpa-lab.com/tech/0160#tm1218587368 http://www.cpa-lab.com/tech/0160 未分類 Wed, 13 Aug 2008 00:28:37 GMT spok 高機能メールコンポーネントQdmailでは、発するエラーを画面に表示しないこともできます。

Qdmailのエラー処理

そうしないと、残念ながらこうなってしまいます。

http://www.namikawa.co.jp/dataupload/registration_send.php
（エラーの画面なので、いつなくなるかわかりません。）
Qdmail error: Must Header is not exist 'TO' line -> 1537
Qdmail error: No Receipt line -> 2159
Qdmail error: No send . Because PHP mail function replied error line -> 1500
Qdmail error: Send Error line -> 1436
Qdmail error: No send . Because PHP mail function replied error line -> 1500
Qdmail error: Send Error line -> 1436
このエラーの例をみて、ああ、エラー出力にも、Qdmailのバージョンを表示させたほうがいいな、と思い、あるバージョンからは、エラー時にバージョンも表示するようにしています。

でも、運用時には必ず、
$mail -> errorDisplay( false );
としたほうがいいですね。
これで画面にエラー出力をすることはありません。他でエラーを検知する必要はありますが。
というか、これをデフォルトにしたほうがいいのだろうか。。。。

■コメント（0件）

■トラックバック（0件）

]]> CakePHPのプロもメールのプロではない？ http://www.cpa-lab.com/tech/0167#tm1218378999 http://www.cpa-lab.com/tech/0167 未分類 Sun, 10 Aug 2008 14:36:39 GMT spok 弘法もメールの誤り？で書いたブルー...さんから、逆引きCakePHPのバージョンアップのお知らせが届いた。
ら、

続きを読む

■コメント（0件）

■トラックバック（0件）

]]> 秀丸メール返信テンプレート http://www.cpa-lab.com/tech/0166#tm1218256474 http://www.cpa-lab.com/tech/0166 秀丸 Sat, 09 Aug 2008 04:31:36 GMT spok

■秀丸返信テンプレート覚書

引用符無し,日時,From,To,Cc,Subjectを入れる

$c

 ----- Original Message ----- 
Date:     $(FormatDate,$(RootHeader,Date),"YYYY年MM月DD日(W) hh:mm:ss")$-

$(SmallRootHeader)$-

$(OrikaeshiRootBody)
Tips
$(OrikaeshiRootBody)を$(RootBody)とすると、折り返し禁止の改行コードとなる。
私は$(OrikaeshiRootBody)が好み。

○○さんが書きました。

$c

 -----------------------------
$(FormatDate,$(RootHeader,Date),"YYYY年MM月DD日(W) hh:mm:ss")$-に
$(SetNameOnly,$(RootHeader,From))$- さんが書きました。

$(OrikaeshiRootBody)

○○様　お世話になります。▲▲です。

$(SetNameOnly,$(RootHeader,From))$-　様

お世話になります。$(SetNameOnly,$(CurrentHeader,From))です。
$c

（署名）

 ----- Original Message ----- 
Date:     $(FormatDate,$(RootHeader,Date),"YYYY年MM月DD日(W) hh:mm:ss")$-

$(SmallRootHeader)$-

$(OrikaeshiRootBody)

■コメント（0件）

■トラックバック（0件）

]]> qd_send_mail登場 http://www.cpa-lab.com/tech/0165#tm1217763725 http://www.cpa-lab.com/tech/0165 未分類 Sat, 02 Aug 2008 06:22:45 GMT spok 高機能日本語メールコンポーネントQdmailが1.0.0bにバージョンアップし、
mb_send_mailの機能強化版、qd_send_mail関数が使用可能になりました。
デフォルトではPear::Mailでもできない、携帯へのデコメ送信も簡単にできます。
それでいて複雑な設定も可能です。

（mb_send_mail自体は使用していません。）

■Qdmail　1.0.0 の特徴（機能）Feature

  • 使い方に合わせた3つの指定方法
    • qd_send_mail() 型　　超オススメ！
    • $mail -> easyText()　型
    • $mail -> send() 型
  • PHPの対応バージョン
    • PHP4,PHP5の両方に対応
  • フレームワークへの対応
    • CakePHP1.1 & 1.2
    • 専用ファイルでなく、通常のQdmailをCakePHPのコンポーネントとして使用可能
  • 簡単にできること
    • 日本語メール（日本語本文、日本語ヘッダー）
    • 日本語以外のマルチバイト各国語メール
    • 添付ファイル（日本語添付ファイル名ＯＫ）
    • 携帯デコレーションメール対応（携帯4社+PHS1社自動判別対応。日本のみ）
    • インテリジェント・ワードラップ（http://の列は、折り返しをしない等が指定できる）（文字数でなく、文字幅での折り返しも可能。英数字と日本語が混ざっても綺麗！）
    • 簡易テンプレート機能(差し込みメール)
    • SMTP送信　QdSmtpと組み合わせて、簡単にSMTP送信
  • 自動でやってくれること
    • 文字コード判別
    • MIME判定
    • HTMLメール時の代替テキスト文生成機能
    • 様々な指定省略時のデフォルト設定
  • 多彩にできること
    • 宛先分離機能（複数宛先に1通づつ送付する機能）
    • 複雑なMIMEタイプ指定
    • 複雑なマルチパート構成
    • 複雑なワードラップ(折り返し処理)
    • 多彩な指定方法
    • 常に管理者にBCC
    • iso-2022-jp以外にも、utf-8,Shift-JIS等の文字セット可能
    • ヘッダー、本文の文字コードをそれぞれ別に指定可能
    • 本文base64エンコードの指定可能
    • 本文Quoted-printableエンコード指定可能
    • 送信ログ、エラーログ作成機能
    • 不具合時のデバッグ情報作成機能
    • 新たな方式のデコメ対応機種がでても簡単に追加可能
    • 独自のメールアドレスチェック（バリデーション）関数を指定可能
    • デコメ、インラインHTMLメール時のContent-Idを任意に指定可能
    • sendmailへのオプション渡し可能

■コメント（0件）

■トラックバック（0件）

]]> でるわでるわ伝説 http://www.cpa-lab.com/tech/0163#tm1217249742 http://www.cpa-lab.com/tech/0163 未分類 Mon, 28 Jul 2008 12:55:42 GMT spok Qdmailバージョン1系にて、バージョン0系のユーザーインタフェイス系のコードを見直している。

そこで驚愕の事実がっ！

続きを読む

■コメント（0件）

■トラックバック（0件）

]]> Qdmail 1系の開発に着手 http://www.cpa-lab.com/tech/0162#tm1217062638 http://www.cpa-lab.com/tech/0162 未分類 Sat, 26 Jul 2008 08:24:16 GMT spok おかげさまで、Qdmailは、ある程度の方々に使っていただいているようです。
機能的には問題ないと思うのですが、ユーザーインタフェイスに若干難がある部分があります。
ここでむやみに変更するとバージョンによって、引数の指定方法が変わったりしてしまうので、いったんバージョン0系は開発終了とし、新たなメジャーバージョンアップとして、バージョン1系に移行しようかと思っています。

もし、こんな機能が欲しい、いらない、というのがあればぜひお教え下さい。

バージョン0系からバージョン1系への変更点（予定）

  • qd_send_mail()関数の新設
  • easy * での引数指定の変更　array('address@example.com','日本語名')方式に統一。
  • replace機能の廃止

qd_send_mail

オブジェクト指向って何？という方のために、単純な関数形式を提供します。
例え、オブジェクト指向をわかっている方でも、たぶんこれを使ったほうが簡潔なプログラムがかけるようになると思います。
これがバージョン1系の一番の目玉です。

実は0系でもコードは埋め込んではいるのですが、正しく動作しない状態です。これを完成させたいと思っています。

引数指定の変更

これまで、easyText()などのeasyシリーズではメールアドレスにつける日本語名について
$mail -> easyText('address@examplle.com','日本語名',......)
という指定方法ですが、これだと、日本語名を指定しない場合は、
$mail -> easyText('address@examplle.com',null,......)
と、nullを置く必要があり、ちょっとスマートではありませんでした。
そこで、配列の要素0にはメールアドレス、要素1には、マルチバイト日本語名、とし、マルチバイト日本語名を指定しない場合は、配列でなくてもいいようにします。
つまり、通常はこのような指定方法になります。
$mail -> easyText(array('address@examplle.com','日本語名'),......)
日本語名が必要ない場合は、
$mail -> easyText('address@examplle.com',......)
となります。
こうすることで、第1引数が to ヘッダがらみ、ということになりすっきりします。

また複数指定するときは、
$to[]=array( 'address1@example.com' , '日本語名1');
$to[]=array( 'address2@example.com' , '日本語名2');

$mail -> easyText( $to ,......)
という感じになる予定です。

replace機能の廃止

マニュアル化もしていなかったので、たぶん使っている人はほとんどいないreplace機能を廃止しようかと思っています（まだ迷っているけど）。
これを実現するのは結構面倒＆使っている人少ない、のであれば廃止しようかと。

というわけで、こんな方針でバージョン1系の開発を進めたいと思います。

■コメント（0件）

■トラックバック（0件）

]]> 0.9.0になったQdmail http://www.cpa-lab.com/tech/0158#tm1216822649 http://www.cpa-lab.com/tech/0158 qdmail Wed, 23 Jul 2008 14:17:09 GMT spok おかげさまで、先日、高機能日本語メールライブラリQdmailは、0.9.0aになりました。それなりに使えるようになっていると思います。

次回のメジャーバージョンアップでは、現在、qd_send_mail() としても使用できるよう、鋭意作業中です。

しかし、そのためには、若干、パラメータの指定方法を変えなければならない事態になりそうで、迷っています。Dynamic Drawの品格でも述べたように、ユーザーインタフェイスは、なるべく変えないほうがいいのはわかっているのですが。。。。
こういう設計は、もっと入念にやっておくべきでした。

■コメント（0件）

■トラックバック（0件）

]]> iPhoneのメールは一体どうなってしまうの http://www.cpa-lab.com/tech/0157#tm1216474531 http://www.cpa-lab.com/tech/0157 未分類 Sat, 19 Jul 2008 13:35:31 GMT spok iPhoneは個人的には魅力はないけれども、Qdmailとしては対応しておきたい。
2年縛りの端末を契約する気になれないのだけど、誰かiPhone貸してくれないかな～。

iPhoneメールについては下記サイトの方々が大変詳しく調べているのだけれど、やっぱり実機がないとわからない部分もあり、どうしましょうかね～。

【iPhone 3Gまとめ】メールはiPhone１台で複数アドレスを利用可能！-め～んずスタジオ － me-n's STUDIOさんによると、@i.softbank.jpでは、デコメの一部については受信可能とのこと。


iPhoneのメール全般については、こちらが詳しい。
iPhoneについて知っておくべきこと【メール編】-MOBILE POWER feat. iPhone

■コメント（0件）

■トラックバック（0件）

]]> Dynamic Drawの品格 http://www.cpa-lab.com/tech/0156#tm1216822629 http://www.cpa-lab.com/tech/0156 未分類 Sat, 12 Jul 2008 23:30:13 GMT spok 知る人ぞ知る有名ソフトDynamic Draw

Dynamic Draw Professional

図を書くときにいつも使わせてもらっています。
とにかく操作が直感的なので、たいへん便利。
「recursiveの正しい理解CakePHP」の図も、Dynamic Drawを使わせていただいています。

こちらの作者さんは、利用者の事を真剣に考えており、とても頭が下がります。
「直感で使える」というつくりにするのは、かなり大変だと思います。こうしたヒューマンインターフェイスが、ソフト設計では重要ですね。
これだけ便利なフリーソフトを提供していれば、様々な質問も来るかと思うのですが、それにとても丁寧に対応しています。
真に技術力のある方は、品格もあるということでしょう。

Qdmailシリーズも、メソッドを呼び出す時の引数の型や、並び順などにかなり気をつけているつもりなのですが、今から思えば、「しまった、別の指定方法の方がよかった」と思う部分もけっこうあります。しかし、一度リリースすると、インターフェイス部分は修正するのは、かえってユーザーを混乱させることになるため、なかなかできないんですね～。
ソフト内部は
結果が速く正しくでれば、構造、アルゴリズムや内部的なインターフェイスはどうでもいい。
ということなんでしょうけれども、
対人間部分は
体系的で理解しやすく、『変わらないこと』
が重要だと思うのですね。だから、ソフトの設計では、中身よりも、対人間部分を事前に検討することが大事なのでしょうね。
プロの方にとっては当たり前なのでしょうけれども、私のような者がソフトを作ると、どうしても作者オリエンティッドな、ユーザーを考えないインタフェイスを作りがちなんですよね。

こちらが処理しやすい入力をユーザー負担で求めてしまうのです。

なんせ、
人間にとって使いやすい入力　→　コンピューターにとって扱いやすいパラメータ
というヒューマンインターフェイス部分は、プログラマにとって相当の負担だろうな、と思います。

Qdmailは、そのコードの約半分を構造的には本筋ではない、ユーザーからの入力対処＆パラメータ分析に使っています。

ユーザーがプログラマでない一般ユーザーの場合は、プロトタイプをなるべく早くリリースしてユーザーからのフィードバックを得るというのは、大事なのでしょうね。
Qdmailは、対プログラマ相手なので、一般ユーザーほどシビアではないと思うのですが、それでもやはりライブラリとして統一感のあるインタフェイスを提供できているかというと、ちょっと反省点があります。


私が品格なぞ語ってはいかんのですが。
タイトルは「ホッテントリメーカー」でいただきました。

関連リンク
ファンクラブ
使い方事例
窓の杜レビュー

■コメント（0件）

■トラックバック（1件）

0.9.0になったQdmail （CPA-LABテクニカル） by spok
]]> 今の新参は昔のホッテントリを知らないから困る http://www.cpa-lab.com/tech/0155#tm1215944134 http://www.cpa-lab.com/tech/0155 未分類 Mon, 07 Jul 2008 12:51:59 GMT spok 新参者のスポックです。
はじめて知りましたホッテントリメーカー。すごくおもしろいです。。。
ホッテントリメーカー

このタイトルは、ホッテントリメーカーでいただきました。。。。

qdmailでやってみたら、、、、
  • 文系のためのqdmail入門　46 users（推定）
  • 本当にヤバいqdmailの脆弱性3つ　5 users（推定）
  • qdmailにありがちな事
  • qdmail信者が絶対に言おうとしない３つのこと　10 users（推定）
  • リア充がひた隠しにしているqdmail　15 users（推定）
  • 全てを貫く「qdmail」という恐怖　
hal456でやってみたら、、、
  • モンスターペアレントからの視点で読み解くhal456　532 users（推定）
  • これは凄い! hal456を便利にする33のツール　9 users（推定）
  • hal456で年収が10倍アップ

おもしろすぎます。
Cake PHPで制作したそうで。。。。

■コメント（0件）

■トラックバック（0件）

]]> PHPでPOP受信サーバー操作 http://www.cpa-lab.com/tech/0142#tm1215263225 http://www.cpa-lab.com/tech/0142 QdmailReceiver Sat, 05 Jul 2008 13:07:05 GMT spok メールの受信(POP)サーバーの操作ライブラリ＆マルチバイトメールデコーダーのご紹介。

簡単受信サーバー操作ライブラリQdmailReceiver
hal456トップページ

応用すれば、こんなことができます

  • 空メール処理
  • ブログへのメール投稿
  • Spamフィルター
  • gmailライクなWEBメール

もちろん、QdmailReceiverは、メールを解析したり、ＰＯＰサーバーを操作するライブラリなので、上記のことをやろうと思えば、他に自分でプログラムを組まなくてはなりません。
しかし、マルチバイト（日本語処理）やメールの解析処理は意外にやっかいなので、それをQdmailReceiverに任せていただければ、かなり労力半減することでしょう。

■コメント（0件）

■トラックバック（0件）

]]> CakePHP(RC1.2)のemailコンポーネントで日本語はまだ厳しい http://www.cpa-lab.com/tech/0141#tm1215038885 http://www.cpa-lab.com/tech/0141 cakephp Wed, 02 Jul 2008 12:40:42 GMT spok

■CakePHP(1.2RC2)のemailコンポーネント評価

CakePHP 1.2 RC2 がリリースされたので、新しいemailコンポーネントを評価してみた。全般的に言えば、改行コード＆英文周りはかなり改善されており、英語メールを送る分には、大丈夫かと思う。
しかし、一部でマルチバイト非対応となっており、日本語の場合、若干の問題点がある。
  1. Content-Transfer-Encoding:ヘッダーは7bit固定＆charsetはutf-8なので、charsetをiso-2022-jpに変更し、本文、ビュー、レイアウトのすべてを自前でiso-2022-jpに変換する必要がある。*1
  2. ワードラップ処理がマルチバイト非対応
    __wrapメソッドがマルチバイト非対応なので、文字化けする可能性が大きい。また、「日本語文字列のバイト数取得にstrlenだけではダメな理由-PHP」でも述べたとおり、マルチバイト環境では、文字列のバイト数を得るのに、strlenだけを使うのは、問題がある。
  3. MIMEエンコードが、マルチバイト文字の途中で強制改行される可能性のあるスクリプトとなっており、長いsubject＆Gmailやbeckeyでタイトルが文字化けする可能性が大きい。*2
  4. qmail用がデフォルト？
    mail関数で送る際には、MTAがqmailであればLF,qmail以外のsendmailやPostFixであれば、CRLFである必要があるが、LFがデフォルトとなっている。
    これはこれで賢いやり方で、CRLFをデフォルトにするとqmailの時にエラーがでるけれど、ＬＦがデフォルトであれば、sendmailやPostFixがエラーを出すことはないだろうからだ。
  5. SMTP送信の場合、　名前＜address@example.com＞　の形式が使えず、＜address@example.com＞　というメールアドレスのみのヘッダーとなる。
    う～ん。どうしてこうしたのでしょうかね。

その他の制約

  • 本文base64エンコードできない。
  • Quoted-Printable非対応
  • デコメ送信不可能*3
  • MHTL(インラインHTML)メール不可
  • 添付ファイルの日本語不可

全般的な感想

相当がんばれば、デフォルトでも日本語は送れないことはないと思うけど、メールひとつ送るのに、がんばりたくないでしょ。

う～ん。mb_send_mail単体のほうがましかな。

Qdmailなら。。。。

高機能マルチバイトメールライブラリQdmailなら、CakePHPのコンポーネントとしても動作します。
上記のemailコンポーネントの弱点はすべて克服されておりますので、一度お試し下さい。

*1 : 7bitなのに、8bitコードのUTF-8をデフォルトにするのはよくないです。。。

*2 : 私もハマったところ

*3 : これは仕方ないよね

■コメント（0件）

■トラックバック（0件）

]]> mb_encode_mimeheaderの都市伝説を検証する http://www.cpa-lab.com/tech/0153#tm1216308130 http://www.cpa-lab.com/tech/0153 php5 Tue, 01 Jul 2008 12:50:35 GMT spok

■mb_encode_mimeheader都市伝説

mb_encode_mimeheaderは、なんか使いにくい。文字化けする。とあまり良い評判を聞きません。私も、「使うのはちょっと怖いな」と思っていました。しかし、mb_encode_mimeheaderは正しく設定すれば、きちんと働いてくれます。それを検証したいと思います。

間違ったバッドノウハウ

mb_encode_mimeheaderの有名なバッドノウハウに
PHPmb_encode_mimeheaderは事前にmb_internal_encodingが必要-akiyan.com
というのがあります。その中身は
PHPのmb_encode_mimeheader関数で文字列をエンコードするときは、直前にmb_internal_encoding関数で変換したい文字列のエンコーディングをセットしてから呼ばないとうまく動作しないもよう。エンコードした文字列の後ろのほうが化け化けになってしまう。
というものです。
そして、
// 元のエンコーディングを保存
$orgEncoding = mb_internal_encoding();
// 変換したい文字列のエンコーディングをセット
mb_internal_encoding($targetEncoding); 
// エンコーディング実行
$encodedString  = mb_encode_mimeheader($targetString, $targetEncoding, 'B', "\n");
// 保存しておいたエンコーディングに戻す
mb_internal_encoding($orgEncoding);
というコードが掲載されています。
それを検証しようとした、
mb_internal_encoding()は必須か?」に対しての疑問と検証-よくきたblog
というのもあります。

しかしながら、このバッドノウハウは間違っており、検証した方も、残念ながら、検証になっていません。

正しいバッドノウハウ

そこでPHP5.2.4のソースコードを読みつつ、動作検証をしてみました。
その結果、mb_encode_mimeheaderを使う時の正しいバッドノウハウは、
mb_encode_mimeheaderに渡す文字列の文字コードとmb_internal_encodingは一致させておかなければならない。
というものです。
必ずしも、最終のターゲットエンコーディングとmb_internal_encodingを一致させる必要はありません。
ん、最初のノウハウと何が違うのかって？
次章でよ～く考えてみましょう。

結論から

文字コードが３つでてきますので、整理しましょう。
  1. mb_internal_encodingの文字コード
  2. mb_encode_mimeheaderに渡す文字列の文字コード
  3. mime変換する最終文字コード
この中で、１と２が一致している必要があるだけであって、３は独立していてＯＫです。
２→３の文字コード変換は、mb_encode_mimeheaderがきちんとやってくれます。
正しくいえば、mb_encode_mimeheaderは「２の文字コードは１と同じであるとして、１→３のパラメータでもって、２の文字列を変換」します。つまり、　

mb_convert_encoding($word,$target_encoding,mb_internal_encoding());

という動作が、mb_encode_mimeheaderには含まれています。
（特殊な条件の時のみ、無変換となる）
間違っているバッドノウハウは、１と３を一致させようというもので、２についての言及がありません。偶然に２についても同じ文字コードであれば文字化けすることはないのですが、２が（１,３）と違うコードの場合、正しくエンコードされません。
1=2となるように、文字コードを設定しましょう。
（さらに、mb_languageもjaに設定しておけば間違いがありません。）

本来は、mb_encode_mimeheader関数にて　2の「渡す文字列の文字コード」を指定できるような仕組みがあればいいのですが、残念ながらそうなっていません。
１のmb_internal_encodingを指定することで、2の「渡す文字列の文字コード」を間接的に指定することになります。
注
この結論は、下記テストコードと、PHP5.2.4本体のmb関係のソースを読んでのことですが、C言語のソースは私も理解できない部分もあり、結論が間違っている可能性もあるかも知れません。その際はご指摘いただければ幸いです。

■テストコード

続きを読む

■長文でテストしてみる。

続きを読む

■PHPの本体コードを読んでみる。

続きを読む

■WEB上の間違った情報（主なもの）

以下は、googleで、mb_encode_mimeheader のキーワードで検索した時に、比較的上位に出てくるページや、他に多く引用されているページにつき、私の見解を書いています。決して、けなしているわけではありません。ただ、私の得た結論が正しいとするならば、間違った情報をそのままにしておくと、また私のような無駄な時間を費やしてしまう人がでてくるであろう、という予測のもとに、「この情報は私が正しいと思う結論に対して、間違っている」ということを指摘するものです。
PHPのバージョン違いによるものもあるかも知れません。私が検証したのはPHP5.2.4ですので、それより前のPHPでは挙動が違うのかも知れません。（一応、PHP4.4.7でもテストコードを動かしてみて、結論は変わらないという心証はえているのですが、4.4.7についてはPHPソースまでは読んでいません。）
またPHP5.2.4であっても私の見解が間違っている可能性もあります。その際は、ご指摘いただければ幸いです。

この記事の冒頭で紹介したページです。1=3という間違った結論です。多くのWEBサイトがこのページを引用しています。この記事のバージョン5.1.2ではこうだったのでしょうか？
私と同様の疑問を持ち、akiyan.comさんの記事を検証しています。しかし、環境が、internal='euc-jp',input='utf-8',target='utf-8'では文字化け、internal='utf-8',input='utf-8',target='utf-8'で文字化けなし、ということを検証しているのみで、十分ではありません。
1=2=3と設定しないと文字化けする、という間違った情報です。丁寧に「mb_encode_mimeheader() ですが、文字コードの変換まではしてくれない為」と書かれていますが、これも間違いです。上のほうに書いたように、むしろ原則として、文字コードの変換をします。

非常に有益なテストコードです。この記事の次の記事の方が
しかも、これらの結果が異なるんですね。
mb_encode_mimeheader($str, 'ISO-2022-JP');
mb_encode_mimeheader(mb_convert_encoding($str,'JIS','EUC'),'ISO-2022-JP');
と述べていらっしゃいますが、mb_internal_encoding('EUC-JP');なので、スクリプトをEUC-JPで保存していれば、上段は1=2となり正常稼働しますが、下段は1≠2なので当然文字化けします。もし、このスクリプトをUTF-8で保存して実行すれば、上段も文字化けするでしょう。
また、同じスレッドで、
mb_encode_mimeheader 自体は、文字コードの変換はしてくれないと思っていたんですが。
という発言もありますが、このように思っている人は多いのではないでしょうか。
繰り返しになりますが、原則として文字コードの変換がなされます。

こちらは逆に、「mb_encode_mimeheader()に渡す文字列はISO-2022-JPに変換するな。」という結論を導いていらっしゃいますが、間違いです。最初のスクリプトが、１≠２になっているだけであり、2=iso-2022-jpとしているからではありません。しかも、次のスクリプトでは、1=2=iso-2022-jp と設定し、結果も正しいのに、「mb_encode_mimeheader()に渡す文字列はISO-2022-JPに変換するな。」というのは、論理的に正しくありません。mb_encode_mimeheader()に渡す文字列はISO-2022-JPに変換しても、１＝２を守る限り大丈夫です。

正しい考察
PHPのmb_encode_mimeheaderは事前に-ryuzi_kambe の？Ｄ
こちらは、私と同じ結論です。そちらにも書いてある通り、mb_encode_mimeheaderに”from-encoding”を指定するパラメータがないのが、混乱のもとになっていると思います。

混乱する考察
mb_encode_mimeheaderについては、そのソースコードのエンコードを書いていないスクリプトの場合、情報が不足するため混乱の元となります。mb_encode_mimeheaderに言及する多くのWEBサイトでは、ソースコードの文字コードに触れおらず、暗黙のうちにEUC-JPやShift_Jisが前提だったりします。
おまけに、inputされる文字列の文字コードさえも記載のないページもあります。
そのようなページはあまりに多いので、ここでの引用は省略します。

開発者さま

ぜひ、このようなバッドノウハウをなくすために、mb_encode_mimeheaderにて、引数に渡す文字列のエンコードであるfrom-encodingを指定できるようにお願いいたします*2。
たったこれだけで、この大混乱を収束することができます。。。


しかしながら、マルチバイト関係のPHP本体のソースをみると、すごく複雑です。c言語で、マルチバイトを自在に処理するのは至難の業ですね。mb_convet_encodingをおっかけると、あの組み合わせの多さに、それだけで萎えてしまいます。それに果敢に挑戦された開発者の方はすごいです。mb*関係に係わった関係者の方々に感謝と尊敬の意を表します。


*2 : こういうのってどこに要望ださばいいのだろう

■覚書

続きを読む

■コメント（2件）

ELF『よくきたblogな人ですが，私の件の記事は網羅性は高くないです． もっと細かいことを書いたものがありまして，「超・極める! PH...』(2008/07/15 17:01)
spok『ELFさん はじめまして。プロの方からコメントをいただけて光栄です。 私の記事が間違っていなかったようで安心しております。 さっ...』(2008/07/17 24:22)

■トラックバック（0件）

]]> PHPの日本語デフォルトコードはEUC-JP http://www.cpa-lab.com/tech/0154#tm1214916635 http://www.cpa-lab.com/tech/0154 未分類 Mon, 30 Jun 2008 15:27:30 GMT spok php.ini が
mbstring.language = Japanese
であり、かつ、mbstring.internal_encodingが未設定の場合、PHPは、mbstring.internal_encodingが、文字コードEUC-JPであるとみなして動作する。*1
ちなみに、languageの設定さえない場合は、ISO-8859-1のようだ。

時代は、UTF-8だと思いますので、UTF-8でソースコードを書く時には、
mbstring.internal_encoding　= UTF-8
を忘れずに。

可搬性を重視した場合

他の環境でも動作させることを考えれば、これらの項目は、php.iniで設定するのでなく、自分のスクリプトの初期設定で行うほうがよい。だって、レンタルサーバーであれば、languageの設定がjapaneseと保証されているわけでもないし、文字コードもphp.iniでどう設定されているかは、千差万別（のはず）だからだ。
よって、日本語のコードであれば、必ず初期設定スクリプトで、
mb_language( 'ja' );
mb_internal_encoding( 'UTF-8' );
を設定しましょう。

なぜ今？

何を当たり前のことをお思いでしょうけど、mbstring.internal_encodingを未設定、またはEUC-JPのままで、UTF-8でコードを書くと思わぬ誤動作が生まれる可能性がある、ということで。。。。次回に続く。

*1 : PHP5.2.4 PHP_RINIT_FUNCTION mbstring-mbstring.c

■コメント（0件）

■トラックバック（1件）

mb_encode_mimeheaderの都市伝説を検証する （CPA-LABテクニカル） by spok
]]> SMTP送信を使うべき3つの理由-PHP http://www.cpa-lab.com/tech/0151#tm1214400096 http://www.cpa-lab.com/tech/0151 qdmail Wed, 25 Jun 2008 13:06:01 GMT spok

■さらば、mail,mb_send_mail関数

続きを読む

■コメント（0件）

■トラックバック（0件）

]]> mail関数(PHP)のハマりどころ http://www.cpa-lab.com/tech/0149#tm1214399161 http://www.cpa-lab.com/tech/0149 qdmail Tue, 24 Jun 2008 15:12:41 GMT spok Qdmailは原則としてPHP標準のmail関数を使用している*1。
このPHPのmail関数は何かとクセがあり*2、特に改行コードでは苦労させられた。
マニュアル(mail)を熟読すれば、載っていることばかりだけど、今後のために整理しておく。

改行コード

インターネットメールの世界では、改行コードは原則として、CRLFである。それは、RFC2822を参照されたい。SMTPサーバーに直接渡す時は、これでＯＫ。
しかし、PHPのmail関数には時と場合により、LFで渡さなければならない時がある。
特に、ヘッダーと本文の改行コードは分けて考える必要があるので、注意すること。
mail関数の改行コード注意点
  • 本文の改行コードはLFで渡すこと*3。
  • ヘッダーの改行コードは、原則としてCRLFだが、MTA（送信サーバー）によっては、LFで渡さなければならない場合がある。現在、LFで渡さなくてはならないMTAは、qmailであることが判明しているが、他もあるかも知れない。qdmailとqmailをごちゃごちゃにしないよう留意を。

混乱しがちな点

本文はLF。
subject以外のヘッダーはCRLFで渡さなくてはならないのが、面倒なところ。

たぶんlinux,unix系のサーバーは、OS標準の改行コードがLFであることから、このようにしているように思うけど、それならヘッダーもLFで渡すようにすればいいのに。。。。

こちら（PHPのmail()のできの悪さ-よくきたblog）でもご指摘ありますが、ちょっと、その実装は。。。。

Windows版の制限

to引数
Windows版のmail関数は、第1引数のtoでは、
name<address@example.com>
が使えず、
address@example.com
しか許されない。
私の環境では、sendmaneというsendmailのラッパーを使わせていただいてるので、この制限はないけれど。
ピリオドだけの行
PHP が SMTP サーバと直接通信をする際、ピリオドから 始まる行は無視されます
FromとReturn-Path
Windows では、From ヘッダを設定すると Return-Path も設定されます。

送信サーバーがqmailかどうかの判別

Qdmail0.8.6aでは、ini_get('sendmail_path');でもってPHP.iniのsendmail_pathを読み取り、そこに、qmailという文字列があるかどうかで判別している。
これだと誤判別もあり得るので、他にもっといい判別方法があったら、ぜひ教えて下さい。

参考にさせていただいたサイト

qmail の RFC 違反
PHPのmail()のできの悪さ-よくきたblog

*1 : SMTP送信もできるけど

*2 : PHPのせいじゃない部分も多々あるけど

*3 : PHPがCRLFに変換するようです。

■コメント（0件）

■トラックバック（1件）

SMTP送信を使うべき3つの理由-PHP （CPA-LABテクニカル） by spok
]]>