堕天使の煉獄

某氏の所の夏コミ原稿も終わったので、ちょっと隣町までお買い物。

道中、不思議な車が二台。
やたらとセンターラインギリギリの右側を走行する車。そのすぐ後ろには、逆に左側の線（車道外側線というらしい）の上に乗っかる勢いで左端を走る車。その後ろに私。

前がベタ左とベタ右なので、その二台を観てると、自分の位置があやふやになって変な感じｗ

てか、センターラインギリギリの車、交差点で右折待ちしてる車とぶつかりそうになって避けてるし……。
結構混み合う場所だったので、しばらくこの二台が前にいて、なんだか落ち着かなかったり。

その後、帰り道は別の広いいわゆる産業道路的な所通って帰ってきたのですが。
なんか見るからにドキュンがのってそうな軽トラが後ろから。
ルームミラーを観ると、運転手の顔が、これまた絵に描いたようなドキュン面。いやまあ、見た目で判断するのもどうかと……その後ウィンカーも出さずに蛇行運転しながら俺様運転で割り込みしまくって行きました。
見たまんまのすがすがしいまでのドキュンでした……。やっぱ顔に出るんだね、人格って。

そのあと、ふと前の車を見ると、前の車のドアミラーに可愛いわんこが映っている。
……？　その位置だと運転席なんですが。わんこが運転してるの？
どうも小型犬で、運転席の窓側の所にわんこを置く棚というか籠というか、そういう感じの物があるらしい。
パッと見、普通に前を見据えてじっとしてるので、普通に運転手の様に見えたりで。

そんな感じで、たまに外に出ると、いろんな人もいるもんだなーとかおもたり。


んで、夏コミ原稿期間も終わって、平常運転に。

とりあえずＰＧ再開。
相変わらずclangbackend.exeがソースファイルをロックして保存出来なくなる症状がでるのでイライラ。ググっても同じ症状な人いないのかな……うちだけの不具合なのだろうか……。
とりあえず、ノートンの監視を切ってみたりとかしてみても変わらず。ノートン先生が悪さしてるわけでもないっぽい。
なにげにここ最近急に誤爆削除の件数増えてる気がするぽ。自作のＱＴ製のツールもいくつかｄｅｌされたし。なのでノートンが悪さしてるのかなと思ったんですけどね。ちがうっぽい。

なので結局clangコードモデルを一時的に利用停止中。
そうなると、autoとかで受け取ったオブジェクトのインテリセンス聞かなかったり、c++14辺りの機能つかうと、ビルドは出来てもqt creator上では波線やらでたりするので、うっとうしい。

むー。

そして、7-zip32.dllの関数とかもういろいろ面倒なのでドキュメントのＡＰＩ一覧をコピペしたやつをperlで全部一括でクラスのメンバとして使える形のｃ++コードに変換とかしてみたり。

ｗｉｎ上で使えるperlの実行環境padreが便利でよいですね。
正規表現モリモリで実行するようなのって、レンタル鯖上で実行するのは、そうそう無いだろうけど万が一ハングったらとか思うと怖いのですが、ローカル鯖立てて実行とかもめんどくさいんですよね。大昔はサイトにうｐするcgiもローカルでテストとかしていた時期もありましたが（遠い目）。でも、やっぱ文字コード回りは鬼門だなぁ。ソースコードもファイル出力もみんなutf-8で統一してるでの、実際の動作には問題でないのだけども、padre上の出力ウィンドウはがっつり文字化け。デバッグ出力的な使い方が出来ないので不便と言えば不便だ。ただまあ、そうしょっちゅう使う物でもないし、そもｃｇｉの作成には向いてないしなこれ。今回のようにちょっとした込み入った文字列変換とかに使うぐらいだし。大抵結果はファイルに出力するのでそれほど困りはしないだろうけど。

んで、そこまでやってから気がついたのですが……。
7-zip32.dllって、書庫内のファイルの個別解凍とかできねえのな……。
そして、ｐｅｒｌで出力したＤＬＬのＡＰＩ関数を文字関係をQStringに書き換えたりとかちまちまやりながら中身見てたら……。
基本、目的からは、ほとんど使う事のなさそうな物ばかり……。それに、ＡＰＩとして存在していても実際は、返値は「現時点ではエラー時以外は必ず 0 を返します」と、実質未実装な機能も結構目につくし……。

あれぇ？　なんかすんごい時間ドブに捨ててた？？ｗ

とりあえず、やりたいことは

1．書庫内のファイル名のリネーム（正規表現置換、桁揃え）、不要なファイルとディレクトリの削除。それらを非解凍で。

2．書庫内画像ファイルの、フォーマット統一（すべてjpgとか）、リサイズ、書庫の圧縮率変更（無圧縮統一とか）

の二つで。

1の場合、結局自前で書庫ファイルをバイナリで開いて読み込んで、書庫内ファイルのデータサイズとか取得してそれらを参照しながら別の書庫をこれまたバイナリで書き込んで造るだけなので、今のところ全く7-zip32使う理由がない……。使えるとしたら書庫がほんとに書庫なのかのチェックぐらいか。でもunzip32にも同様の機能あるんだよな。

んで、2の時、書庫内ファイルの画像のフォーマットとかサイズとかをリスト表示したかったんだけど、非圧縮の場合はそのままの形で画像ファイルが存在するので、直接画像のヘッダを読めるのだけど、圧縮されてるものは解凍しなければならない。
んで、ｚｉｐの面倒なところは、その圧縮のアルゴリズムが多種多様に存在すること。
なので、その辺を既存の物を使わせてもらおうと思っていたのだけども……。
その肝心なところが7-zip32には存在しない……。

unzip32の方見てみたら普通にUnZipExtract、さらにはUnZipExtractMemという、メモリ上に書庫の中の圧縮ファイルを解凍するという、一番欲しかった物がある。

うーん。
一応リネーム機能のあるオープンソースなアーカイバのソースコード弄ってたときに見た、各アーカイバの使用優先順位設定のところで、unzip32のが7-zip32より上位にあったんだよなぁ。

なにげに圧縮率とか対応書庫の種類とかから、漠然と7-zip32のが良い物だと思い込んでいてunzip32の上位互換的なイメージあったんだけどそこに大きな誤謬があったのかなーとか。
一括で圧縮解凍の用途のみならそれも間違いではないのかもだけど、書庫内ファイルを個別にどうこうするには向いてない物だったとは……。

1の場合、ｚｉｐ書庫として正しい物であれば、圧縮方法は関係無いんですよね。単にファイル名変更して、データヘッダのファイル名の長さのフィールド値変更して。あとはヘッダ内のファイルサイズ分新しい書庫ファイルにそのままコピーするだけなので。
unzip32でまず書庫ファイルチェックして、漏れたら次は7-zip32でチェック……まんまオープンソースの奴の処理と同じやぁ。
優先順位の件といい、そういうことだったのかといろいろと腑に落ちる。

なんか変な回り道した所為でか、結構ソースコードとかソースのファイル名とか混迷してきたので、また1からリライトするか。
7-zip32てunzip32の上位互換みたいな物だと勘違いしていたので、複数のアーカイバ対応する必要もないし、ｚｉｐ決め打ちなら7-zip32オンリーで良いジャンと、アーカイバ回りのクラスとかSevenZipなんとかーとか名前つけちゃってたんですよね……ｗ

んでもまあ、ようやくzip書庫ファイル回りの全体像が把握できてきたぽ。

とりあえず今週中には終わるかなぁ。
他にもいろいろとやりたいことは山積してることだし。