lineの日記: 続・UnlhaGetMethod 4
動かない理由判明。API.TXTの流れを読めてない俺がアホでした・・・。orz
今までの思考を簡単に書くと:
1.UnlhaGetMethodは圧縮形式を与えるAPIらしい
2.一つの書庫で幾つも圧縮法使ってるわけじゃないだろう(1書庫に1圧縮法だろう)からこれは一回呼べば十分だろう←ここで既に違う
3.FindFirst/FindNextの後か先か…で迷う←分かった今となっては意味無し
正解は、圧縮方法を示す文字列は格納ファイル毎に返されるので、ループの前や後に呼んでも意味無い。ループ内で各格納ファイル情報を得るたびに呼ばないと。またINDIVIDUALINFO構造体で言うとszModeメンバを見れば解決。てゆかAPI.TXTに
OpenArchive 系での大まかな処理の流れは次のようになります。
UnlhaOpenArchive();
if (UnlhaFindFirst() != -1) {
do {
…
構造体か,各種 API で情報を取得。API が望ましい。
…
} while (UnlhaFindNext() != -1);
}
UnlhaCloseArchive();
ちゃんと書いてあるし。UnlhaGetMethodは各種APIsのうちの一つなわけです。すげーアホな事をしてしまった・・・。こうなったら格納ファイルの情報は構造体じゃなくて各種APIで得てやる!!
INDIVIDUALINFO構造体じゃ得られないアクセス/参照/作成日時を得られるし。圧縮した/元のファイルサイズも64bit整数値で得られるし。
負け惜しみじゃないやーい。いや正しくは自業自得なんですが。
ほにゃららGetMethod()系API は使ったことないんです (スコア:1)
>一つの書庫で幾つも圧縮法使ってるわけじゃないだろう(1書庫に1圧縮法だろう)
これは yz1 などの圧縮形式の書庫はたぶんそうですが、LHa の場合は -lh0- -lh1- -lh5- -lh6- -lh7- と圧縮形式が複数ファイル・フォルダでちゃんぽんな書庫が存在しますからね。(拙作圧縮ソフトで lh auto で圧縮した場合はそうなっちゃうことがある)
使ったことのないAPIまわりの実装なので、個人的に参考になります。
私も使ったことなかったです (スコア:1)
圧縮形式を示す文字列が異なるということは、実際に異なる圧縮法なんでしょうか。これを使ってまた別のことをするわけではなくただ表示するだけなので、違っててもどうでもいいんですけど。
私も初めて使うAPIなので、あちらこちらでつまづいてます…。しかもこういうAPI群はUnlha32.dll以外だと実装されて無いことが多いので、汎用的じゃないと今更ながら気付きました。DLL作者のみなさん、そのあたり書いてくれないかなあ。(笑
Re:私も使ったことなかったです (スコア:1)
Lhasaのような一発解凍系ソフトは、「フォルダ1個をそのまま圧縮しました」「解凍時にフォルダを作成して、そのなかに解凍します」といったケースの場合、フォルダが二重に見えることがあります。それの防止機能が二重回避というもので、解凍ソフトによってはフォルダ1個だとフォルダ作成を自動回避する(拙作のはこれだけ)、フォルダ1個でかつ名前が書庫名と一緒のときだけフォルダ作成を回避する、ファイルが1個だけでもフォルダ作成を回避する、などのバリエーションが存在します。
例) apache_1.3.26.tar.gz を解凍すると、解凍先が
apache_1.3.26.tar\ になってしまい、
apache_1.3.26.tar\apache_1.3.26\README.txt ...みたいな状態になる。
このような状態になる場合、apache_1.3.26.tar のフォルダ作成・解凍先指示を省略することでちょっとユーザーが楽になる。
> 圧縮形式を示す文字列が異なるということは、実際に異なる圧縮法なんでしょうか。
書庫形式によりけり、です。Lzh の場合は圧縮アルゴリズムのバージョン、くらいの認識でしょう。一般的な書庫は lh5、圧縮率高めだけれど永遠にβ版みたいな扱いをされているのが lh6 と lh7、lzs など LHA になる前の圧縮アルゴリズムが lh1 (初期バージョンなので圧縮率は悪め)、とこんな感じです。Zip などの書庫になると、実際に圧縮法が変わってくる(deflateなどいろいろ)ので、その値が入ってくるものと思われます。
DLLを使う分には、表示するとき以外にわりとどうでもいいAPIではあるかもしれません。内蔵解凍エンジンを作る場合にはアルゴリズムを変えなければいけないので重要ではありますが...
統合アーカイバの作者さんたちは自己主張しまくりだけれど連携においては?な部分がある(Shoda.T さんがまとめサイトを作らなければ、そしてcaldixがなければDLLごとにバラバラに見えてしまう)のは難ありですね(笑) こういうのは arcdll.sourceforge.jp な方々など、アーカイバDLL 新世代の方々に期待しましょう^^;;;
# 本家もメールでちゃんとレポート・要求出しすれば、検討してもらえるかもしれません。>情報整理など。
Re:私も使ったことなかったです (スコア:1)
参考になりました。つかこれは一回作ったなら気付けよ>自分
ひとつの書庫内でファイルごとに圧縮法が違うとは、これまたさっぱり知りませんでした…。
>arcdll.sourceforge.jp
おお、こんなところに。たしか以前Hikoboshiという名前で低レベルなところから実装しようみたいなプロジェクトが立ち上がってたものの
いつのまにか消えてしまっていたので、どうしたのかと思ってましたが。
とりあえず本家の開発系メーリングリストに入ってみます。