Namazu-devel-ja(旧)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 長い単語の排除
寺西です。
Tadamasa Teranishi wrote:
>
> > オプションの整理を行なったのは高林さんなのですが、その時にはそれらの
> > フィルタにだけ適用すればあとは不要だろう、という判断があったようです。
...
> -u に関しては、少々事情が異なるかと思ったわけです。メールに添付
> することは多いのですが、単体のファイルとして存在することも
> ありますし、各種ドキュメントファイルの中に存在することも、少なからず
> あるように思います。
uuencode_filter() をのぞいてみたところ、uuencode のブロック、BinHex
のブロック(?)を丸ごと削除するようになっていました。
この仕様ならメールとMHonArcでのみ働くようにしてあるのは、妥当だと
納得しました。
HTML などに uuencode されたものが含まれる場合は、uuencode の全体が
含まれることはあるでしょうが、その最初の部分のみが引用されることも
多いと思われます。このため、uuencode のブロックが完全な形で含まれる
場合にのみ削除されるというのでは、HTML の場合は不十分な気がします。
(メールやMHonArcは妥当)
行単位で判断するものであればよかったのですが、正確に判断するのは
そもそも難しいことですから、それは無理なようです。
やはり、$WORD_LENG_MAX = 60 で削除するのが、合理的ですね。
> > > 普通の HTML ファイルにも存在する可能性はあるし、テキスト(Word や
> > > PDF等も)にも入っているケースもあると思うので、オプションで排除
> > > できるとうれしいのですが...。
> >
> > utils.pl あたりに移して、generic に利用可能な関数とした方がいいのか
> > も知れません。
上記の理由により、これは必要ないということで。
> HTML に PGP等の公開鍵をつけている場合もあるかと思いますので、-u が
> 復活すると良いなぁと個人的には思っています。
> uuencode_filter() で、PGP等の公開鍵まで排除できるかどうかは確認できて
> いませんので、少し調べてみます。
PGP 公開鍵に関しては Base64 ライクなエンコード + CRC でした。
公開鍵の場合は、全体が HTML に含まれることが多いとは思いますが、
個別に解析するよりは、$WORD_LENG_MAX = 60 で削除するのが合理的で、
実害も少ないように思います。(URL 文字列の処理は考えなければならない)
--
=====================================================================
寺西 忠勝(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