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