🚀 go-pugleaf

In article <7bqhn6.vq5.ln@sou.nerv.org>,
  Kazushi (Jam) Marukawa <jam@pobox.com> writes:

> ああ、subjectのエンコーディングの罠が(笑)。
> セキュリティの最後の「ィ」が"%#\e(B"なんだけど、
> 今使ってるtinだと、"...=25?= =?...?=23=1B=28B?="
> とエンコードされてます。酒井さんのメイラは、
> それをデコードする時にスペースを取り忘れてます。
> ただ、tinも一行が長いままなんで問題あり。

あー, tin の問題はそんな簡単な話ではないようですけど。
<7bqhn6.vq5.ln@sou.nerv.org> ではなんとエスケープシーケンスの途中でぶっ
た切ってますね。これは tin が Subject の文字列を ISO-2022-JP にのバイ
ト列に変換した「後」に encoded-word に分割していることを示しています。

しかし, 本当は encoded-word に分割する場所を決めるのは, 文字列からバイ
ト列に変換する「前」に行なわなければいけません。これは encoded-word が
(バイト列でなく)文字列を表すもので, 文字と文字の境界で分割しなければい
けないからです。

# ちなみに, 分割する時は, 変換した「後」の行の長さが 76byte を越えない
# ように分割しなきゃいけません。
## さらに charset が ISO-2022-JP 決めうちでなく, 最小の charset を適切
## に選ぼうなんて考えると... まぁ, かなり厄介な話になるのはたしかです。
-- 
[田中 哲][たなか あきら][Tanaka Akira]