まだ細かくは使ってないけど、基本はCVSの操作と一緒なはず。
でもメニュー類がやっぱり違うので、見た目がちょっと違和感あってちょっと新鮮(笑)
今までAntのタスク一覧メモにひっそり例を書いているだけだったfixcrlfタスクに対し、独立したページを作成。
fixcrlfと言えば改行コード変換で有名だけど、タブ⇔スペースの変換も出来るとは知らなかった。
何より、Ant1.7では文字コードを変換する（SJISをUTF-8とかEUCに換える）ことも出来る！ 文字コードを変換するタスクって無いのかなーとちょっと探していたので、こんな所にあってびっくり。
jajakartaの日本語訳（Ant1.6.1）しか見てなかったから、気付かなかった…。
（つーか、Ant1.7になるまで文字コード変換て無かったのか…）
Eclipse3.4のAntは1.7.0なので、問題なく使える。
ただし、build.xmlのエディターでは、Ant1.7の属性はCtrl+SPACEによる補完で出てくれないみたいだけど…。
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不一致を含む）はダイアログも何も出ないで処理が終わるので、何が起きたのかよく分からない(苦笑)
Javaアプレットを久々に試してみた。
Javaが出た当初はアプレット全盛だったけど、最近はほとんど聞かないもんなぁ(苦笑)
基礎的なサンプルはネット上に色々あると思うけど、パッケージ付きクラスやjarファイルからの実行サンプルって実は少ない？
