たとえば Perl で書かれた CGI script, それも掲示板なんかには、 -こんなくだらない code が載っていたりします。
+こんなみっともない code が載っていたりします。
jcode'convert(*from, "jis");
@@ -49,8 +49,8 @@
my $msg = new Message::Entity;
my $hdr = $msg->header;
$hdr->add ('From')->add ('me@bar.example');
-$hdr->add ('To')->add ('foo@bar.example', display_name => 'Mr. foo');
-$hdr->add ('Subject' => $subject);
+$hdr->add ('To')->add (['foo@bar.example', display_name => 'Mr. foo']);
+$hdr->add (Subject => $subject);
$msg->body ($body);
# $smtp->send は SMTP で送信する method と仮定。
@@ -60,20 +60,12 @@
CPAN を探すと、
これに似たようなことができそうなモジュールはあるようですが、
実際に使ってみると、与える値によっては RFC 822/2822 に違反する
-結果を出力するなどの不満があります。 (例えば今の例で
-To: 領域に使っている
-display_name で「.」が含まれますが、
-RFC 2822 的には新しいメッセージでは互換性のため
-quoted-string
-にする必要があります。しかしそのまま出力されます。)
-
-参考: 「.」の場合は RFC 2822 的には正しく解釈
-されなければなりませんが (出力はすべきでない)、
-これ以外の文字、例えば制御文字 ESCAPE でも同じようになります。
-こちらは完全に間違いです。
-参考: 実装方針としては不正な値はモジュールに
-渡す前に弾くべきという考え方もあるでしょう。
-でもそんなのは不便です。
+結果を出力するとか、そもそもそれ以前に、
+$hdr->addr ('Foo Bar <foo@bar.example>')
+のようにメッセージ形式をモジュール内に隠匿しきれていないとか、非
+ASCII 文字を考慮していないとかの不満があります。
+
+(実装方針としては不正な値はモジュールに渡す前に弾くべきという考え方もあるでしょうけど、一般的な利用に際しては賢い設計だとは思えません。)
ということで、はじめは既存のモジュールの wrapper (あるいは補完)
を書くつもりでしたが、なんだかごちゃごちゃしていて、
@@ -82,40 +74,54 @@
特色 (という程のものでもない。)
-- 結構(謎)オブジェクト指向です。
+- 結構オブジェクト指向です。
- RFC 822/2822 の
group を解釈出来ます。
- draft-ietf-usefor-msg-id-alt-00 に基づいた送信アドレスなどによる
Message-ID を生成出来ます。
- 文字コード独立 (CSI) です。 (但し RFC 822 である都合上(謎)、
-ASCII 互換である必要はあります。 EBCDIC とかは無理です:-<)
+ASCII 互換である必要はあります。 EBCDIC とかは無理です:-<
+(というのはメッセージ構造の部分のことです。
+MIME を使って EBCDIC などをメッセージ本文に入れることは可能です。))
+- MIME (RFC 2045,
+2046) にほぼ完全に対応しています。
各仕様への対応状況
- 電子メイルのメッセージ (RFC 822, RFC 2822)
-の全機能に (抜けが無ければ) 対応しています。
-但し長さ制限などはチェックしていません。 (MIME の
-
Content-Transfer-Encoding
-と一緒に実装予定)
+の全機能に対応しています。
- 電子ニュース記事 (RFC 1036,
son-of-RFC1036,
draft-usefor-article (06)) の頭領域の多くに対応しています。
-- MIME の本体部分 (body part) にはまだ対応していません。
-- MIME の追加頭領域
+
- MIME の本文部分 (body part) に対応しています。
+
+ - 多部分 (multipart) や分割 (message/partial),
+ 外部本分 (message/external-body) を扱うことが出来ます。
+ - text/plain; format=flowed
+ (RFC 2646)
+ に対応しています。
+ - Content-Transfer-Encoding は Base64, Quoted-Printable
+ は勿論、 x-uuencode, x-gzip64 にも対応。
+ RFC 2822 メイル出力モードでは、本文が8ビットでも自動的に適切な
+ CTE で符号化します。
+
+
+- MIME の頭領域
(RFC 2045,
Content-Disposition) に対応しています。
パラメーター値拡張 (RFC 2231)
も入出力ともに実装しました。
- MIME 符号化語 (
encoded-word)
-の解読に対応しています:-) 但し別途変換処理を指定する必要があります。
-(文字コードの扱い参照)
+の解読に対応しています:-)
- HTTP/1.0, HTTP/1.1, CGI/1.1, CGI/1.2 の頭領域のうち、
ごく一部に対応しています。 MHTML の
Content-Location にも対応しています。
- 日付形式では RFC 822/1123,
RFC 733, asctime, ISO 8601 (HTML)
-などに対応しています。
+などに対応しています。日付の出力は sprintf
+の様な書式文字列を与えることで、多種多様な形式に対応。
+- X-Moe シリーズに対応しています:-)
制限事項
@@ -127,11 +133,14 @@
保持しています。ですからあまり大きなメッセージの処理には
向いていないでしょう。
CR や LF が単体で出現する場合、
-正しく処理出来ません。 (CRLF と等価とみなします。)
+正しく処理出来CRLF と等価とみなします。)
将来の版ではオプションで制御可能になるかもしれません。body) の実装。Message-ID の生成にこれらを使用する場合のみ、
- Message::Field::MsgID::MsgID が使います。
Message::Field::MsgID が使います。
これらが用意されていない環境ではエラーになるので、 (現状では) 上記モジュールの該当部分を書き換えて対処して下さい。
ちなみに、 Quoted-Printable や RFC 2231 の + % 符号化は自力で復号します。
+日本語メッセージを扱うなら必須でしょう。 詳しくは文字コードの扱い @@ -195,6 +208,7 @@
卑しいことで頭を悩ますのは嫌なので(藁)、
+[[ →手っ取り早く方法だけ読む。 ]]
Message::* は符号化方法独立 (CSI) を目指して実装しています。
(但し ASCII のしがらみだけは断ち切っていません:-))
0x00 〜 0x7F が ASCII (または ASCII と見なして良いもの) である
@@ -270,6 +284,7 @@
何も処理しません。) これ以外の場面では、 *default
で定義された関数が使われます。
ややこしい説明をしてきましたが、実際面倒なので、日本語文字コード変換に良く使われる、 +jcode.pl や Jcode.pm などのための設定は予め用意してあります。
+ +
+## どちらか好きな方をどうぞ。
+use Message::MIME::Charset::Jcode 'jcode.pl';
+use Message::MIME::Charset::Jcode 'Jcode';
+
+
+この1行だけで、 ISO-2022-JP, EUC-JP, Shift_JIS +および幾つかの関連 charset が利用可能になります。
+ +Perl 5.8 になって Encode モジュールが使えるようになれば、 +もっと色々な文字コードが楽に利用できるようになると期待しています。
-Perl 5.8 で Encode モジュールが使えるようになれば、 -もっと楽になると期待しています。
+ところで、このように charset 対応処理をしなくても、 +MIME で charset 札付けされてメッセージに含められている未知の +charset のデータが破壊されることはありません。 (はずです。) +(そこいらが、 Unicoder のソフトウェアとの違いです(笑)。)
-