堕天使の煉獄

まだ書庫内ファイル変換PGやってたり。
なんかいろいろと横道にそれたりしてるもんだから……。

結局、jpgのExif情報は、なんだかんだで要らないデータだという結論に。
そも、QImageで読み込んで、変換とかした上で再保存すると、Exif情報は吹っ飛ぶのがデフォなので。そして、もともとExif情報は除去したい方向なのと、jpg限定なので、わざわざ読み込んでも利用価値とかないなと。読み書きでExif情報を保持しつづけたいというのでもなければ、もともと必要もないものだし。
でも、非圧縮な書庫の場合は、ファイルデータがそのまま入ってるので、ヘッダを読む事は可能ということで、画像のサイズ（width,height）と色数、ビット深度ぐらいは取得するかーということで、jpegのその情報とるのにも、結局たくさんあるヘッダ情報のなかから取捨選択するのに、結局それなりにヘッダの構造の知識はいったので、まあ結果オーライか。てか、ひちめんどくさいフォーマットになってるのですね……ｊｐｇって。

それに引き替え、bmpやpngのフォーマットの簡素なこと。わかりやすくて良いです。
てか、bmpのヘッダなんか久しぶりにのぞいたよ……大昔の、HTでαブレンディングとかやってた時代を思い出すにょう。
昔は自前でピクセル見て透過処理とかやてったんですよね。なのでピクセルデータがベタで入ってるbmpファイルが使われたので。

なにげに微妙に嵌ったのが、bmpやpngのヘッダのなかの画像の大きさのデータはwidth、heightの順番に格納されているのだけども、なぜかjpgはheight,widthの順番に格納されてるぽ。なので、情報取得してリストで表示してる時に、あれ？　幅のサイズがおかしい？？　と一瞬混乱したｗ　うーん。jpgめんどくせぇ。

んで、ようやく最後の仕上げ、変換後の書庫ファイル書き出し部分。

とりあえずテストでQImageで読み込んだ画像をメモリ上のバッファに保存。そのバッファをつかって、その画像一枚だけ入ってる非圧縮zipファイルをバイナリから作ってみるテストを別プロジェクト立ち上げて作ってみることに。

……そうか、ｚｉｐに登録するファイルって、crc32の値がいるのか。

いまだにc++って、標準でcrc32を算出するのないんだよな。他の言語ではぼちぼちはいってるのに。

が、ＱＴなら、とおもったんだけども、ＱＴにもはいってなひ……。

結局自前で（つーてもほとんどwebサイトで見つかったコードをＱＴ用に書き直しただけ）実装。

で、ｚｉｐ出力。

「CRCエラー」

あるぇー？　＿｜￣｜○

Explzhで中身を見てみると、追加した画像ファイルは認識してるっぽい。
ファイルのcrc32の値も、にバイナリ化したQImageのデータを一旦またjpgにして保存したファイルを、普通の圧縮ソフトでｚｉｐ化したものの中のファイルのcrc32の値と同値。

crc32の算出が間違っているわけでもないぽ。でもなんで「CRCエラー」？？

書庫内ファイルも開けないし。

Explzhの「修復」を行ってみる。
したら普通に利用可能な書庫になる。

んで、バイナリエディタで、修復前と後を比較してみると……。

んん？
なんでか修復後のファイル、CentralDirectoryHeader部の対応するLocalFileHeaderまでのオフセットが変な値になってる。
ここは、ファイルは一つしかないのでファイルの先頭、0になってるはずなんだけど。

でも書庫ファイルは開けてるので、問題はここじゃない。

うーん。

結果的には、書庫の一番末尾につけるEndOfCentralDirectoryRecord内の１フィールドのサイズが一個、２バイトのところを４バイトにしちゃってたところがあったというオチで、そこ直したら普通にｚｉｐとして認識されたりしてｗ　EndOfCentralDirectoryRecordのサイズがおかしかったのですね。普通に書庫内の画像も閲覧出来る用に。

