堕天使の煉獄

なんだか意外に時間がかかってしまった、書庫編集ツール。
とりあえず一区切りついたかなと。



一時ファイルに解凍とかしないで、直接画像をリサイズやフォーマット変更等の加工（非圧縮書庫限定）
zip書庫の再圧縮なしのファイル一括リネーム（正規表現置換、連番、桁合わせ）、ファイルの個別削除。
リネームと削除は圧縮書庫でもそのまま可能かつ、再圧縮しないので一瞬で終わる。
あとは画像のフォーマットやサイズの一覧表示とかできる、書庫内のそこそこ高速な閲覧。

てな感じなのようやく出来。


やっぱいちいち書庫とか解凍してから、画像編集とかタルイので、このツールでいろいろ一本化できそう。実際には人様の作ったツール（UnifyZip）のサポートありきなかんじですが。
フォルダ回りの走査が超めんどいので……。
ファイルの一覧＆編集結果表示とかしたかったのでテーブルリスト表示にしたのだけども、フォルダ構造表示するのにはふつうツリービューですよね。
でもツリービューだと編集結果とか一度に表示出来なかったりとか、一括で編集とかやるの考えると、一本のリストで完結したい。そこで再帰的な走査が必要になるフォルダ構造とか超邪魔ｗ
ってことで、非圧縮書庫化の他にも、余計なフォルダの除去とかでもUnifyZipのお世話に。データ構造の相性的にフォルダの除去機能とかつけるのめんどい感じになっちゃったので。


しかし、一番の感想は……。

zipフォーマットは酷いフォーマットだなと。
歴史的経緯というのもおおきいのだろうけど、とにかく統一性が無いというところがうっとうしいですね。唯一の救いは、フォーマットの情報がネットでいくらでも出てくると言うところか（古い情報に惑わされる事もあるけど）

なにげに日本語混じりのファイル名かフォルダか含むと？　winrarで作ったｚｉｐでは、Info-Zipとやらが提唱した、unicode文字をファイル名に使う拡張が埋め込まれるっぽい。けどぐぐってみると、提唱もと自体がもう使ってないとか。なんだそりゃｗ
そんでもって、この拡張がある場合は、zipファイルのヘッダのなかにあるオプションフラグにも、unicodeフラグというものがあるのだけど、このInfo-Zip拡張の場合はこのフラグはｏｆｆのままだったり、はたまた基本的にｚｉｐのなかのファイル名などの文字コードは、作成環境のローカルの文字セットが使われるという仕様らしく、unix系osで作成したzipはunicodeフラグ有る無しにutf-8が使用されるとか。（win系では暗黙でshift-jisがつかわれる）
なので、ヘッダの中の作成ＯＳの種類の値をみて、unicodeか判定するソフトもあるそうな。

個人的には、もうみんなutf-8で統一してほしい感じなのだけども、まだまだｗｉｎ系のアーカイバでは、古いソフトになるとunicodeには対応して無かったりするし。未だにぼちぼち使ってる画像ビューワのmangameeya(いまだにコレを越えるのがない……)も開発停止してから長く、unicode文字だと化ける～。

て感じなので、unicodeフラグon、Info-Zipのunicode拡張、作成osがunixの時はうにこーどとして読み込みまではまあ簡単。そこから、書庫を保存するときにどうするか……結局現時点のwin上では、保存時は常に文字列はshift-jisで保存するというのが一番トラブル少ないぽか。

いまだにshift-jisの呪縛から逃れ慣れないのか…開発環境まわりはもうすべてutf-8で統一してるんですけどね……。

てか、保存するときは自分でどのオプションとか、拡張機能使うかとか選択肢あるのですが、そのへんみんなばっさりカットで、書き出し部分は非常にシンプルにしてみたり。（というかいろんな他のアーカイバで読める用にするには結局最小構成にするのが一番ぽ）
逆に読み込み部分は、いろいろなフォーマットでも読める用にと、いろいろとちまちま組むハメになってそこいらへんで、ｚｉｐフォーマットのくそっぷりが身にしみるぅ。


あとは……手前味噌ながら普通に速い。
ＱＴのQDataStreamとからへんが優秀なのか、その辺の書庫系ソフトにくらべて、書庫の読み書きがすんごく速くてびくり。
……てかこれって、unzip32とかの統合アーカイバ系のハンドル取得して検索して回すAPIあたりが腐ってるんじゃないのかな。文字通り。

この辺って、それこそMS-DOSとか、win95とか、メモリが640KBとか8MBとかそんな時代からあるフォーマットやアーカイバのライブラリだし。読み込みも一括でメモリに展開とか贅沢な事も出来なかった頃の仕様が、いまだにそのまま残ってるんじゃなかろうか。

なので、普通に今風の組み方で直接バイナリから読んでると、明らかに速度差が出てるんじゃなかろうか。

そんでもって、あまりにもｚｉｐのフォーマットって無駄が多いし、雑多な拡張の所為でカオスだし。

基本的には、胆の部分はファイルの圧縮アルゴリズムの部分で、それ以外の部分はいかようにも組める感じなのに、そこがひたすらあほらしいフォーマットになってるのはなんだかなぁと。

でもこういうのって、結局何が流行るかわかんないし、そして流行った物勝ちで、内部構造がどうだとか、圧縮率がどうだとか、性能部分が秀でてるものが天下とるとは限らないんですよね。

そんなかんじで、漠然と最初は書庫を読むってと統合アーカイバ系のDLLを使うものらしいという先入観あったせいでその方法から入ったのですが、そもそのDLLの内部実装自体が前時代的に古すぎて、結局使わないという結果に。
それで一週間ぐらい時間無駄にしたなぁ……。

アーカイバのＤＬＬ関係って、基本的には、一括全解凍、全圧縮と、かなりおおざっぱな機能しかないんですよね。
なので細かいことをやろうと思うと結局自前でバイナリからフォーマット解析して読むしかなく、結局アーカイバＤＬＬ関係の仕様は全部破棄して、1からｚｉｐのフォーマットの解析作業に。

……当初はほんと、ＤＬＬ読み込んだらもう書庫回りのことは大抵のことは出来ちゃうもんだとおもってたですよ（遠い目…･･）

ああ、そういえば、jpegのExifまわりも余計な回り道だったなぁ……。結局調べたことはほとんどなんにも使わなかったものなｗ
とにかくなんか無駄が多い感じだったな今回。
かるーく一週間ぐらいで作る予定だったのに……。

そんな感じで、最後はやっぱり愚痴っぽく。……いかんな。


とりあえず、ここ数日実際にいろんな書庫にたいして使ってみて、運用テストしてるのですが、意外に良い感じに使えているぽ。

読めないものごくたまにあるんですが、そのファイルはUnifyZipでもエラーになったりして、これは邪魔くさい。
そのファイルのフォーマットどうなってるのか調べるかーってところでモチベーションが切れたぽ。

とりあえず、根詰めて組むのはもう終わりにして、あとはちょいちょい運用しながらバグフィックスしていく感じにしていこうかと。

やはり、実戦こそが最高のテストｄｅａｔｈね。

ついでにちょっとまえに計測してみたので、一段落ついた今の状態でも計測してみたり。



先週の段階で4000ステップぐらいで、今回は7000ステップ。
3000しか増えてないやん。まあ、今週はコード書くよりもテストの方が時間食ってたので、こんな物か。

はーちかれた。