Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Yukio USUDA wrote:
> 
> HEADについてはfilterモジュールからの返値としてオリジナルファイル名の他に、
> 展開後ファイル名も渡すようにして、apply_filterの２周目以降では展開後ファ
> イル名も利用してファイルタイプを判断するとしてはどうでしょうか。

Windows / Unix 系のフィルタ(gzip.pl, compress.pl)の場合は、
末尾の拡張子(.gz, .Z)を削除したものを返せば、良いのかも
しれません。

macbinary.pl に関しては、オリジナルファイル名を使うことはできない
でしょう。Macintosh では拡張子でファイルタイプを識別するという概念
ではないため、ファイルタイプを識別できる拡張子が付いているとは
限りません。(Word ファイルだからといって、foo.doc とは限らない)
ヘッダ情報に含まれる内容から、ファイルタイプを識別するためです。

では、ヘッダ情報に含まれるファイルタイプから、拡張子を生成して、
オリジナルファイル名に付加したものを返すというのでも良さそうです
が、どのみち filter モジュールの仕様を変えてしまうのなら、
展開後のファイルタイプを返す方が良いでしょう。
(そして、この返されたファイルタイプを最優先で次のファイルタイプを
決定する。)

フィルタの仕様を変えるのなら、HEAD だけの対応ですね。

> >    この理由により実用的ではないかもしれないため、HEAD のみとしました。
> MS-Office系のExcel,Powerpointファイル以外には今の状態で実用になるので、
> STABLEに入れても良いのではないでしょうか。
>
> Magicデータの書けないexcel,powerpointのデータも結果として
> filter/msword.plに渡されたのちにwvHtmlで未知のデータとしてはじかれている
> ので致命的なエラーにはならないと思います。

MS-Office系ではそうですが、一太郎系での確認は一切していないですし、
テキスト系でも、 フィルタが誤認するのでデタラメな内容が単語
登録されてしまいます。(HTML タグ等)

致命的なエラーではないにしても、同じファイルタイプ(で、一方は普通、
もう一方はMacbinary)でも結果が異なることになり、それが Macbinary に
よるものなのか、それともそのファイルタイプのフィルタの問題なのか
を判断しなければならなくなり、今よりも混乱をまねくことになるでしょう。

> 「環境とファイルによってはmknmzがcoreを吐く」というものへの暫定的な対処と
> してSTABLEにもいれてはいかがでしょうか。

この目的なら、macbinary なら全て弾くというフィルタの方が、良いで
しょう。中途半端に対応したものを stable に入れると、「動かないよ」
の問い合わせがいろいろときそうです。
stable に関しては、「Macbinary だから、処理しないよ」という方針の
方が、より実用的でしょうね。
-- 
=====================================================================
寺西 忠勝(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