Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Yukio USUDA wrote:
> 
> > > ・標準ではbase64は無視し、デコードしたい場合はオプションで
> > > 　指示するほうがよい？
> 
> quated-print部分はMIME::QuatedPrintがあればデコードすることにしました。
> base64部分はMIME::Base64があっても通常では無視することにしました。

ん? このように動作する意味は何かあるのでしょうか?
(base64 と quated-print を区別する意味)

添付ファイルの展開は、デフォルト禁止で、スイッチを入れれば
展開可能というのが良いかなと思っていたのですが...。
 
> > > ・画像等はデコードせずに無視するほうがよい？
> とりあえずContent-Typeが image/* のものだけは常に無視することにしました。
> 
> 以上の修正をしてHEADにcommitしました。

少し中身をみて気になった点をあげておきます。

1. $has_base64 が undef の場合、base64_filter, quotedprint_filter を
   を通った後、$body が空になりますが、そのまま後の処理に流れて
　 しまっています。この結果、中身が空にもかかわらず nesting_filter
   が呼び出されているようです。呼び出し先でエラーになるので、
   実害はないのですが、$body が空の時点で skip した方が良いのでは
　 ないかと思います。

2. 添付ファイルのファイル名の扱いについて、現状はそのまま使って
   (nkf でデコードされた結果)いますが、実はここは結構やっかいな
   ところです。
   現状の処理は妥当だと思いますが、おそらく将来、ファイル名が
   正しくないといった問い合わせが来ることでしょう。
   (それどころか、ファイル名を後のフィルタが使うので、重要かも
   しれない)

　 日本語のファイル名に関しては RFC で決まる前に、
   いろいろなエンコード方式のメーラが普及してしまっているからで、
   きちんと処理するのは結構面倒です。
　 ちなみに 1行で表現できない長い文字列の場合は、複数行に分割され
   ることもあります。
   
　 少々古い内容ですが、
   http://www.emaillab.org/essay/japanese-filename.html
   に、詳しい説明があります。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E