Namazu-devel-ja(旧)


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macbinary.pl



寺西です。

Yukio USUDA wrote:
> 
> Tadamasa Teranishi wrote:
> > RTF の filetype が TEXT だったりします。ですので、filetype だけ
> > で、text/plain とすると誤認します。(たぶん)
> filetype が 'TEXT'の場合はtext/plainにせずにundefにすることにします。

ttxt/TEXT のものは text/plain
MSWD/TEXT のものは application/rtf
としておくのが良いと思いますよ。

> > # data/ja-mac/textedit.rtf の filetype は空です。ごめんなさい。
> > # あまり良いサンプルでなくて。
> このサンプルはcreatorも空ですね
> これはmacのアプリでないもので作成されたファイルですか?

はい。Mac OS X の textedit で作成したものです。(確か)

Mac OS X ぐらいになると creator/filetype の対応が甘くなって
たりしますね。(拡張子判断に方針転換か!?)
 
> macbinay.pl内ではファイル名の拡張子でしか判定できないOLE系のファイル
> だけ特定しておき、あとは通常処理にまかせて判定させようと思います。

ちょっともったいない気もしますが、とりあえずそういう方法も
ありますね。

> > もうちょっと実用的なサンプルデータを集めて、実用上問題のない
> > ところまで対応するというのが良いのでしょうね。
> >
> > 常に filetype と creator のペアで比較するというのも、creator 違いで
> > 同じメディアタイプもあるだろうから、面倒といえば面倒ですしねぇ。
> creatorではファイルタイプは特定できないからまずいですね。

そうそう。そこがちょっと心配なところです。

> (wordで出力されたplaintextファイルもあるということですね)

# Word で出力された plaintext の場合、MSWD/TEXT だと RTF になっちゃう
# ので、creator/filetype はどうなるのだろうとちょっと疑問。

> Mac上のアプリケーションがfiletypeを適切につけていることは信頼できる
> のではと考えているので、filetypeの一覧を充実させるということですね。

creator filetype mediatype

のセットでテーブルを作成しておけば、後から追加するのも簡単かと。
creator が省略可能と思われるもの(例えば JPEG とか)等は、
creator に全マッチするパターンを書いておくとかすれば、良いで
しょう。
 
> > > > ppthtml の問題なら powerpoint4.ppt を削除するということで
> > > > 良いかもしれません。
...
> > powerpoint4 って随分と古いので、これをはじくための処理をわざわざ
> > するまでもないような気はしてきました。
> > powerpoint4 が現存する確率は低いだろうし。
> powerpoint4はあきらめようと思います。

はい。powerpoint4.ppt は削除してもらって結構です。

> 私の発想は
> filterモジュールの中でアーカイブを展開してループを回し
> mknmz::apply_filter()に分割したcontentを渡して返って来た結果を結合
> していけばよいかなというものです。

なるほど。

> 野首さんの準備しているArchiveモジュールはfilterモジュールに渡す前に
> アーカイブを展開して各contentにuriをつけてあげてからインデックスにする
> というしっかりとした実装で将来性がありそうに思えます。

おお。
 
> > へぇ。よければ、gnome-vfsのschemeってどんなものかわかる uri を
> > 教えていただければうれしいです。
> 私もくわしくありません。
...
> ローカルファイル以外のものも共通に扱うように抽象化しアーカイブ中の
> ファイルも同様にアクセスさせる予定なのではと思っています。
> gnome-vfsの紹介記事
> http://japan.linux.com/desktop/03/05/25/1710208.shtml
> gnome-vfsのAPIドキュメントからコンセプト部分
> http://developer.gnome.org/doc/API/gnome-vfs/writing-modules.html

参考にさせていただきます。
 
> こんな表記がサンプルに出ていますが
> ftp://username:password@xxxxxxxx/path/to/file.tar.gz#gzip#tar/path/to/hello.c
> Nautilus以外のブラウザはこのuri?を処理できないようにも思えるので
> 具体的にどういうものにする予定なのか野首さんのご意見をお聞きしたい
> です。

処理できないのはそうですが、たぶん問題ないと思います。
エラーになるわけでもなく、file.tar.gz を開くように振舞うだけなので、
今までと特に変わらないでしょう。

そして、プラグインを作成してそこで、#gzip#tar/path/to/hello.c の
解析を行い、特定ファイルを表示する仕組みを作れば、IE や Netscape でも
該当ファイルを表示させることも可能になるかと思います。
-- 
=====================================================================
寺西 忠勝(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