堕天使の煉獄

某氏のところの夏コミ用お絵かきは、微妙に〆切りが予想よりのんびりで、なんかちょっと間延びした感じになっちゃって、いまいちモチベーションが上がらなくなってしまったりで。

んで、何もしないのもアレだということでＰＧがりごりと。

書庫ファイル関係で自分的にやりたい処理を一つのソフトで完結出来る用なのを作っちまおうっての。

んで、書庫ファイルの中身のファイル名をリネームについて。

解凍、圧縮回りは7-zip32.dllとかの機能使えば簡単なんだけども、書庫の中身のファイル名を、再圧縮無しで行うのって、それらのアーカイバdllの中のドキュメントみても、存在しないんですよね。

でも実際にそういうこと出来るツールはあるので、どうなってるのだろうということで、アーカイバdllあれば書庫ファイルのフォーマットなんか知らなくてもおｋだぜとか思ってたのですが、結局調べてみることに。

したら……


基本的なフォーマットの場合だと

--------------------------------------
ヘッダ（Local file header）
ファイルの圧縮データ
--------------------------------------
……
……

これが書庫内の圧縮された１ファイル分の情報。
それが収録された分だけ続く。
その次に

--------------------------------------
ヘッダ（Central directory header）
--------------------------------------
……
……

と言うのが、これまた格納されたファイルの数だけ並ぶ。
そんでもって、この中に、対応するLocal file headerのアドレスが入っていて、対になっている。
そしてなんでか、Local file headerとCentral directory headerは重複しているデータがかなりある。ファイル名とかファイルサイズとか……。

そして一番最後に
--------------------------------------
ヘッダ（End of central directory record）
--------------------------------------

一つの書庫に一つだけ存在する、普通ならファイルの先頭にあるものなんじゃないの？　っていう、書庫ファイル自体のヘッダ。

この中に、Central directory headerの一件目のデータのアドレスなんかが入ってる。


このフォーマットからして、ファイル名変更というのが、さくっと出来るものではない事が判る。
ファイル名はヘッダの中で、文字数を記録しており、各ヘッダの末尾に可変長データとして収録されているので、ファイル名を変更すると、ヘッダの長さが変わり、以降のデータのアドレスが全部ずれてしまうのです。

うーん。
そりゃそうだよな……
ファイルの先頭にヘッダ。ヘッダの中にはヘッダのサイズ（データ部の開始位置算出用）があり、ヘッダの中にファイル名と、データの開始位置とセットのデータがある。
みたいなのだったら、ファイル名とか簡単に変えられるので、そういうソフトはいっぱいあってもおかしくないはずだよな。

出来ないのには理由があるのねと。
で、なんでこんなひちめんどくさい、さらには重複データもおおい格納ファイル一つに対応するヘッダが二つもついてるのか。
こんな変なフォーマットになっているのはなぜかというと、「歴史的経緯」という奴らしい……。

つまるところ、大昔の、1ＭＢちょいのフロッピーに、分割して書庫を記録させる手段としての書庫ファイルという役割から、分割結合出来る用に、それぞれファイルをセル単位で記録して、かつ整合性チェックのためにもう一つヘッダを用意して、二つのヘッダの中の重複データから収録ファイルの整合性のチェックを行う。さらにはファイルの追記のために、書庫全体のヘッダ部は
一番最後に置かれる。（分割した書庫の末尾に追加する時に有効ということなのかな？）

といった、時代背景からのフォーマットなわけで。
現代においては4ＧＢ以上のzipも作れるし、ＨＤＤの容量も通信速度も遙かに大きくなり、分割する理由もあまりない。
ので、あまりスマートでないと感じるフォーマットになってしまってるわけだ。

あとは、書庫ファイル全体の末尾のヘッダ……最後に可変長のデータがはいってるんだよな……。
なので、末尾から○バイト前（ヘッダサイズ）から読み込む。ってのができないぽ。これはもうちょっと考えて欲しかったな……。
最後の末尾には可変長データのデータ長が入ってるとか……。
なので、結局、先頭からもりもり読んでいくしか手がないんじゃないのかねコレ。


