Zipユーティリティーで、パスワード不正やCRC不一致専用の例外を追加し、解凍したデータのCRCチェックを行うInputStreamを作成した。
CRCチェックを行う指定をした場合のみチェックすることにした。
デフォルトでチェックしても良かったかもしれないけど、当然CRCチェックをする分遅くなるし、大元のjava.util.zipやAntのZipFileではデータのCRCチェックをしていないようなので。
(もっとも、あちらはパスワード機能が無いので、CRCチェックなんか不要なのかもしれないけど。
というよりは、解凍したデータを使って外部でチェックできるから、ライブラリーには組み込まなかったという事だろうか)
パスワードチェックはヘッダー部のCRCをチェックしているだけなので、そこだけたまたま一致する不正パスワードもありうる。でもInfo-ZIPで作ったzipファイルの場合は、後続の処理の中でデータ不正になる可能性が高い。そこすら通り抜けたものでもデータ部のCRCチェックで引っ掛かる。(CRCなので理屈上は異なるパスワードでも一致する可能性もあるだろうが、自分が試した範囲では100%引っ掛かった)
WindowsXPで作った暗号化zipファイルだと、ヘッダー部のチェックを通り抜ける不正パスワードがけっこう多い。でもデータ復元処理中では不正にならず、データ部のCRCチェックで引っ掛かる。
どうも、ヘッダー部のCRCの作り方がちょっと違うっぽいが、詳しいことは知らない…。
lhut(unzip32)やLhacaの動作は、データ部のCRCチェックをしないパターンと同じ動きをしているような気がする。
(ヘッダーチェックで引っ掛かれば「パスワードエラー」。たまたま通り抜けて処理中に変になるパスワードだと、処理不正となる(そういうダイアログが出る)。そこも通り抜けると、データ内容がおかしいファイルが生成される)
WindowsXPの解凍フォルダーだと、ヘッダー部のCRC不一致だとパスワード不正のダイアログが出るが、そこを通過してエラーになった場合(データのCRC不一致を含む)はダイアログも何も出ないで処理が終わるので、何が起きたのかよく分からない(苦笑)