ITOさん

こんにちは。アドバイスありがとうございます。

>>Packageクラスって圧縮形式はZIPってことでいいんんでしょうか？

http://msdn.microsoft.com/ja-jp/library/system.io.packaging.zippackage.aspx?
ppud=4

ここを読む限りZipPackageクラスという派生サブクラスがあるようでしたのでPackag
eクラスでアーカイバが作成できると思ったのですが・・。

>>もしこだわるのなら、Packageクラスをやめて
>>aetosさんが推薦した「ZIPLIB」を利用するのがいいと思います。

もう少し試行錯誤してみて無理そうであれば別の手段を検討したいと思います。ただ
出来る限り他のライブラリやフリーのDllは使用したくないので・・・

> 圧縮後のサイズのほうが大きくなってしまうことに関してやっぱり疑問が残ります。

十分起こりうることです。

たとえば(255個までの)連続する白/黒を白の数/黒の数(8bit)で表現したとしましょう。
そうすると255bitの白/黒連続が8bitに圧縮できます。
ところが1bitずつ白/黒が交互に現れると1bitが8bitに膨張します。

これは極端な例ですが、圧縮効率はアルゴリズムと適用対象に大きく左右され、
膨張することもありえます。

> Packageクラスって圧縮形式はZIPってことでいいんんでしょうか？

いいと思います。

Package クラスは抽象クラスで、Zip 以外の圧縮形式を利用するような派生クラスを作る
ことは可能です。
ただし、Package クラスは OPC（Open Package Conventions）仕様のファイルを読み書き
するためのクラスであり、OPC 自体が圧縮形式は Zip だと規定しています。
また、Package.Open メソッドは ZipPackage のインスタンスを返します。

OPC 自体は Ecma の定めた公的な規格ですが、Zip は PkWare が定めた私的な規格です。
こういう依存性はよくないと思うんですけどね…。

規格関係の参考リンクです。
http://www.microsoft.com/japan/whdc/xps/downloads.mspx
http://www.ecma-international.org/publications/standards/Ecma-376.htm
http://www.pkware.com/documents/casestudies/APPNOTE.TXT
http://msdn.microsoft.com/ja-jp/magazine/cc163372.aspx

> しかし、僕の予測で基本はunix付属のZIPだと思います。

Unix で Zip ってあまり使われないような…
Unix で主に使うのは GZip じゃないですかね。

> aetosさんが推薦した「ZIPLIB」になるんでしょうか。

#ZipLib（SharpZipLib）です。# を省略しないでくださいな。
で、SharpZipLib が Unix の Zip 相当かどうかは知りません（が、Unix の ZLib 相当で
ないことは確かです）。

> Unix で Zip ってあまり使われないような…
> Unix で主に使うのは GZip じゃないですかね。
了解です。
ZIP = GZIPで考えてたみたいです。

>#ZipLib（SharpZipLib）です。# を省略しないでくださいな。
了解しました。

> ZIP = GZIPで考えてたみたいです。

# とくに ITO さんへの返信というわけではなく。

ご存知かもしれませんが、GZip と Zip は別物です。
どちらも中核のアルゴリズムは Deflate という同じものですが、GZip は単ファイル圧縮
です。
.NET Framework で Deflate 圧縮・展開を行うには、GZipStream クラスを使うことがで
きます。

ちなみに、「圧縮・展開ソフト」と「アーカイバ」は厳密には同義語ではありません。
「アーカイブ」とは複数のファイルを１つにまとめることであって、圧縮しなくともよい
のです。
そういった意味では、Unix でよく使われる Tar が無圧縮アーカイブです。
Tar 形式でアーカイブしたものを GZip 圧縮したものには .tar.gz とか .tgz といった
拡張子が付きます。
Tar 形式でアーカイブしたものを BZip2 圧縮したものには .tar.bz2 とか .tbz といっ
た拡張子が付きます。
一般的な Zip とか Lzh とか Cab といった形式は、圧縮とアーカイブを一緒に行う形式
ですね。

さらに余談ですが、tgz や tbz が Tar でアーカイブしてから圧縮したものであるのに対
し、GZip や BZip2 で圧縮してからアーカイブしたもの（アーカイブ形式は Tar ではな
く独自形式）が、統合アーカイバプロジェクトで公開されている BGA32.DLL（メンテされ
ていませんが…）で作成できる .gza とか .bza といった形式です。

aetosさん、ITOさん、επιστημηさん、wclrp ( 'o')さん

返信申し遅れました。この度は貴重な意見をくださりありがとうございました。
圧縮についてここまで深く検討したことがなかったので大変参考になりました。
今回の用途は圧縮して小さくするよりもパッケージングのほうに重点を置くこと
になりましたのでPackageクラスを使用した方法を採用することにしました。

しかしながら圧縮について最後にもう１点だけ確認させてください。
写真等の同じデータが並びづらいビットマップファイルをzip圧縮させた時に

Lhaca、Lhasa、ラプラス・・・どれもだいたい同じサイズで圧縮前よりかなり小さいサ
イズに圧縮される。

Packageクラス・・・圧縮前より圧縮後のサイズが大きくなってしまう。

推測ですが上記についてはLhaca、Lhasa、ラプラス等は圧縮する処理では共通の圧縮Dll
(同じような圧縮のアルゴリズム)を使用しているから圧縮後はだいたい同じくらいのサ
イズに圧縮されるがPackageクラスについては写真等の高画質なビットマップに関しては
圧縮をかけても圧縮後は元サイズよりもはるかに大きなサイズになってしまうことにつ
いてこうも違いがあるのはPackageクラスは全く独自の圧縮アルゴリズムを使用している
からなのでしょうか？

> Lhaca、Lhasa、ラプラス等は圧縮する処理では共通の圧縮Dll
> (同じような圧縮のアルゴリズム)を使用している

いずれのアーカイバも DLL を使用しません。
とはいえ、内部アルゴリズムはおそらく似たようなものでしょうね。

> Packageクラスは全く独自の圧縮アルゴリズムを使用しているからなのでしょうか？

かもしれませんね。
CreatePart で CompressionOption.Maximum を指定したのに膨れるとは思わなかった…
ただ、実際に圧縮を行う部分のコードが公開されていませんので、真相はわかりません。

皆様、いろいろとアドバイスありがとうございました。Packageクラスを用いて
圧縮した際に圧縮前より膨れてしまう件については引き続き調査しようと思いま
す。