……ＳＭＦファイルの読みこみの時も、この歴史的経緯というのがおおかったな……インターネット以前のパソ通時代の、恐ろしく低速な通信速度では、数バイトでも削る事に意味があったので、ものすごくめんどくさい、先頭からちまちまと読み、省略部分を復号したりしなきゃいけない、うっとうしいフォーマットになってたっけか……。


で、実際の所、書庫ファイルの名前の変更を再圧縮なしにどうやるかと言えば……
結局のところ、普通に書庫ファイルをバイナリで読み込んで、ヘッダ部のファイル名を変更し、サイズが変わった分は再計算して、指定アドレスの値も変更して、データ部（圧縮されたファイル）をコピーして、新しい書庫ファイルを別にバイナリで積み上げて作成する。その後変更前の書庫を削除して、変更前の書庫ファイル名に変えて置き換える。

という方法を行うしなかい模様。
再圧縮に比べれば、ちょいと解析+コピーのコストで済むので、軽いは軽いけど、１ＧＢとか越えるような書庫の場合は、どっちにしろ時間がかかる処理ぽですね……。数ＭＢ程度なら一瞬だろうけど。

たしかに、書庫ファイル内のリネーム対応してるソフトで、リネームした時の処理時間は、書庫ファイルのサイズに比例してる感じだったっけ。

同じように、書庫内のファイルの削除も、ヘッダとアドレスの書き換えだけで行えるぽですね。


んーそうなると……。

「リネームと削除」
「画像処理」（書庫内画像のリサイズや画像フォーマットの変更など）

とでソフト分けるべきなのかと。

後者の場合は、書庫ファイルのなかの実ファイルのデータのヘッダも読んだりするので（画像サイズとか現在のファイルフォーマットとか）
一覧表示にもそこそこ時間がかかりそう。
また、「画像処理」の方は再圧縮が前提なので、（データ部自体の変更を行うので）
そこでもついでにリネームや削除も行えるわけですが。
リネームや削除目的のために再圧縮必要なのは、非効率だし。


かたや、リネームと削除だけが目的の場合は、ファイルのリストだけで十分だし、ディレクトリ関係の処理も考えると、テーブルビューではなくツリービューも欲しくなるところ。

この二つを混ぜると、結構ＵＩが面倒な感じになりそうで。

でもそうなると、一つのツールで完結させるという当初の目的からは……

その辺ＵＩのデザイン次第でなんとかなるものかもしれないけど、もうちょっと煮詰めてみないとかなぁ。


……しかし結局ｚｉｐのフォーマットを細部まで調べるハメになってしまった……。
アーカイバのdllのドキュメントだけで事足りるとおもったのに……ｗ

でもｚｉｐのフォーマットはまだオープン（とはいえ、亜種が多いのも問題だけど）なので、こうやってバイナリから直接編集と言うことが出来るけど、rarとかは無理だからなぁ。

実際、書庫内リネーム対応してるソフトも、lzhとzipのみしか対応しないみたいな感じだったし。lzhはもう作者さん本人がもう使わないでねと言ってるフォーマットで、日本人が作ったアーカイバであるということになんらかの思い入れがある人以外はもう今後は使われることは無いフォーマットなので除外するとして、結局書庫内ファイルリネームはzipのみ対応すればよいし、基本ｚｉｐ以外の書庫も面倒なのでアーカイバつかってすべてzipで統一してる感じの運用にしているので（2ＧＢ越えるようなのはrar使ったりするけど）リネーム＆削除はｚｉｐ形式専用と言うことになるだろう……。

そうなるとやっぱ書庫内画像編集とは、個別のツールにすべきかなぁとか。
書庫内画像編集はアーカイバ対応していれば複数のタイプの書庫に対応できるし。そのへんで取り扱いがかなり違うぽ。

でもなにげに、ｚｉｐファイルのヘッダは基本リトルエンディアン。文字列はビックエンディアンで、shift-jisだったりutf-8だったりするのだけども。
そこいらへんはsmfファイルの読み込みの経験が生きるなあとかおもたり。

なにげに時代背景とか発生年台もかぶるフォーマットなんだよな。どこか似てる。うっとうしさも（ぉ

それがいわゆる、歴史的経緯というやつなんだなー。と遠い目になっちゃった今日この頃。