[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[kagemai-users:0390] Re: 通知メールの Subject にステータスなどを入れる方法
福岡です。
"Sakuragi Yukari" san wrote:
| しかし、これを見習って、
| attriの一要素がフルパスの場合、そのフルパスを文字列操作して
| 一部だけとりだしたときに邪魔なスペースが入ります。
|
| ○データ例
| netpath : C:\test\soft-AA-BB-050110-01
| status: 未定
| title: いらないスペースが入る
|
| だったとして、これらがメールの件名として期待されるものは
|
| [Bug:01] 未定 soft-AA-BB-050110-01 いらないスペースが入る
|
| です。
| しかし、実際は
| [Bug:01] 未定 soft-AA- BB-050110-01 いらないスペースが入る
これについての短い答えは、「メールのタイトルなんてそんなもの」です。
それで納得いかない場合には以下の長い説明をどうぞ。
まず前提なんですが、メールを送るときの１行の長さについて、RFC 2822 の
"2.1.1 Line Length Limits" に、以下のように書いてあります。
> There are two limits that this standard places on the number of
> characters in a line. Each line of characters MUST be no more than
> 998 characters, and SHOULD be no more than 78 characters, excluding
> the CRLF.
つまり、78文字以内であることが推奨されているわけですね。
次に、日本語を含むヘッダフィールドについては、RFC 2047 にしたがって
エンコードを行います。
たとえば、"[Bug:01] 未定 soft-AA-BB-050110-01 いらないスペースが入る" を
エンコードすると以下のようになります。
[BUG:01] 未定 soft-AA-BB-050110-01 いらないスペースが入る
これで、長さは111文字になります。
（実際には先頭に 'Subject: '、がつくので、120文字。）
長い行を複数の行に分ける方法も RFC 2822 に書いてあって、
影舞もそれにしたがって長い行を複数行に分けて送ります。
もっとも、影舞はエンコード後の長さの計算がかなりいいかげんで、
実際にはエンコード後に78文字を越えない場合でも適当に分割する
ことがありますが。
ちなみに、影舞の処理だと先ほどの例は以下のように分割されます。
[BUG:01] 未定 soft-AA-BB-
050110-01 いらないスペース
が入る
２行目以降は先頭に空白が入っていて、この空白によって、行が
連続していることをあらわすことになってます。
メールを受信した MUA は分割された行を１行にもどすわけですが、
行間の改行を削除するだけです。つまり、分割された行の先頭にある
空白はそのまま残ります。これが、今回 "いらないスペース" として
気にされているものです。
もっとも、RFC 2822 ではそれを考慮して分割はスペースの位置で行え
と書いてあります。しかし、英語はともかく、日本語の場合には適当
な位置にスペースがあることは期待できません。そのため、影舞では
スペースを考慮せずに適当に分割しています。
＃ 正確にはまったく考慮しないわけではなく、もっとも分割したい位置
＃ に近い日本語の文字の間や、スペース、'-' などの位置で分割します。
もっと洗練された分割のアルゴリズムを実装することもできるでしょうが、
あまり意味がないと思うので今のところその予定はありません。
もちろん、今の私の知識が間違っていて、修正するだけの根拠を誰か
が示してくれればその限りではありませんが。
今回のケースでは、subject にファイルのパスを入れるので、パスの
中にスペースが入るのは困るということなんだと思いますが、パスが
長くなれば、より洗練された分割のアルゴリズムを用いても、パスの
途中で分割されて復元時にスペースが入ってしまう可能性は高いと
いえます。
というわけで、「メールのタイトルなんてそんなもの」です。
--
福岡ともゆき <fukuoka@xxxxxxxxxxxxx>
http://www.daifukuya.com/