（最近忙しかったので、リプレイの感想をまとめて…。まずは10月分から）
六門セカンドリプレイ『スカーレット・シンフォニー2』
スカーレットシリーズの最終巻。
最初ニッケも変な妄想を言うただの（痛い）ネズミだと思ったが、このメンバーだとなんて常識人な(笑)
そしてかわいそうな奴…。加藤さんもこういう仕掛けは上手いな。
R&Rで割愛されていた「親睦の三日間」というのが載っているけど、その前フリって、
R&Rを読んでた人にはお待ちかねかもしれないけど、
逆にR&Rを読んでない人には何のことだか分からんのでは？(苦笑)
そして「スカーレット」の名前の由来とか半端な状態に終わっていた召喚ムスメとかTCG時代からの因縁（なのかな？その辺りは知らないけど）とかまで出揃い、それらを含めて六門世界の大きなストーリーが完了した模様。
うーむ、お疲れ様でした。
（よくあの変○的なメンバーでここまで続けられて、完結までもっていけたものだ。ほんと、感心する(笑)）
今まで、コネクションを切断（クローズ）しさえすればDB接続が終了すると思っていたけれど、シャットダウンしないと終わらないんだ。
ij.batからもちゃんとシャットダウンできるので、いちいちijを終了させなくてもよくなった(笑)
自作のJavaDBアクセスツールにもシャットダウンを組み込んでみた。
以前はderby.jarの場所を変更したらツールを再起動しないと同じDBへの再接続が出来なかったけど、すんなり再接続できるようになった！
原因が分かってなんだかすっきり＾＾
DBViewerとかのツールもシャットダウンをやってないんだろうなぁ。
…今試してみたら、切断時に「シャットダウンしました」って表示された。あれ？以前からこうだったっけ？
ちょっと前に自分のEclipseのプラグインのバージョンアップ（ソフトウェア更新）をやったから、変わったんだろうか。
でもderby.jarの場所を変更したらやっぱり再接続できなかったけど(爆)
ところで、久しぶりにJavaDBのドキュメント（db.apache.org/derby）の日本語ページを見たら 文字化けしまくってるんだけど、なんで～？
困るなぁ。
ZipFileでエンコードにJISAutoDetectを指定すると例外が発生する！というお話があったので、調査。
そもそもJISAutoDetectなんて実務で使ったことが無かったので軽く調べてみると…名前の通り、自動的にエンコードを判別してくれるもので、バイト配列からStringに変換する際に使用できるが、当然String（Unicode）からバイト配列に変換する時には使えない（何に変換すればいいか分からないから。明示的にUnsupportedOperationExceptionがスローされている）。
また、文字列（バイト列）が短すぎると正しく判別できないこともあるらしいが…そりゃしょーがねーっぺ。
ZipFileは解凍に使うものだから、日本語ファイル名のエンコーディングを自動判断してStringに変換する、という意味ではJISAutoDetectが指定できてもおかしくない。
で、何が例外になっているかというと、ZipEntryのコンストラクター。エントリー名（ファイル名）の長さチェックを行っている箇所。指定されたエンコーディング（バイト配列）で長さを取得するので、JISAutoDetectだと駄目なわけだ。
で、そもそもなんでZipEntryで長さチェックを行っているかというと…よく覚えてないけど(爆)、java.util.ZipEntryのコンストラクターで文字数チェックを行っているからだろう。こちらはUnicodeの文字数が65535文字を超えていないかどうかチェックしている（英語圏の人はアルファベットしか使わないから、Unicodeで文字数をチェックしても同じという意識だったんだろうけどなぁ…）んだが、実際に圧縮する際には65535バイトまでしか許容できないから、バイト配列でチェックするようにしたんだと思う。
で、解凍時にZipEntryインスタンスを作成する際にはそもそも長さチェックなんか必要ないわけで。
という訳で、ZipFile関連クラスを修正。
ZipEntryで長さチェックするのをやめた。
そしたらZipEntryでエンコーディングを保持する必要も無いので、encodingフィールドを削除し、encodingを指定するコンストラクターも廃止。
長さチェックはZipOutputStreamの中（圧縮時）で行うように修正。
長すぎる場合に例外発生する箇所が変わってしまったが、…まぁそもそもそんなに長い名前を入れることは無いと思うので、良しとしたい。
全然関係ないが、このZip関連クラス、2007年12月に作って、毎年12月に手を入れているなぁ。
来年は何を直すのやら＾＾；
