Namazu-devel-ja(旧)

["Komai @home" <GFH05144@xxxxxxxxxxx>]

komaiです。

Tadamasa Teranishi さんは書きました:
>長さ72,76 の Base64 っぽい記号 に関しては、削除したいですね。
このあたりは、uuencode、ish等は、削除されるとのことですから、
Base64もついでに、、というのは難しいでしょうか？

>長さ128 の URL系 に関しては、128以上のものが打ち切られている可能性
>もあるので、何らかの特別な対策が必要ではないかと思いました。
>128文字以上の URL もきちんと扱えるようにするのか、URL は排除する
>のか。文字列の長さに関わらず同じ動作になるのが良いように思います。
>また、日本語ドメインを考えると同じ動作を行うのは難しいような
>気もします。
URL系については、いろいろ考えると
○ドメイン名的な英語文字でしか検索しないのではないか？
なんて考えてしまいますね。。
（例えば、あるサイトのURLを検索したいときには、
その中のうろ覚えのドメイン名で検索するとか。
そうであれば、-Kオプションで済みますね。）

 
>> 例1 BASE64らしき記号
>> kqwaacomaaardaaalawaac0maaaudaaalwwaadamaad9/f39/f39/f39/f39/f39/f39/f39
>
>"kqwaacomaaard*" 等で検索して元ファイルを特定すると、元ファイルが
>どういった形式のファイルなのかが分かると思います。
>もしかすると、そのファイルの処理にバグがあり、デコードできていない
>のかもしれません。
これは、検索した結果、やはりWordをBase64でエンコードした電子メールでした。



>> 例2 単なる記号？
>こちらについては、全角記号を削除するオプションを考えています。
>-K オプションの全角バージョンのようなものです。ただし、連続して
>何文字以上続く場合といった数を指定できるようになっていると良いのでは
>ないかと思っています。現在、仕様を検討中で、削除対象文字の選別を
>行っています。
これは、確かに良いですね。単なる記号列は、めったに検索しないのですが、
もしかすると、半角の/、:等の記号よりも、全角記号の方がさらに
あまり意味のないものが多い、、（と個人的に感じるだけなのかもしれませんが）
ような気がします。

例：自分の電子メール中のNMZ.wのごく一部例です。
┗…┗…┗…┗…┗…┗…┗…┗……‥
┗…┗…┗…┗…┗…┗…┗…┗…┗…
┗◇┛┗◇┛┗◇┛┗◇┛┗◇┛┗◇┛
┗━━━━━━━━……‥‥‥・・・・

もちろん、電子メール中の上記のような記号は、
装飾的に使っている事が多いと思われるので、完全に無意味というのは
難しいような気もします。。
（まず、第一に、どういう規則で排除するコーディングにしたら
良いか、難しそうですね。）