でもそれでなんでCRC32エラー？
あと、修復後のファイルのほうの、LocalFileHeaderまでのオフセットが異常値でもｚｉｐファイルとしては問題無いってのも不思議。

てかこの値、普通に使ってないんだろうな……。

ファイルの構造的に、先頭からLocalFileHeader読んでったとき、のときにLocalFileHeaderの開始位置オフセットも取得しながら読んでいくのだけど、それはCentralDirectoryHeaderにLocalFileHeaderのオフセットを書き込むフィールドがあるからと言う理由で。順序が逆だｗ

なので、このオフセット値ってそもつかわないんだよな。
本来はファイル末尾のEndOfCentralDirectoryRecordから読みこんで、その中の
CentralDirectoryHeaderの開始位置オフセット読み込んで、そこからCentralDirectoryHeader内のLocalFileHeaderの情報を読んでいくという構想だったのだろうけど……。

EndOfCentralDirectoryRecordの末尾に可変長のデータがあることと、いろいろほかにも拡張データとか引っ付いてたりするので、末尾からEndOfCentralDirectoryRecordの先頭を探すのは確実性が低い（拡張データとかのなかに、偶然ヘッダの開始シグネイチャと同じ並びのバイナリがないともかぎらないので）

結局この方法の読み込みは現実的ではなく、結局先頭から読んでいく形になると、LocalFileHeaderのオフセットいらないんですよね。
そんなかんじなので、CentralDirectoryHeaderも、LocalFileHeaderと重複してるデータ部を比較して正当性チェックのためにあるようなもので、本来の収録ファイルのインデックスヘッダ的な役割をはなせないでいるぽ。

なので、LocalFileHeaderへのオフセットは正当性チェックにも使われないので変な値がはいっててもスルーと言うことなのだろうかｗ

でも、EndOfCentralDirectoryRecordから逆引きするような展開方法をとっているアーカイバだと、エラーになる可能性がある状態でもあるし。

いろいろと難儀なフォーマットだな……zipって。

とにかく、あとちょっとで終わるぽ。
なんか、あとちょっとってところから結構時間かかっちゃってるなぁ。
関係無い調べ物とかに没頭してたりと、脱線が多い……。

あとは、微妙な嵌りポイントがいくつか。

QTableWidgetのリスト内を、右クリックした状態でドラッグして離すと、コンテキストメニュー呼び出すイベント内で取得出来るリストのindex値は、クリック開始時でなく離した位置のindex値になること。

その場合、リストのcurrentIndexは変更されないので、クリック→currentIndex取得してリストのデータにアクセスみたいな事やってると嵌るぽ。
それに離した位置のindex取得って挙動も違和感あるなぁ……。

それからＱＴのシグナルとスロットの機構、へんな嵌りポイントがあるぽ。
どうみてもコレであってる筈なのに、No such signal とか抜かしやがるファッキン！　とおもってたら、どうやらシグナル名が、どこぞの知らないところですでに使われている名前だったらしく、それでエラーになってたっぽい。
この辺、いろいろ多重継承されてるオブジェクトおおいので、どの名前が使用不可とかよくわからんし、名前の重複が想像できるようなエラーも出ないので嵌るわー。

あとは、どうも最近のQT creatorの挙動が不安定。
ソース変更してても変更部分のビルドが不完全で以前のコードの部分が残ってるかんじで、しょっちゅうリビルド必要ぽ。プリコンパイラ涙目（ぉ

あとui関係追加すると、qmake必要になるっぽい？
この辺はｍｓｖｃビルドだからとかあるのかな？？

そんな感じで、なんでうごかんのじゃーとおもったらリビルド一発で治ったり、一旦クリーンしてqmakeしてリビルドしたら治ったりとか、コードのバグ以外の所でのエラーに泣かされること多い。
むうう。