Namazu-devel-ja(旧)

[Yukio USUDA <m6694ha392t@xxxxxxxxxxxxxxx>]

臼田です。

Tadamasa Teranishi wrote:

> > quated-print部分はMIME::QuatedPrintがあればデコードすることにしました。
> > base64部分はMIME::Base64があっても通常では無視することにしました。
> 
> ん? このように動作する意味は何かあるのでしょうか?
> (base64 と quated-print を区別する意味)
> 添付ファイルの展開は、デフォルト禁止で、スイッチを入れれば
> 展開可能というのが良いかなと思っていたのですが...。

「Quoted-Printable encodingは、大部分US-ASCII文字セットの印字可能な文
字に相当するオクテット（8ビット）からなっているデーターを表現するよ
う考えられています。」rfc2045の和訳より
http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc2045j.html
というものなのでマルチバイト文字部分以外はそのまま読める状態です。
基本的にテキストであること（多くはhtmlでしょう）から積極的に捨てる
こともないだろうと考えました。

base64はなにが入っているかわからないので必要と判断した方のみ利用するのが
よかろうと考えました。

InternetExplorerが吐き出すmhtファイルを見ていたらhtmlと画像ファイルとで
エンコード方式を使い分けていたので分けてみたものです。

あまり深く考えてはいませんので、動作のわかりやすさをとるほうがよければ修正
します。


実はwin32-oleフィルターにマクロウィルスつきのms-wordファイルが渡ったときに
マクロが動き出すのではと不安だったのでbase64はデフォルトで展開しないことに
したほうがよいかとも考えました。
oleフィルターがどのような仕組みで動いているのか知らないので詳しい方のご意見
をいただきたいです。


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


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

昨年このメーリングリストで話題が出て
最終的に添付ファイルの名前をインデックスに入れるのは保留にしたよう
ですので気にはなっていました。

今の処理では添付ファイルのuriはファイル形式の特定のみに使い
後は使わずに捨ててしまっています。
拡張子だけ無事であればよいと考えておりました。
（渡した先のフィルターで本文に追加していれば入ってしまいますが）
このあたりは改善の余地ありです。


> 　 日本語のファイル名に関しては RFC で決まる前に、
>    いろいろなエンコード方式のメーラが普及してしまっているからで、
>    きちんと処理するのは結構面倒です。
> 　 ちなみに 1行で表現できない長い文字列の場合は、複数行に分割され
>    ることもあります。
>    
> 　 少々古い内容ですが、
>    http://www.emaillab.org/essay/japanese-filename.html
>    に、詳しい説明があります。
mhtmlに対応したフィルタにしようと思ってはじめたので、
rfcはいくつか流し読みしましたが、メーラー毎の違いは研究しておりません。
rfc2231も読んでいませんでした。
上記のページを読み勉強しようと思います。

複数行にデコードされるようなURIを持った添付ファイルが
ちゃんと処理できるのかなどはサンプルを作って
検証をする必要がありそうですね。

臼田幸生