Namazu-users-ja(旧)

[usuda@xxxxxxxxxx (Usuda Yukio)]

2000年03月07日(火)19時24分JST
knokさんは書きました。
> <200003060756.QAA11844@xxxxxxxxxxxxxxxxx>の記事において
> usuda@xxxxxxxxxxさんは書きました。
> 
> >> 　この際Namazu2.0.1付属のMMagic.pmでは
> >> 　Excel95ファイルは(application/excel)として認識されますが
> >> 　Excel97ファイルは(application/powerpoint)として認識されてしまいますので
> >>   下記の程度の追加が必要です。
> >> 　# Reversed-engineered MS Office magic numbers
> >> 　0	string		\320\317\021\340\241\261\032\341
> >> 　>48	byte		0x1B		application/excel
> >> 　0	string		\320\317\021\340\241\261\032\341　<=追加
> >> 　>48	byte		0x1E		application/excel　　　　　 <=追加
> 
>   これ、信用 ^^; しても良いでしょうか? 手元に Excel95 がないので確認で
> きないのですが、問題ないようなら次のバージョンの File-MMagic に追加し
> ようと思います。

信用してはいけません（ごめんなさい）
元のソースをしっかり読んでいなかったのでマジックナンバーの行を見た時点で
Excel95を特定するのに48バイト目を用いていると単純に思い込みテスト用に
手元にあったExcel97ファイルの48バイト目を覗いてみたところそれが
0x1Eだったので追加したものです。

今いくつかファイルを見てみたところ、どうもこれはまずいようです。
私自身はExcel97しか利用していないのですが、
Excel97の標準形式で保存したファイルはここの数値がばらばらです。
また、Excel95形式で保存させたときも0x1Bになっていないようで
やはりばらばらの数値になるようです。

xlHtmlのソースとExcelの吐き出すファイルを見比べると
Excel Ver4の場合は0x01バイト目（こういう呼び方でいいのでしょうか?）
に0x04が入っており
Excel95,Excel97は0x0205の箇所にそれぞれ0x05,0x06というバージョン番号
が入るようです。（Excel95についてはお手元のサンプルファイルで確認して
下さい。）
正確には0x09というOPcodeで始まるブロックの５バイト目ということ
なので0x0205の場所は時によって変化するのかも知れません。
他から送られてきたExcel2000で作成されたファイルも見て見るとこのブロック
は0x0A00辺りに存在するので、単純なパターンマッチングだけでは判定できな
いのかもしれません。

不正確な情報を投げて済みません。
私自身はExcelのデータに固執する気は失せてきました。
緊急性はありませんので無理のない程度にサポートを考えていただければ
十分です。
************************************************
臼田幸生　<usuda@xxxxxxxxxx>
建設省土木研究所  建設マネジメント技術研究センター