堕天使の煉獄

相も変わらずＰＧ。そろそろお絵かきもやらないとな。

今日は、やはり欲しい。ｚｉｐ内ファイルの個別解凍機能。
ってことで一度は挫折したこの件を再調査してみたり。

とりあえず、基本的にはzip書庫の圧縮にはデフレート圧縮が使われている。それは良いんだけども、なんかいろいろこれも種類があるらしく。
書庫ファイル内からバイナリで圧縮ファイルのデータをもってきて、それを解凍するだけなのだけど、これが良い手段が見つからない。

まず、解凍をどうやるのかさっぱり。辞書+ハフマン方式だとか、こんなん1から自前で解凍出来るようなものを作るのは骨が折れそうで。

しかし、メジャーどころのライブラリなんかでは、書庫ファイル自体を読み込んで、独自のハンドル操作やら、ファイルを検索する機構とセットで解凍機能がついてるんですよね。
そんでもって、出力は大抵ファイル。

メモリ上の圧縮データをメモリバッファに解凍。というのが欲しいのだけども。

なので、解凍ルーチンだけが欲しいんだけどなぁ。

で、いろいろ探していると、1ファイルで完結してるという、「miniz.c」なる物を発見。

uncompress( buffer, &buffer_size, src_memory, src_size );

おお、こういうのが欲しかったっ。

やっと見つけたーと、試してみると、解凍に失敗のエラーが。
デバッガで追ってみると、なんかソースと出力先のバッファサイズ回りでなんかエラーが起きてるっぽい。

んー。圧縮ファイルと解凍後のファイルのサイズなんか間違いようもないし……。
なんど見返してもうまく動かん～。


したらこんな記事が。

データ圧縮 zlib と gzip と zip (zlib で zip にアクセスする)
ttp://wlog.flatlib.jp/item/1653


どうも、miniz.cのuncompressは、zlib形式の解凍に使うものらしい。

で、zlibと、zip書庫内ファイルの違いといえば……圧縮形式は同じ？　なのだけどもzlibには独自のヘッダが付加されているんだそうな。

書庫内zipファイルは、圧縮ファイルのサイズだとか圧縮方式だとかは、ｚｉｐファイルのファイルヘッダとして別個にもっていて、圧縮ファイルはヘッダ無しのベタファイルになるようです。

そんで、uncompressの内部で行われているinflateInitをinflateInit2に変えて、 windowBitsに「-MZ_DEFAULT_WINDOW_BITS」を与えてやると、ヘッダ無しの生データ（raw）として解凍されるとのこと。

で、その辺修正した自前のuncompress関数にぶっ込んでみると。

解凍出来たー！

最初のはzlibのヘッダ分でバッファのサイズが狂ってたのね……。

てかzlibとかgzipとかややこしぃ……。



そんな感じで、圧縮書庫内ファイルの画像もプレビュー出来るように。

んー意外に展開速いな。画像一枚単位だからだろうか。ファイルアクセスの速度のがよっぽど問題なのか、あんまし展開速度に非圧縮と差が感じられない。
とはいえさすがに画像のヘッダ情報も読み込むのは、全ファイル解凍と同じで数個のファイルでのテストとは違って、実際の運用では重たくなりそうなので、やっぱ圧縮ファイルはファイル選択時のみ個別解凍でプレビュー表示のみ……というのが妥当か。

あとはこのバージョンでは、unzip32も7-Zipなどの統合アーカイバ系は使わない形に。結局全部バイナリから自前で読んだ方が速いし融通きくなと。windows.hもインクルードしなくて済むし。ああすっきり。

そんでもって、編集設定画面を別画面に移したので、画像プレビューも大きくなったり。やっぱ画像プレビュー画面は大きい方がいいな。


しかし……「miniz.c」……これ拡張子がｃになってる通り、Ｃ言語ベースなんですよね。しかもソースファイルだし。なんでｈじゃないんだ……。

そんでもって中身はdefineもりもり、マクロもりもり。目からゲボがでそう……。

あと、一応ｚｉｐ書庫内の解凍にも対応してるようなのですが、こちらは統合アーカイバ系とちがい、何番目のファイルか指定して解凍する形ぽ。
なので、一旦リスト化して、あとはインデックスで解凍するファイルを選択する形っぽい。
ファイル名で毎度検索するっぽい統合アーカイバ系よりはマシな作りの気もするのだけど、最初からファイル名判ってて解凍したいときは結局走査がいるので、使い勝手はあまり良くないぽですね。（すでに別手段でリストを取得後の状態で解凍なんてときに、結局再捜査がいるぽなので。インデックス番号がどういう順番のルールなのかもわからないし）

そんなこんなで220kbぐらいあったｃソースコードから、圧縮もつかわなーいってことで、zipファイル関係と圧縮関係のコードをばっさり削って、さらにソースではなくヘッダファイルに変更。

んでも100kbぐらいある……。

そんでもって、できればクラスライブラリ化したかったのだけども、Ｃ言語ベースのポインタうんこもりのコードなので、とても触る気にもならず……。
単にラップするのでは意味ないし（defineマクロ系を排除が一番の目的なので）結局ヘッダ化したところで妥協。

そんでテスト用プロジェクトで動作確認後、本チャンのプロジェクトに組み込む。

#define crc32 mz_crc32

うぉいキミぃ。

こんな定義の所為で自前のcrc32関係のコードが誤爆を受ける……。

define定義による名前空間汚染事故は結局起るのか……せっかくwindows.h排除したのに……。

ていうか他にももりもり小文字オンリーのdefine定義があったりして、止めてぇ……ってかんじぽ。

やっぱC言語って邪悪だわ……。