圧縮・復元 相談室YouTube動画>2本 ->画像>2枚

アルゴリズムは別スレで

アルゴリズムを別にしたら
語るべき事は何もありません

（ﾟ∀ﾟ　）2

ん？ZIPからどうやってファイルを取り出すかは
ZIPアルゴリズムを完全に理解しなくたっていいでしょ。

>>4
既存のライブラリを使用せずにZIPからファイルを取り出すのなら
アルゴリズムも、それなりに理解する必要はあるし
ライブラリを使用するなら環境に依存した問題で
特に難しい事ではないので環境にあったスレで聞けば問題なし

>>4
Lhasa使えよ！

俺はライブラリの使いかたが知りてーんだよ
VBでどうすればいい？

要は>>1を不可逆圧縮しちまえってこった。

むしろ>>1の脳みそが不可逆圧縮だな。

どんなライブラリーでも使える共通インターフェース
みたいなのないの？

×ライブラリー
○ライブラリ

×インターフェース
○インタフェース

>>12
何を根拠に○×を付けてるのか教えてくれ

×ライブラリ
○ライーブラリ

×インタフェース
○イーンタフェース

3音節以上はーをつけない

>>12-13
こっちでやってくれ
http://pc3.2ch.net/test/read.cgi/tech/1014691583/l50

母音はのばすとｶｺｲｲ

>>15
これは？
らいぶらりぃ
いんたぁふぇぃす

>>15
お前が決めたルールか？

ちんこはのばすとｶｺｲｲ

こっちでやってくれ
http://pc3.2ch.net/test/read.cgi/tech/1014691583/l50

ちんこーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

>>21
廃スレなんだし、いいでしょ

ボインとちんこ、どっちをのばすべきか？

>>16==21?
あげなければ良いんじゃないの？

ﾊｧ?

>>25＞あげなければ良いんじゃないの？
うわ・・
出たよ、雑談板ルール。
マジで冬厨増えたな。

共通インターフェースないのかな？見つかんなかった。
いろいろな圧縮ファイルに対応したいんだけど、全部の仕様
調べないとならないの。ヽ（`Д´）ﾉ ｳﾜｧｧｧﾝ

ひとつお前は勘違いをしている。
馬鹿がプログラミングできると思うなよ。

>>28
とりあえず統合アーカイバへ逝け。
そして不可逆圧縮されなされ。

勘違いって何？

仕様を調べる位が嫌なら
人様が作ってくれたものを使うな

されなされ
　↑
どおゐう意味？？

なんと統合アーカイバDLL使えばコマンドラインで操作する感覚で圧縮、展開できますよ！！

共通インターフェースなんて作るの簡単でしょ？
Win32のCreateFile,ReadFile,WriteFile,FirstFindあたりを
用意すればいいんでしょ。ﾀﾞﾒ？

>>33
You'd like to be compress in lossless method.

>>35
全然ダメ。

>>35
なんで（；´Д｀）

>>37だった

＞共通インターフェースなんて作るの簡単でしょ？
作れない癖に簡単だと分かるのか？ｱﾌｫよ

>>34
っつーかアレは exe をDLL化しただけっつー話も…
ライブラリっぽいのは書庫内のファイルを列挙できる部分だけのよーな。

ライブラリとフレームワークとコンポーネントとパッケージとモジュールとクラスの違いを教えてください

>>40
どこが難しいの？（　´∀｀）

>>43
そー思うなら とっとと作ってください。

逝かれてんのか、こいつ

ガキが話相手欲しがってるだけ
放置しとけ

なんか具体的に指摘できる人がいないみたいだね。
具体的に指摘できないやつは（・∀・）ｶｴﾚ!!

釣りｽﾝﾅ

結局ライブラリの使い方が分からん1が粘着に答えを求めるスレってことでいいの？

DNA系列や画像、音声などの圧縮を行うような、
特殊化されたライブラリのインタフェースまで統合したいの？

>>48 >>49
>>47

>>50
zip,lzh,rar,cabみたいな一般的なやつを考えてます。

統合アーカイバ行ってこい。
ついでに削除依頼も忘れずにな。

>>51
> zip,lzh,rar,cabみたいな一般的なやつを考えてます。
zip形式だが、Javaで、
java.util.zipパッケージ内のクラスを使うのはどう?
漏れは使ったこと無いけれど。

それか、邪道だがjakarta-antのzipタスクを使うのはどうかな。

Nohrのソースをぱくる

Noahだった。。。

>>53
＞java.util.zip
ストリーム（・∀・）ｲｲ!!

＞jakarta-antのzipタスク
これはよくわからなかった。
ビルドツールがZIPを生成するのかな。

＞Noah
みつけました。調べるよヽ(´ー｀)ノ

>>57
>ビルドツールがZIPを生成するのかな。
そうです。まずantの使い方を覚えるしかないかな。
Javaやるならant覚えると便利です。
antはJBuilder,Forte for Java, Eclipseからでも呼び出せますし。
でもjava.util.zipを使えるならantでZIPタスク使わなくてもいいね。

>>58
java.util.zip のは
ファイル名をうにこーどで格納するため
日本語のファイル名を扱った場合問題が出る。

まぁ問題を回避するコードを書くのはそんなに手間ではないが。

ant の zip タスクも同様の問題なかったっけ？

>>59
> java.util.zip のは
> ファイル名をうにこーどで格納するため
> 日本語のファイル名を扱った場合問題が出る。
> まぁ問題を回避するコードを書くのはそんなに手間ではないが。
> ant の zip タスクも同様の問題なかったっけ？
半角かな文字同様、日本語のShift_JISファイル名使うなんて問題外、
って言ってるのは今では古いですか?

antにしてもJavaにしても、

ソースを全部UTF-8(Unicode)で書いてしまえばいいんじゃよ。
コンパイルオプションのencodingにUTF-8を付ける。
それでもだめならnative2ascii( or antでnative2asciiタスク )を使う。

JavaもXMLもUTF-8が標準なのだ！
........解決になってないかな?

>>1 = MD5( >>1 )
あまりに単細胞なのでハッシュしても同じとは・・・恐るべし>>1

Rar!のリカバリレコードどうやってるか知ってる人いない？

512b/256bの多重チェックサムらしいんだけど

知ってるけどタダじゃ教えられないな。

WinXPで使ってる.zipライブラリってどうやって使う？

統合アーカイバDLLってコマンドラインの書き方統一されて無くて使いづらい。

>>63
☆
|＼
|∴∴
|・ω・`)＜おしえてよ
|ｏ□ｏ.
|―ｕ'

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

>>352
ひろしま必死だなっと・・・

fewfwfeefwefw

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

スレってなんですか？(´Д｀)

>>531がいいこと言った

まだっすかー？

★とトリップが違うじゃな。

半角板がおもしろい

ネット弁慶

>>932

そう思うねぇ　

マンコとかきまくれるのは2chだけ！！ということに変わりはない

母音はのばすとカコイイ

1個、10個、100個、1000個、万個。

関係無いのは分るけど、粘着サンしつこすぎます。

あー、そっか。まぁしょうがないですね。

質の低い書き込みを減らしたいのに
質の低い板を生かしておくのはどうしてなんでしょうか？

てゆうか、２ｃｈが来年あたり消滅している可能性もあるっしょ。

なんということだ・・・・
移住先をさがさないとな。

(；´Д`)ﾊｧﾊｧ

あっ、漏れと同じ串だ

賛成！えらい。よく思いついた、あんたは凄い！天才！神！シャッチョウサン！

内部告発も何も、今までここで内部告発が行われ
世の為人の為になったことなどどれだけあっただろうか。
むしろ違法行為のほうがはるかに多いような気がしてならぬ。

winnyの発端となったスレッド
http://tmp.2ch.net/download/kako/1017/10175/1017590243.html

開発者はこのスレの氏

削除板に書き込む時いちいち設定し直すのが面倒臭いから

元々パク(ry

電波を演じてるのか、ほんものの電波なのか・・・
４００レス以上演技は続かないかな・・・

ウエー、ハッハッハ

288 ：ひろゆき ◆3SHRUNYAXA ：03/01/08 17:56 ID:rLfxQ17l
＞厨房板は本当に閉鎖なのか？
初耳。

質の低い書き込みの例

302 名前：心得をよく読みましょう ：03/01/11 21:57 ID:A+3kp3mQ
いやそんな今時な煽りやられてもな

ただ俺は「誰もお前には聞いてねーから大人しくROMってろや低脳」って言いたいんだよｗ
理解出来た？？

最高裁への上告は認められなくなったから、これで事実上判決確定だよ。
逆転も何もないって。
勢いで上告なんかしても一発で上告却下(門前払い)だよ。

二審も一審を支持。これに対して上告しようにも、
刑事訴訟と同様、自由に上告できるってもんでもないのです。
民事訴訟法312条 （上告の理由） 1項
「上告は、判決に憲法の解釈の誤りがあること
その他憲法の違反があることを理由とするときに、することができる。」
http://www.m-net.ne.jp/~doba/goto/hon.htm

ようするに上告しても今の制度では100％無駄。
これで完全終了ってことか。

少しは効果があるみたいだな。

ども。
ってことは IP 記録ってのはやっぱ揉めた時用の
"当事者同士でやってね"　っていうメッセージ & 仮 Flow なんですかね？

にしても　・・・うまく頭に入っていかないなぁ。。

？

（＾＾）

さーど じゃなくて さんど だろ。

（＾＾）

データ圧縮について勉強したいのですが
どんな本を読めばよいのかわかりません。
わかる方がいれば教えてください。

>>105
データ圧縮ハンドブック
http://www.pearsoned.co.jp/washo/prog/wa_pro30-j.html

不可逆な圧縮で、情報源が時間とともにゆっくりと変化していくものを
想定しています。
ちなみに今は、「情報と符号化の数理」という本を読んでいます。

「文書データ圧縮アルゴリズム入門」(CQ出版社)の復刊きぼんぬ！
漏れは大学の図書館で借りたこの本のおかげで圧縮にはまった。

このサイトはいいね
http://www.ingnet.or.jp/~kojif/mu/comp/

>ちなみに今は、「情報と符号化の数理」という本を読んでいます。
それを読めば十分というか
それより高度な内容の本はない。

>>107
培風館の他の書籍で、たとえば
現代シャノン理論、植松友彦著
情報源符号化・無歪みデータ圧縮、情報理論とその応用学会編
情報理論における情報スペクトル的方法、韓太舜著
情報理論、橋本猛著
などを読むとよいだろう。

（＾＾）

lzopはディレクトリ情報もてないの？

外人さんは凄いな。
どう圧縮したらLet It Be（レットイットビー）がレルピーになるのか小一時間・・・。
聞いた奴もレルピーと聞いてLet It Beと復元する能力に小一時間・・・。

>114

おまえはいいことにきがついた。
それが人間のもってる辞書圧縮機能というやつだよ

>>115
熟達すると、文脈だけで次に言いたいことがわかってしまう。
これを阿吽とか、ツーカーの仲とかいう。アイコンタクトもそれに入るかな。

あとは、反射神経、夢、なども人間に組み込まれた圧縮機能といえよう！

プッ

>117

ちんこ

□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□■■□□□□□□□□□□□□□□□□□■■□□□□□
□□□■■■■■■■■■■■■■□□□□□□□□□□□■■■■□□□
□□■■■□□□□□□□□□□□□□□□□□□□□□□■■□□□□□
□□■□■■■■■■■■□□■□□□□■□□□■■■■■■■■■■■
□□■□□□□■■□■■□■■□□□□■□□■■■□■□□□□□■■
□□■□■■■■□□□■■□□■□□■■■□■□□□■□□□□□□□
□□■□□■■□□□□□■■■■□□□■□□■□■■■■■■■■□□
□□■□■■■■■■■■■■■□□□□■■■■□□□■□□□□□□□
□□■■■□□■■□■□□□■■□■■■□□■□□□■■□□□■■□
□□■■■■■■■■■■■■■■■□■□□□■□□□□■■■■■□□
□□■□□□□■■□■□□□□□□□□□□□■□■□■■□■■□■□
□■■□□□□■■□■■□□□□□□□□□■□□■□■■□■■□■□
□■□□□□■■□□□■■□□■■□□□■■□□■■■■□■■■■□
■■□□□■■□□□□■■■■■■□□□■□□□□□■■□■■□□□
□□□■■■□□□□□□□■■■□□□□□□□■■■■■■■■■■■
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□

http://www.geocities.co.jp/Playtown-Denei/1184/satoimo/

他のスレにこんなのあったぞ

>>120
どーせなら4/1になってから披露すれば良かったのに。

>>121
どっかのスレに作者らしき奴が居たような気がする。

zipとgzip(zlib)ってアルゴリズムの組み合わせは一緒なんですか？
それでZipのアルゴリズムは”lz77->ハフマン”で正しいの？
するとどこらへんがzipとlhaは違うの？

タフマソ

>>123
gzip, lha のアルゴリズム的な違いはほとんどないです。
したがって、圧縮率もほぼ同等です。
ツールとしては、単体で圧縮しかできない(gzip)のか、
書庫化できる(LHA)のか、で大きく違うわけで。

（＾＾）

RARの圧縮アルゴリズムって
何使ってるんでしょう？

ここで聞かずに作者に聞け

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

ﾎｫｰｼｭ！

それよりGIFはタダで使えるようになったのか？

日本では来年の6/19に特許が切れるらしいが。

「GIFの特許切れでPNGあぼーん」なんてほざいてるﾔｼ、ほんっと何もわかってないよな。

（＾＾）

みなさん、統合アーカイバプロジェクトのライブラリを使ってますか？

誰もいらっしゃいませんか？

それはもう、どーしようもない。カタチは統合になっただけで結局は別モノって感じ。
それなりに便利なんで感謝してますけど。
一応そこら辺の改善を含み、使いやすいアーカイバ関連のライブラリを作る
プロジェクトが興ったみたいだけど、まだモノは出来てない。どうなるのかな

>>144
これかと
http://pc2.2ch.net/test/read.cgi/software/1046607695/

あと、解凍のみならともかく圧縮まで扱うなら、iniに設定を持たせるのは
無謀かと。

・SFX作成（書庫→SFX化と直接SFX化の二通りある)
・暗号化、ソリッド、分割などのオプション機能
・tgz/tbzなど、圧縮時に拡張子が変わる時はどうするか
・ファイルリスト仕様の微妙な違い

など、仕様が異なるところがかなりあるので設定がかなり膨れ上がりそう。

ファイルを圧縮するプログラムを作りたいのですが、まずなにからはじめたらいいのでしょうか

>>146
まずは、ファイルをコピーするプログラムを作る。
このときに、ファイルの入出力などの取り扱いについて学ぶ。

次に、圧縮のアルゴリズムなどについて学ぶ。
それから、上記のコピープログラムに、圧縮と展開を組み込む。

>>146
データ圧縮ハンドブックを買ってくる。
ソースを(コピペじゃなくて自分でキーボード叩いて)全部うつす。
コンパイルして遊ぶ。

SPECintベンチマークにcompressが含まれてて、これはとっても
並列化しにくいんですけれども、gzipなら割と簡単に並列化できるんじゃ
ないかと思いました。

　i)１ブロック読んで、中の部分文字列をハッシュ表に登録
　ii)ブロック内の各位置からの最長一致を求める。
　iii)エントロピー符号化

という順でやれば、各ステップは並列にできるのじゃないでしょうか。
gzipだと、エントロピー符号化もブロックごとの静的ハフマンだし…
ただ、ii)では無駄な位置に対しても投機的に最長一致を探すことになりますが。
並列化できないのは、ビット列の出力ですが、この時間は大きくないでしょうし。

>>149
i) と ii) を分ける理由が分からん。
ハッシュ関数換えるってんなら話は別だが。

>>150
並列化したら、
後に出てきた部分文字列の方を先に処理することもありえますから、
その際に、前に出てきた文字列が未登録だと
うまく圧縮できません（逐次処理と結果が変わります）。

PPMやべー
PPMに惚れそう

その高速性はあたかも弾丸のようだ。

>>152
もう惚れ済みですが何か？
7-zip [ http://7-zip.org/ ] とか、
ppmd(1) [ http://packages.debian.org/unstable/utils/ppmd.html ] とか。

zip や lha　とかってbitごとに辞書化してるんですか？
それともbyteごとなんでしょうか。
よく見る解説ページでは"aaabcccddddff"とかって
アルファベットだったりと概念的なものばかりでよくわからんのですが…

>>155
一般に圧縮ではバイト（あるいはそれ以上の大きさ)が用いられる。
あと、圧縮の説明にアルファベットがよく使われるのは”見える”からだと思われ。

>>158
その違いが辞書の違い、すなわち、手法の違い。
LZ'77, LZ'78 くらいでよいから、参考書で勉強すべし。

なるほど。もちっと本読んで勉強します。
ありがとうございました

LZSSのソース（作者が使用してもよいと言ってる物）欲しいんですがどこにありますか？
へたれなのでアルゴリズムﾊﾟｸﾘたいのですが。

>>161
おまいは奥村先生の「最新アルゴリズム事典」を枕にして勉強しる。

>>161
おまいは奥村先生に足を向けて寝ていはいけない。
http://www.matsusaka-u.ac.jp/%7Eokumura/algo/

>>162-163
奥村先生のソースコードは落としましたがあれは本当にLZSSの基本実装みたいな形ですよね？
だもんで速度的にちょっといけてないかなーとへたれ心に思ってみてり。
因みにツリーを使わずハッシュを使うと特許に触れるんでしたっけ？

>>164
LHA, gzip はハッシュを使って実装されている。

つーか、へたれを自称する人は基本をおろそかにしてはいけない。
とりあえず、LHA か gzip のソースを読んでみてわからなかったら、
素直に奥村先生を拝むこと。

>>161
これはどうだ？
http://www.ingnet.or.jp/~kojif/mu/comp/

>>164
へたれだからこそｺﾋﾟﾍﾟなんだよ!
ハッシュ化するのは問題ないんですね。少し勉強して奥村先生コードに手を加えるか…。

>>166
確か最初に落としたけど研究目的以外はx(ﾒｯ)なんすﾖ。

>>164
LZSS系列だとツリー使っても特許の地雷だらけなのよね。
ハッシュ使っても地雷だらけ、ってのは変わらんけど。

>>168
特許の有効期限、いつになったら切れるんだ？

特許発効から20年ほど

MACのsit形式の仕様書はいつになったら公開されるんですか
不便でしようがありませんよ！

どこかに解析資料とかないでしょうか

>>171
こんなのとか。
http://www.stuffit.com/win/sdk/index.html

>20年ほど

長いよねぇ

>>172
ありがとう

登録制なのか…やだなぁ

http://www.cmagazine.jp/books/assyuku/index.html

この本とかはどうだろ？

>>10
　激しくﾜﾛﾀ（笑）。

>>171
http://www.speakeasy.org/~russotto/arseniccomp.html

圧縮といえば、2年くらい前にすげー大ボラ吹いた奴が
海外にいなかったっけ？

>>178
1/100に圧縮できるってヤツか?

あげ

おまえらエントロピーくらいわかってるよな？

圧縮・燃焼について語れ

ロータリーエンジンはすごいって事話す事になったんですか？

ロリータエンジン

LZ系で小さいやつ
(コードサイズが小さくて、
符号化・復号化だけで余計な機能がなく、
復号が速いやつ)
ない？
アプリにこっそり組み込んで使いたいんだが。

>>178-179
ZeoSyncｷﾀｰｗ
懐かしいな。

>>185
奥村LZSSでもつかっとけ

THCompが最強

>>185
MS-COMPRESSを呼び出すのが簡単かつ確実

>>189
WinでもAIXでも使えるのをおながいします。

昔の7行スレのやつ使うことにしました。
ちょっと遅いけどすげー小さいので。
ちなみに190は偽物です。

む、7行であったのか

>>192
7行のだと、Huffman, rangecoder, LZ77系, RLEなら、
それぞれ2つ以上の実装が出ていたはず。
LZ78とかBPEとかもあった。

>>192
これかな？
http://www.isl.cs.gunma-u.ac.jp/~shingo/make/7line/7line.html

違う

数MのXMLを短時間で圧縮解凍したいんですが、圧縮率とパフォーマンスのバランス
の取れた圧縮アルゴリズムってなんでしょう？

XML → 無駄なコード削除 → ブロックソーティング → MFT → ランレングス

　でやってみたんですが、圧縮率は満足なもののブロックソーティングが遅すぎて
使えませんでした。もちろん、高速化は可能だと思うのですが…

>>196
まずbzip2で試してみて、それでも遅ければブロックソートは向いてない、
十分な速度ならブロックソートの高速化が甘いかと。

ブロックソートの高速化についてはこちらなど
M.Hiroi's Home Page　http://www.geocities.co.jp/SiliconValley-Oakland/1680/
white page　http://homepage3.nifty.com/wpage/

すいません、javaで圧縮・解凍プログラムの作成を試みているのですが、
どこか良いサイトあれば教えてください。
jarでなくてgzipの話です、念のため。

そういったアルゴリズム関連の場合、
いきなりJavaソースを探すのではなく、
C/C++をJavaに翻訳することを薦める。

>199
javaには、圧縮関連のインタフェースが提供されているはずなのですが。。
圧縮クラスだとか圧縮メソッドのような。。

>>198

> 標準的な ZIP ファイル形式および ＧＺＩＰ ファイル形式を読み取ったり、書き出したりするためのクラスを提供します。

http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/util/zip/package-summary.html

そこはおとずれました。サンプルプログラムを教えてください。

見つけた。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=5688&forum=12

マルチメディアのファイルフォーマットを作成中なのですが
ストリーミングに向いた、圧縮方法を教えてください。

>>204
うぐっ！
書き損ねた。>>204は携帯電話によく搭載されてるSMAFみたいな
奴を考えてます。

ストリーミングと圧縮はあまり関係ないんじゃないのか？
あえて言うなら、ストリーミングにはデータ欠損が付き物なので
データが足りなくても質を下げて再生できるようなフォーマットが必要だろう。
最初の数パケットで数フレーム分を荒く再生できるとか。

>>206
すると、圧縮しないほうがいいってことでしょうか？

いや、そういう意味ではなくて、ストリーミングに適しているかどうかは
アルゴリズムよりも実装の問題だという事。
圧縮は当然する。
しないと送受信が間に合わないでしょ。

といっても具体的に知っている訳じゃないので一般論でしかないけどね。
とりあえずmpegとか調べてみては如何かな？

>>204
「携帯 ムービー フォーマット」でググればそれらしい形式が出てくるんだから
更にそれらのフォーマットを調べれば済むんじゃないかなぁ。

質問です。
backup[1]という名前のフォルダの中に次のようなファイルが入っているとします。
　regcopy.exe
　help.chm
　online.htm
　readme.txt
別のbackup[2]というフォルダの中にもbackup[1]と全く同じファイルが入っているとします。

このbackup[1]とbackup[2]のフォルダをそれぞれLZH形式に圧縮します。
圧縮したこれら２つのファイルのバイナリを比較したところバイナリが一致しません。
上記４つの各ファイルのバイナリは一致しているのに、なぜ圧縮すると圧縮ファイルのバイナリが一致しなくなるのでしょうか？

宜しくお願いします。m(ﾟдﾟ)m

釣りか?
フォルダごと圧縮してるなら、フォルダの名前が違うから。

>>211
いや、最初はそれが原因かと思ったので、フォルダ名を同じにして圧縮してみたんですが、
やはりバイナリが一致しないんですよ。
どうやら、フォルダ名はバイナリに反映されないようですね。

今度はZIP形式に圧縮し直して試してみたんですが、やはりバイナリが一致しません。
うーん、、何故？なぜなんだろう。。

フォルダのタイムスタンプが違うんだろ。たぶん。
タイムスタンプも統一(偽造)してやってみて。

>>213
レスありがとうございます。
タイムスタンプは一致させているんですが、やはりバイナリが一致しません。
どうやら、ファイルの圧縮順が違ってみたいです。

例えば、backup[1]では、
regcopy.exe→help.chm→online.htm→readme.txt
のような順で圧縮処理しているのに対し、backup[2]では、
help.chm→online.htm→readme.txt→regcopy.exe
のような順で圧縮処理しているようなのです。

つまり、圧縮書庫内に格納されているファイル順が異なるため、バイナリが一致しないようなのです。
そこで、フォルダ内のファイルを名前順で並べかえてから圧縮したのですが、圧縮順は変わらないままです。

何か良い方法はないものでしょうか？
OS：WinME
アーカイバ：Easy圧縮

ファイルの列挙順はファイルシステムに依存するから、
それを制御するのはWindowsでは難しいだろうな。

ところで個人的には「どうしてそうしたいのか」が不明なんだが。

>>215
なるほど、やはりファイルシステム依存でしたか。
アーカイバ側の設定で名前順でソートしたらバイナリ一致確認できました。

＞ところで個人的には「どうしてそうしたいのか」が不明なんだが。
書庫内の格納順が名前順になってないと、解凍後に名前順に並べ替えないといけないんですよ。
これって気になりませんか？

いや別に並び順なんてのは表示の問題であって
内部処理がどうなってようが気にならんがね。
実際FATだかNTFSだかがどんな順番で格納してるかなんか
気にしてないだろ？　もちろんファイラで一覧表示するときは
なんかの基準でソートされてないと見づらいけどね。

アーカイブも同じだと思う。実際にどの順で格納されてようが
別に気にならないな。中に何が入ってるか表示するときに
ソートすればいいだけの話だから。

>>216
勝手に並べ替えされると「あぁ、名前順に格納されてるのか」とか考えるバカが出るような気もするが。

ファイルを圧縮するんじゃなくてメモリ内のデータをファイル名を指定して直接
ＬＺＨ圧縮ファイルに出力したいんだけどやっぱハフマン法とか勉強しなきゃできないん？

>>219
zlibならそういう使い方もできるんだが、LHAでは聞いたことないな。
LHAという縛りがあるなら勉強してクローン作るしかないかもしらん。
LHAじゃなくても良くて単に圧縮したいだけならzlibが使えると思う。

>>220
レスサンクス
ＬＺＨ圧縮しる！っていわれてるんで参考書でも買ってきて勉強しマフ

>>219
unlha32.dll で UnlhaCompressMem とか使えばできなかったっけ？

>>222
情報サンクス
ちょっと試してみますた
メモリ圧縮は可能だけど解凍ソフトで解凍してもファイルが出来ないよ・・orz
やはり自作しるしかないのか・・はぁ・・

出来ないと思ってたのは自分のミスですた・・・
これでデータ長がDWORDの設定範囲を超えるデータを
１ファイルにまとめることが可能なら・・・これで十分いけそうでつ
>>220さん
>>222さん
ありがたう！

自動解凍のプログラムを作るのに参考になるページはありませんか？
解凍後にいろいろ処理をしたいのですが、既存のをそのまま使うのは
無理そうなんです。
解凍後に指定のEXEファイルを実行、というのでは解凍中のエラー時の
処理などがカスタマイズできないので使えないんです。

>>225
makeとかantとかを強制させるとか

>>225
installshield(?)を参考にしる

>>225
プログラムの参考にはならないだろうが、
DGCAが、自動解凍後に任意のプログラムを実行する機能を持っている。

>>228
そんなんlhaだって持ってるぞ。
っつーか普通は持ってるんじゃないか？

>>229
% lha --version
lha for unix version 1.14g
% lha
...
LHa for UNIX V 1.14i Modified 2000 Tsugio Okamoto

ごめん。よくわかんない。
DOS版にはそういう機能があるの???

>>230
そもそもunix版では自己解凍書庫つくれんだろーが。

>>230-231
sharの仕組みを導入して何でも自己解凍化してしまえばok

　

既存圧縮アルゴリズムを上回る圧縮率を開発できれば食いっパくれないんだろうなぁ

たかだか 1%程度改善できても誰もよろこばんと思われ。

開発しただけではどうだかな。その後のマーケティング次第でなんとでも。
それに圧縮率だけなら既存のでもシャノン限界に肉薄しているのがあるし、
圧縮速度やメモリ効率や使い勝手も優れてないとこれから普及するのは難しい。

いま，バッファにあるデータを
圧縮したり，展開したりする必要があるんだが，
統合アーカイバプロジェクトにあるような
圧縮展開ライブラリは「ことごとく」，
ファイルから入れて，ファイルに出すような，
API しか用意していない．

バッファで使えるようなライブラリ知らない？

>>238
少なくとも unlha32.dll と unzip32.dll はメモリから圧縮、解凍できるが。
っつか、>>222 で既出。

>>239

lnlha32.dll では圧縮したデータを直接バッファに
出すことはできない

unzip32.dll では圧縮そのものができない

だとすると素直にzlib使う感じかなぁ。

すいません。馬鹿な質問かも知れませんが圧縮ってどうやってやるんですか?
例えばバイナリは1バイトで必ず0〜255の値しか取らないじゃないですか。
それを圧縮したら戻らなくなっちゃう気がするんですけど…

>>242
まずはこの辺読めば？
http://homepage1.nifty.com/snap/room03/c02/comp/comp.html

>>240
それなら、バッファにあるデータをバッファに圧縮、展開と書かないと分からないよ。

展開はともかく、圧縮データをバッファに吐くのは
圧縮できなくてデータが増える事も考慮すると、ちと面倒くさいね。

要するに可逆圧縮は連続データがなければ圧縮というよりファイルサイズが増えるってことですかね…
なんとなくわかりました。ありがとうございます。

>>245
ほとんどわかってないぞお前。

>>243
そこはLZ78符号 ≒ LZ77符号 ＞＞ 算術符号 ＞ ハフマン符号 ＞＞ 連長符号
みたいな比較をしていて解説としてはちょっとおかしいぞ。
LZ符号と算術・ハフマン符号を比較するのは無理がある。

>>244
> 展開はともかく、圧縮データをバッファに吐くのは
> 圧縮できなくてデータが増える事も考慮すると、ちと面倒くさいね

ん？ 意味わからん
ちぢまない最悪のケースを考慮して，
バッファを用意させればいいだけの話じゃないか

>>248
最悪のケースを調べるのが面倒くさいって事。

deflate でやるなら deflate のフォーマットを調べないと最悪のケースはわからん。
適当にやると不具合が出たときに泣きを見ることになる。

GCAってのはどれだけ優秀なの？
解凍速度優先型らしいけど、ホントにゲームに使ってる方いらっしゃる？

たとえばランレングス法とかのように("aaabbc" => "a3b2")
日本語を含む文字列(char型の配列)を圧縮して、
出力がバイナリでない圧縮方法はないですか？
ランレングス法は通常のテキストだとあんまり意味がないもんで。

>>251
そんな特異な圧縮方法はありそうにない。
ってか、ほとんど仕様が決まってるじゃん。自前で用意しる！

>>251
君は>>242だな？

>出力がバイナリでない
意味が良く分からん。
もう少し圧縮について勉強しなさいな。

失礼いたします。
LHAやzlibでの、LZ系の高速化手法について詳しく述べられている
サイトってございませんでしょうか？

>>254
サイトは知らないが、論文はいくつかある。

>>254
ランペル・ジブ系一般に対する高速化の手法ではなくて、
LHAやzlibが採用してる手法について知りたいってこと？

後者なら、LHAについては1970〜80年台の古い雑誌に解説記事が載ってたな。
zlibはソース見るのが早いかも。いずれにしても、奥村先生のとこの記述がとっかかりになるはず。
http://oku.edu.mie-u.ac.jp/~okumura/map.html

前者だと、論文とか特許文書あたりの範疇になるのかな。これはさすがによくわかんね。

教えて頂いてどうもありがとうございます。

>>256
後者の方です。

gzip.dll用のCのヘッダーファイルが存在するのかどうか、
どなたかご存知でしたら教えてください。
当方VC6.0で圧縮モジュールを作成したいと考えています。

　

>>258
http://www.gzip.org/

人生に密着した、圧縮と解凍。
http://www.newforeskin.biz/CI/CIchart.htm

LZとかその他の理論を基本的な手法を解説した本ってあまりないよね
なので、見つけたら即買ってしまう・・・

「ＬＨＡとＺＩＰ」つー、マンマの本はどうなのかな。
オレは読んだこと無いけど(苦笑)。
Cが読めるなら、理解できるんじゃないかな。
オレはCを読めないので本当のトコは知らないけど(苦笑)。

アルゴリズムだけなら、上の本の作者の若い片割れの
ウェブサイトに、基本的にトコがカンタンに載ってるよ。
オレはそこ読んでLZSS+ハフマンのアーカイバを作った。

>>262
理論を解説した文書が欲しければ論文を読むか、情報理論の教科書を探せ
手法を解説した文書ともども、amazonで買える

そもそもの大問題として、LZそのものの理論解析が実はあまり進んでいないという
確率推定問題に置き換えての証明やらは腐るほどあるが、派生手法に適用が困難

gzipの解凍と圧縮の仕方を知りたい。

>>265
ソースプログラムを読もう
アルゴリズムを知りたければRFCを読めばおｋ

LZMAをマイナーOS環境にポーティングしようと思ったら、LZMA SDKの
コードそのままでメークできてしまった。色々いじって楽しもうと思ったのになあ・・・。

zip32.dllをダウンロードする場所を教えてください

>>268
googleで検索することをオススメします

いいから直アド教えれこのくずが

ごめん・・・
もうゲットしちゃった(*´д`*)

(ﾟдﾟ)

>>270
氏ね

lzw圧縮ってもう使ってもいいんだよね？
あとでまた特許云々…とかなったりしないよね？

> lzw圧縮ってもう使ってもいいんだよね？
Unisysが持ってた特許は失効した。

> あとでまた特許云々…とかなったりしないよね？
可能性はある。
実際に Unisys が関連特許で gif からライセンス料を徴収を続けるかも、って記事もあったし。

>実際に Unisys が関連特許で gif からライセンス料を徴収を続けるかも、って記事もあったし。
マジですか('A`)
携帯アプリのデータ圧縮に使おうと思ってたんだけど、やめといたほうがいいのかな…。

>>277
>>276 は脅しただけだと思うが。
まぁ、油断はしない方がいいやね。

lzwってsuffix treeが必要になるから携帯でやるとメモリきつくない？

各ノードの前後のインデックスを保持するだけだからそんなにメモリ使わないと思う。

前後のインデックスってわかんないや。
親ノードのインデックスだったらわかるけど。
最近勉強してなかったからなぁ。

ああ、親子のインデックスって言った方がよかったか。
lzwなら、親ノードのインデックスと１字のデータ(ある意味、子ノードのインデックス)ってことだよ。

>>277
>>276 が言ってるのと同じかはしらんけど、こんなん見つけた。

http://pcweb.mycom.co.jp/news/2004/06/21/001.html
> 現在、米UnisysはLZWの技術に関連する2件の特許を出願中であり、
> 近い将来において特許成立が見込まれると発表している。
> 画像フォーマットとの関係は不明だが、その内容次第では
> 今回解決に至ったGIF問題の再発も懸念される。

まあ特許切れてる間に発表すれば後で公開停止求められることはないと思うけど、
作ってる間に関連特許取られたら怖いなー。後々使いまわす予定のコードだし。
短いコードで圧縮率高いから使いたかったんだけど…lzw以外でそういう圧縮方法ってないよね？

lzss もハッシュテーブルと連結リストだけでできるっしょ。
こっちも特許ヤバそうだけど。

ごめん、今更だが子のインデックスって言い方はまずかった。
要は、辞書X番の情報は「辞書Ｙ番の子である」と「その後ろにつく１文字」ということなんで、
ノードの持つデータと親のインデックスだけでいいんだな。

cabinet SDK(cabinet.dll)のAPIが日本語で説明されてるサイトってありませんか？

大阪（西梅田）、新宿（JR駅前）のそれぞれ一等地に
拠点を構え、業績急上昇中！未経験者大募集中！の
ソフトウェア開発会社
グリーンシステムを応援するＨＰです。
http://www.geocities.jp/grs_hp/

応援するスレはこちら！
http://school4.2ch.net/test/read.cgi/job/1077432387/

最高の会社にするため、みんな頑張ってます！

高速ブラウザ「Opera」、SlipStreamの圧縮技術でさらに加速
http://pcweb.mycom.co.jp/news/2004/11/06/100.html

の記事で、
「SlipStreamが開発したWebやEメールのアクセラレーション技術である。同社独自のデータ圧縮アルゴリズム」
とあるけど、
またまた、何かのパクリなのか？　

こういう紛いもんみたいな新技術の話って、よくもまあホイホイ出てくるよなぁ。

教えてください。私目のバカ脳では、限界です。
JavaのZGIPOutputStreamクラスでgzip形式で圧縮が可能なのですが、

同じファイルでも、プログラムで圧縮プログラムを実行するたびに、
出力された圧縮ファイルが異なります。サイズも中身もです。
解凍すれば、同じデータであるので、別に良いのですが、
会社で資産管理作業を行う際に面倒です。
そもそも、gzipや他の名のある圧縮アルゴリズムの
仕様なのでしょうか？

>>289
適当な圧縮ソフトで実験してみれば？

拡張子ｆｃｄってどうやって復元するの?
サイズ400メガ

>>291
とりあえず吊っとく？

ＦＣＤ・・わからん
吊っとく・・わからん

割れだろ？放置推奨

圧縮ソフトを作りたくて圧縮技術に関する本をamazonで検索しています。

http://www.amazon.co.jp/exec/obidos/ASIN/4797325526/ref=pd_bxgy_img_2/249-1522108-5041925
圧縮アルゴリズム―符号化の原理とC言語による実装 C magazine
↑は購入を決めたのですが、他にお勧めの本はありますか？

できればプログラムのソースの解説については少なくて
アルゴリズムの解説に重みを置いている本を読みたいのです。

上記の本は知人から見せてもらって
自分のそばに置こうと考えたので購入することにしました。

http://www.amazon.co.jp/exec/obidos/ASIN/4798005606/ref=pd_sim_dp_2/249-1522108-5041925
図解入門 よくわかる最新データ圧縮技術の基本と仕組み
―情報圧縮技術とアルゴリズムの基礎講座
How‐nual Visual Guide Book

こちらも候補に入れております。

保守

あとはこれ。
「LHAとZIP―圧縮アルゴリズム×プログラミング入門」
http://www.amazon.co.jp/exec/obidos/ASIN/4797324287/

>>298
その本は 1/3 が LHA の作者の一人の奥村氏による昔話とアルゴリズム解説、
2/3 が DeepFreezer作者による LHA の独自実装のソースと解説。
ついでに ZIP も実装できちゃいましたって感じの本だよ。
アルゴリズムの解説が読みたいっていう >>295 にオススメできるような本じゃない。

仕様を網羅してるか、という点で見ても LHA も ZIP も中途半端だし。

そうだねぇ。私も買ったけど、仕様がどうこうって本ではないですね。
圧縮アルゴリズムのさわりと、プログラミングの入門って感じの本でした。
ていうか、サブタイトルがそのまんまなんで、タイトル通りの本ってことだけど。

図解入門 よくわかる最新データ圧縮技術の基本と仕組み
―情報圧縮技術とアルゴリズムの基礎講座
How‐nual Visual Guide Book

圧縮アルゴリズム―符号化の原理とC言語による実装 C magazine

上二つの本を購入することにしました。
みなさんありがとうございました。

>>296 >>301
よくわかる〜　はさわりしか書いてないので、物足りなくなったら原論文を当たるとよいでしょう
ただ、オリジナルの論文では正確なところがわからないこともあるので、
解説的な論文を読むのもいいでしょう

突っ込みたい。「さわり」を突っ込みたいー。

昔買った、文書データ圧縮アルゴリズム入門 というのは様々な圧縮方法が書いてあって
よかったけど、今は絶版らしい。

>>304
http://www.cqpub.co.jp/hanbai/books/36/36721.htm
漏れが圧縮にハマるきっかけになった名著。絶版でなければ、>>301で不足してる分はこれが補ってくれると思うんだが…
復刊.comでリクエストするか、それとも改訂版をリクエストするか？

改訂版のほうが良いんじゃないかな

掲示板を作りました
http://scs.dip.jp
情報通信に関する学術的および技術的な議論の場を
提供することを目的としています。
勉強するためのテキストの紹介、技術的な質問、
産業界の動向、議論などご自由にお使いください。

ランタイムライブラリ含まない大きさが2kバイトぐらいの
小さくて展開の速い圧縮ありませんか？
圧縮する対象は主にexeとかの実行イメージです。

今はひそかにスライド辞書(LZ77)を使ってますが
アルゴリズム同じだと特許に触れるんでしょうか。
せっかく苦労して作ったのにやだなあ。

>>308
子供は早く寝ろ

LZ77なら全く問題なし

>>310
富士通はLZ77+ハッシュ使うとダメって言ってるし、
LHA作者の奥村教授はLZ77+ツリー使うとダメって言ってるが。

LZ77+何か：×の可能性が高い
LZ77のみ　：
って事

文字化けしてたらｽﾏｿ
は○

LZ77 + 普通のハフマンは×ですか？(LHAではないです)
ハフマンって圧縮以上に見た目のランダム性上がるから
使いでがあるんですが。

というかLZ77のみは可ですか。
とりあえずLZ77だけでいきます。


こういう思いつきそうな事を特許で縛るのって卑怯ですよね。
そういえば、バイオハザードの視点固定は特許になったのかな。
あれも酷いですよね。

>>314
> というかLZ77のみは可ですか。
LZ77のみっつーか LZ77 + 単純検索だけでhashもツリーも使ってないなら、たぶん可。
LZ77 + 自分でゼロから考えた高速化をしてる場合は特許の調査をしてみんとわからん。

hashとかツリーとか言われて理解できないようなら、たぶん不可。
一般にwebや本に書かれてるLZ77のプログラムは、全てhashかツリーを使ってるから。

>>314
誰でも思いつきそうで、特定の誰かが思いつくものは多々ありますが、結局早い者勝ちです。
それに、もう20年近く前に「開発され尽くした」といわれた手法に、
いまさらどうこう言ってもしょうがないかと。
LZW同様、ぞくぞく特許が切れつつあるので、ちゃんと調べるなら、使うことができますよ。

あと、LZ77の大多数の特許は、圧縮時の手法（ハッシュも木も）なので、
LZ77オリジナルと同じ圧縮後データをもち、展開するだけなら、特許は全く関係ないわけです。

> ちゃんと調べるなら、使うことができますよ。
ちゃんと調べるならって、>>314 には使えないって遠まわしに言ってるだけのような。

>>317
特許専門の弁護士やら技術者やらを用意しても回避困難
一般人ならなおさら

・ソース非公開
・リバースエンジニアリング、解析を禁止
しておけば大丈夫。
特許の有効期限分経過してからソースは公開すればいい。
後で特許とられても、先に実装が存在する場合は特許が成立しないので、
この場合も安全となる。

> 特許の有効期限分経過してからソースは公開すればいい。
特許が無効になるまでの期間分の特許料払わなきゃいかんと思うが。

> 後で特許とられても、先に実装が存在する場合は特許が成立しないので、
実装が存在しただけで公知と言えるのかは疑問。

>>320
>> 特許の有効期限分経過してからソースは公開すればいい。
>特許が無効になるまでの期間分の特許料払わなきゃいかんと思うが。

特許の存在を知らなかったといえば回避できる。

>実装が存在しただけで公知と言えるのかは疑問。

公知でなくとも存在を証明できれば問題ない。
そのためにはネット上で配布などをあらかじめ利用する。

> 特許の存在を知らなかったといえば回避できる。
著作権じゃないんだから……
それが通るなら特許なんて法制度はあっというまに崩壊するな。

> 公知でなくとも存在を証明できれば問題ない。
改竄が比較的容易なネットでの配布が法的にどーゆー位置づけになるか、って問題と
実装だけで存在を証明できるかって問題が……

>>319 >>321
特許は、
知らなかったでは回避できないし、
その期間分を遡って賠償も請求されるし、
(著作権と異なり)偶然一致した場合でも侵害したことになる。

ネット上での公開は、現在は灰色。
ソースコードを登録機関に提出しておくべし。


・・・はず、有識者もとむ(特許出しているくせに、未熟ですまぬ)・・・

じゃあ組み込むのは展開部分のみなんで関係ないですね

>>323
回避できる。例えばGIF関連では、期限が切れた今現在、過去に上って請求されることは無い。
ポイントは、経過したことと、相手に請求されていないこと。
期限が切れてしまえば、知らなかったで済む。大抵は時効だ。

ソースコードの提出は、逆に自分を危険に晒す。
自分が権利を主張しないなら、バイナリが存在すれば、それで十分。
バイナリ自体が、アセンブリ言語のソースになる。

>>322
お前は馬鹿か。特許制度が、どういう理念で作られたかわかっていないな。
著作権などの法制度とは全く異なる。もともと技術が隠されるのを防ぐためだ。

>>325
無根拠で知らなかったで済むとか言われても……

それに Unisys が現実に特許料を請求するかは別にして、
今現在でも Unisys は2004年6月（だっけ？）までの特許料を請求する権利を持ち続けてるだろ。

あとバイナリ自体がアセンブリ言語のソースって考え方なら
バイナリもソースコードと同程度に危険なはずだが。

>>324
奥村教授を信じるなら、LZ77の展開部分だけなら大丈夫だと思われ？
ハフマンの展開部分も大丈夫か、ハフマンの展開部分とLZ77の展開部分くっつけて大丈夫かは知らんが。

>>326
特許の目的は人類の知的財産の共有が目的だよ
みんなで一歩一歩進みましょう。
って感じの。

特許対象となるようなすばらしいアイデアはみんなのものです。
でも、発明人にもなにかおいしいことがないといけないので
20年間は発明を特許で保護されるわけです。

あんまり恥ずかしいこといわないでね。

no patent!!
no patent!!

ん？LZWはもう使って大丈夫なんですか？

解禁です。
あの子のへあーも

>>331
>>275-276,>>281

× >>281
○ >>282

rarて何使ってるの？
最近の圧縮アルゴリズムはさっぱりわからん

自己解凍書庫ってのは『解凍Exe』＋『圧縮データ』って形になってると思うんですが
『解凍Exe』はどのようにして『圧縮データ』の位置を取得してるんでしょう？

自分のサイズがわかってればいいんじゃない？

ここに詳しい人がいる
http://pc5.2ch.net/test/read.cgi/tech/1039513920/

>>335
とりあえず

　r　a　r　は　最　近　で　き　た　圧　縮　形　式　で　は　な　い　ｗ

>自分のサイズがわかってればいいんじゃない？
ふむ．．．
『解凍Exe』内部にハードコードで書込んでおく。ってのも有りか．．．しかしなんかイヤな感じが

統合アーカイバとかの自己解凍書庫てどーゆー作りになってんだろ？

>>340
良くわからんけどID3みたいにファイル末尾に前のブロックの末尾位置だの
最終ブロックないのデータの先頭位置だののテーブル持ってるんじゃない？

>>341
おいおい憶測で物言うのもいい加減にしろよ。
ストリームでもなければ末尾にヘッダを置く意味がない。
自己解凍書庫の作成はあらかじめ用意した解凍ロジック付きexeの
PEヘッダに適当なデータセクションを追加修正すれば終わり。
解凍ロジックはデータセクションで定めた決めうちベースアドレスから
データを読み取るだけでOK。
PEの仕組みとローダの知識が多少あればできる。

ソースコードが移植可能なライセンス携帯で、3kbぐらいのオブジェクトサイズの
圧縮ライブラリ知りませんか？ちょっとSymbianに乗せるアプリに実装したい
と考えています。

>>343
Huffman自作しなされ。以上

344の意訳

知りません。でも知らないって言うの恥ずかしいから煽ります。

MPGかWAVからAFSファイルを作りたいんだけど、ツールないですか？

>>346
板違い

ソフトウェア
http://pc5.2ch.net/software/

Lhaplusの作者のWebページどこへいっちゃたんだろ？
Lhaplusってあれだね、ファイル数が多いといつまで待っても
圧縮が始まらんねｗ

> Lhaplusの作者のWebページどこへいっちゃたんだろ？
http://park14.wakwak.com/~schezo/

>>349
サンクス。
lhaplusをver1.50β11にしたらサクッとスタートしてくれました。

LZ77の圧縮にハッシュも木も使ったらまずいってどうすりゃいいんだ？
LZ77を少し改造してLZ77じゃありませんよ〜とかいったらOKなんだろうか。

>>351
2-3文字をインデクスするリストを使えばいい
木とほぼ同程度の速度で動く

・・・ぶっちゃけ、2-3文字のハッシュと同じなんだがなｗ

なんか圧縮のことよくわからなくてはじめてここに来たんだけど、
とりあえず３バイト連続する同じデータがあれば２バイトに圧縮したらＯＫなんですね。
あと連続するパターン見つけるんだろうけど、俺がプログラム書いたらそんなの
時間かかってぐっちゃぐちゃでめっちゃめちゃでアウトだ

>>353
専門書も扱っている本屋へ行って、圧縮とかアルゴリズムとか、の本を買うと良い。

パターン検索は >>351-352 のキーワードを参考に。

>>352
それだとハッシュ使う特許に引っかかる可能性が残ると思われ。

圧縮率上げる工夫よりも特許を回避する方に労力を費やしてる矛盾

>>353
unsigned char c = in[i];
int count = 0;
while (c == in[++i]) count++;
out[j++] = c;
out[j++] = count;

こんな感じのルーチンで出来る。

>>355
ハッシュとは別の論文で発表されていたから、大丈夫だとは思うがどうだろう。
Bell and Kurp, 1991. だったかな？

>>358
ハッシュの特許に触れるか、だけが問題で
ハッシュと同じ論文で発表されたかは問題にはならないと思われ。

ちなみに、その論文の方法が特許化されてないのは確認済み？

とりあえず何も考えずに zlib 使っとくのが一番現実的なのかね。
仮に問題があったとしても、みんな闘ってくれるはず。きっと。多分。

>>360
zlibに採用されているハッシュ法って、まんま>>352 >>358 だよね
3文字でインデックスしたチェインリストを順に読むわけだから…

installshield の　cab 形式への圧縮が出来るツールってないですか？
既存のcabを展開して、パッチを当てて、また再圧縮したいんですけど・・

>>340
UpdateResource()を使うのもありかもね。

>>361
zlibとかのは先頭3文字を加工して使ってるからなぁ。
ハッシュでないというのは通らんと思うぞ。

加工せず使うなら、なんとかなるかもしれんが
3文字だとテーブルだけで16M*sizeof(テーブルの要素)バイトかかる。

デコードするだけなら引っかからないんでしょ？
普通のアプリなら解凍できれば十分だし

100個くらいあるファイルを、それぞれ違うパスワード(予めエクセル等でファイル名とパスワードの対応は作成しておきます)でzip圧縮したいのですが、やり方がわかりません。
エクセルのVBAで、UNZIP32.DLLを使えば良い、というのは想像出来るのですが、記述方法がわかりません。

お知恵をお貸しください。よろしくお願いいたします。

普通にコマンドライン呼び出せばいいんちゃう・・・？

解決しました！！

どうやって解決したのか書けよ

誰か366を語って書き込みしたようです。まだ解決してません。
よろしくお願いいたします。

zipファイルにパスワード付けるのは安全ですか？

>>371
はい

>>371
危険です
なぜなら371はパスワード掛けてみたはいいもののそのパスワードを忘れてしまうでしょう

>>371
zipパスワード検出プログラムが出回ってるから気休めにしかならない
本気で保護を考えてるなら止めといた方がいい

そういうときのために、ファイル名をパスワードにしておくとよいよね。

zipそのものを暗号化してしまえ

zlibでzip圧縮されたデータ(ファイルにはなってない)を受け取って
解凍しようとしてるんですが、失敗するときがあります。
で、データが正しいかバイナリデータを出力してみてみたのですが
先頭からみると↓こんな感じになってます。
---------------------
78 9C EC 5A CB 6F 1C C9 79 AF 67 77 F5 6B 1E 1C
52 5A 91 94 28 52 94 B4 14 F7 41 AD 76 B5 F1 CA
2B 6E E0 83 45 1D 12 84 30 10 60 15 C0 87 24 F0
D9 B0 BD 57 55 F7 F4 3C 49 59 4B 2A 36 10 CA 46
80 2C 95 E4 60 3A 08 90 E5 DE BC 02 F2 4F 24 B9
E4 E0 3D AE 03 04 F0 4A 39 65 F2 7D 55 DD 3D ・・・
---------------------
http://www.futomi.com/lecture/japanese/rfc1950.html
http://www.futomi.com/lecture/japanese/rfc1951.html
をみるとzipの先頭データは8かFかってことっぽいので
このデータはzip圧縮されたデータとしてはおかしいと
思っていいのでしょうか？

>377
>をみるとzipの先頭データは8かFかってことっぽいので
どうしてそういう結論になる。
先頭バイトが 0x78 なんだから、CM=8, CINFO=7 でウィンドウサイズ 32k の deflate じゃないの？
あと、zlib も zip も deflate を使っているかもしれないが、zip圧縮という言い方は語弊が
あるのではないだろうか。

>>378
二桁目がCMなんですね
ドキュメントをよく理解できてませんでした。

>zip圧縮という言い方は語弊が
このへんはよくわかってないです。紛らわしくて申し訳ないです

>379
バイトの並びとビットの並びに注意しよう。
リンク先の zlib の資料でも「2.1. 全般的な規約」に書いてあるよね？

>>zip圧縮という言い方は語弊が
>このへんはよくわかってないです。紛らわしくて申し訳ないです
俺もよく分からんが、
・zlib はライブラリおよびフォーマットの名前
・zip はフォーマットの名前
・deflate は圧縮アルゴリズムおよびそのフォーマットの名前
ってことでいいの？教えてエロい人！

deflate　圧縮アルゴリズム
zlib　圧縮ファイルフォーマット
zip　圧縮形式の名称及び拡張子

こんな感じか？

zlibは圧縮ライブラリの名前でいいと思うけど

deflate アルゴリズム
zlib バイトストリームを圧縮するライブラリ。ファイルの概念は無い。
zip 複数のファイルを圧縮したアーカイブファイルのフォーマット。

じゃないの？

>>383
それが正解

>>383
意味なんて人それぞれ。
zipを圧縮フォーマット（たぶんdeflate）の意味で使う奴もいる。

俺は deflate はフォーマットだと思うけど、アルゴリズムだと言う奴もいるしね。
deflate がアルゴリズムなら、zlib の deflate と 7zip の deflate は
同じアルゴリズムを使用してる事になるけど、俺は別のアルゴリズムだと思ってるから。

↑こういう意識のやつはこの業界に必要ない

↑オレ用語が否定されてムキになってる人？

deflateはRFCで記述された通りでいいんじゃないか?

どっちでもいい。

今、圧縮解凍ツール作ってるんですけど、
unlha32で、既にある書庫にファイルを新規に圧縮して追加したいんですけど
コマンドがわかりません。どなたか教えていただけないでしょうか？

・既存の書庫ファイル(c:\work\abcd.lzh)
a/aaaa.txt
a/b/bbbb.txt
a/b/c/cccc.txt

a/b/c/d/dddd.txt　を追加したい

・圧縮前のファイル
c:\temp\dddd.txt

a

>>391
追加圧縮はできるんですけど、書庫内のディレクトリ指定がうまくいかなくて困っています。（；_；）

Unixで暗号化ZIPファイルをプロンプトを出さずにCプログラムから作成する方法を教えてください 

キーをテキストに書き出す
テキストを読む
以下略

30 30 30 30 30 30 30 30 30 30 を圧縮すると（16進表記）
30 30 30 30 30 30 30 30 30 30 のままで

30（ASCIIで'0'）を20個つなげたやつを圧縮すると
05 30 EE FF 30　となった圧縮形式があったんだが、これなんだっけ？

ヘッダとかついてないのかね。

あげ

UNZIP32.DLLやUnGCA32.dllでパスワードがかけられてるファイルかどうか見る方法をおしえて

書庫のヘッダに書いてあるよ

パスワード付きZIPをパスワードWindowを開かずに作成する方法を教えてください

コマンドラインで入れる

もう少し詳しく教えてください

ソフトウェア板かwindows板の話題だと思うんだそれは。

実装でもアルゴリズム概念を聞いている訳でもなし。

>>402
ま、巷じゃ「圧縮がわかる本」とかいって圧縮ツールの使い方だけ教えてるのが何百冊も出てるしな…

漏れもいっちょ書いてみるか！

>>399 無理

統合アーカイバのDLLを使ってプログラミングをしているのですが、静的インポートの場合、付属のインポートライブラリを使用しますよね？
これってVC++(MS-LINK)用COFFのようですが、BCC++(ILINK32)でうまく使えないみたいなんですが・・・？(UNZIP32.DLL)
BC++付属のCOFF2OMFで変換するも、デフォルトでは利用できず、-lib:stスイッチで変換しました。
しかし名前インポートができず、オーディナルになってしまいます。
BCC++で名前インポートするにはどうしたらよいでしょうか？

って、しまった！全然間違えた！

MASM + MS-LINKでそのままリンクすると序数インポートになってしまうんだった。

<<X.ASM>>
        .386
        .model  flat,stdcall
        .code
start:
        call    UnZipGetVersion
        ret
        end     start

<<ビルド法>>
ml /c /coff x.asm
link /subsytem:console x unzip32.lib

私はVC++を持ってないのではっきりとはわかりませんが、リンカが同じなのでVC++でも名前インポートにはならないですよね・・・？
名前インポートにするにはどうしたら・・・？

>407
各処理系のスレで聞いた方がいいと思う。

implib

名前でのインポートにこだわる訳は？

>>409
IMPLIBなら確かに付属のインポートライブラリはいらないですが・・・MS-LINKはOBJ型ライブラリが使えないようなんですが・・・？

>>410
オーディナルのインポートって信用できないんですよね・・・
DLLのバージョンが上がると変わらない保証ってないじゃないですか・・・？

>>411
BCCで使うのになんでMS-LINKが出てくるんだ? わけ分からん
MS-LINKなら付属のLIB使えば済む話だろ

>>412
ですから間違えました。BCCじゃなくてMASMです。

ヒント: /coffオプション

完全に特許に引っかからない技術を教えてクレイ

>>415
特許の期限が切れたもの

>>415
bzip2,gzip

完全と言い切れるものは多分ないんじゃないかな。
知られてないだけで、所謂サブマリン特許の類のパテントが存在するかも知れないし。
bzip2のBWTも発案者が特許を取らないといっているだけだし。

圧縮ソフト作るのって床から刃の出ている廊下を歩くような感じだよ。
時々踏むと刃のでる罠が仕掛けてあったりして。
最初にアルゴリズムに特許を与えたバカは誰なんだろう。

>418
アルゴリズム特許は暗号が初めてじゃないっけ
それならこれもそれならこれもとずるずる範囲が広がっていった。

暗号の場合は納得できるんだけどねー

フラクタル圧縮もダメなんでしたっけ

>418 >419
線形計画法のカーマーカー法じゃないの？
>カーマーカー特許とソフトウェア―数学は特許になるか 中公新書
>http://www.amazon.co.jp/exec/obidos/ASIN/412101278X/249-7663900-1232317
元々の圧縮アルゴリズムはともかく、○○＋ハッシュとかいうのになってくるとどんどん納得できなく
なっていくんだが。

>421
すまんこった、カーマーカー法が最初の特許アルゴリズムだった。
ほら吹いてしまいました。ごめんさない。

Info-ZIP社のZIP32.DLLって商用で使用するにはライセンスがいるのでしょうか？
UNZIP32はいるみたいなのですが。HP読んでもわからない･･･

zip32.dllは知らんが、zlibならいらないはず。

>>414
どの/coffですか?
mlなら/coffつけてますが?>>407

hosyu

質問です。
DEFLATE圧縮では元データはバイトごとに圧縮されるのですか？
それとも6ビットや5ビットなどビット単位ですか？
RFCと一緒にzlibやgzipのソースを読んでいるのですが
自分の読解力ではわかりません。

バイト単位

>>428
バイト単位ですか。ありがとうございます。
その線で読んでみます。

ソース読んで理解できないなら>>298

>>430
やっぱりその本を買った方がよさそうですね。
今から買ってきます。

書庫が１バイト足りずに破損している場合、末尾に00を付加するという話を聞いたんですがどうやって付加するんでしょうか？
調べようと思ったんですが検索ワードが思いつかない…

>432
君が何を聞きたいかが理解できない。
とりあえず付加するのは誰？
特定のソフトの話か、特定のファイル形式の話？

>>433
漏れの予想では、ファイルの末尾に00を付加させるのに、
どんな関数orAPIをコールすれば良いか判らない

そういうレベルの質問だと思う

板違いの予感。まさかnarがどうとかって話じゃないだろうな。

1 バイトのファイルを作っておいて copy /b とか cat とか、
そんなスキルもないならバイナリエディタ。

ってところだったりして。

narってなにさ？

もしかして null ?

ナルほど

>>438
誰がうま(ry

>>432, >>435
出てきて釈明しる！

済まん、あっさりスルーされると思ってた。
「伺か」が使うアーカイブ(実態はzip)の拡張子。
公開終了したアーカイブをWebArchiveから拾ってくるって話。
まあ、オタネタだ。

補足。
WevArchiveにはファイル末尾の0を切り捨ててしまうというバグ(?)がある。
そのためせっかく昔のアーカイブを見つけてもzipが解凍できないことがある。
末尾に0を付加してやると正常に解凍できるようになる。
というのがこちらで想定した問題のバックグラウンド。

自己解決したから書き込まなかったんだけど、WebArchiveのzipファイルで〜て事が聞きたかった。
narは良く分からなかったけど、435が書いてくれたからまぁ良いかと思ってた
オレのせいで微妙な話が続いて悪かったです

zlibの使い方を詳しく丁寧に説明してる日本語サイトを教えてください。
あと、gzip（と可能ならzipも）の中のファイル名を解凍せずに知りたいんですが、できませんか？

zlib.hの英語を読むのが一番確実だと思うけど。
別に読みにくくは無いし、そんなに長くもないし。
gzio.cも。

>>443
ヘッダにテキストで書いてあるけど。

>>445
日本語って言ってるだろうが、馬鹿

日本語なかったっけ？　どっかでzlib.hのコメント日本語訳みたことがあるんだけどどこだったか…

>>446
日本語読めないのに日本語要求してたんですね。
# 単に駄々をこねてみたかっただけかな? :-P

ありがとうございました。
日本語訳はこれですね。
http://www.sra.co.jp/people/m-kasahr/zlib/zlib-1.1.4-ja.h

zlib の deflate　を利用して
自前でzipファイルを作るプログラムを作ろうと思います。
とりあえず、ここの仕様書を見たのですが、
http://www.pkware.com/business_and_developers/developer/popups/appnote.txt

extra fieldの意味がよくわからないです。
私の場合は、この部分は出力しなくて良いのでしょうか？

あげます

遠慮なく頂きます

前スレ

圧縮アルゴリズム考えたんですが
http://pc8.2ch.net/test/read.cgi/tech/1041803200/


テンプレは >>1-3 あたりには無い。

乗っ取るの？

圧縮アルゴリズム2
http://pc8.2ch.net/test/read.cgi/tech/1140946646/

圧縮アルゴリズム考えたんですが

まずデータの中にフラグの立ったビットがいくつか数えます。
そしてデータは0と1を並べ変えたものと考えます。
あとはそれを使って先頭ビットから1なら
(そこから先のビット数)Ｃ(そこから先の立ちビット数)
を計算して足していきます。
つまり圧縮するデータを0と1の並べ替えとしたときに、
それらを辞書順に並べて上から何番目かを数えるということをします。

例)8ビット中3ビット立ってるとして
10001100
最初1なので
7Ｃ2
を計算。0は読み飛ばし次の1でも
3Ｃ1
を計算。これ以上は変わらないので終わり。
で、上の二つを足す
7*6/2*1+3/1=24
あとはこの数と圧縮前のファイルサイズと立ちビットの数だけ出力すれば復元可能。

こいつはすげぇやとｵﾓて作ったら799バイトのデータを50分かけて圧縮して何番目のデータかの数値だけで2972バイト悔いました。
Ｃ(コンビネーション)て恐ろしいな

俺を圧縮してみろ！！

>>456
Lynch-Davisson 符号とか数え上げ符号を調べてみて

圧縮にはならないって事か？調べたけどあまり無くて分からなかった

10年くらい前、bzip で使われている
ブロックソートが何故圧縮にいいのか証明されていない、
と聞いた気がするんだけど、今はもう証明されているの？

( >>460 http://www.google.com/search?q=BWT+MTF&lr= )

>>460
有村　とか　Effros の論文読んでみて

>>463ごめん後半からわかんなかった…

ところでJAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト見ながら自分なりの解釈で作ったんだけど
76Kbのビットマップをデフレで圧縮したら44Kbになったのね。
で、7zのZIPで圧縮したら37Kbになったのよ。
これって何がいけないの？Lhacaも7zより圧縮率悪いけど
どういう工夫すれば縮むようになるん？

教えてエロい人！

AGE

ハフマン圧縮について教えてください。

よくあるのは、出現率の低いものを２個取り出して、その和をつくり、さらに残ったなかから一番出現率が小さいものをとりだし、
これと、先ほどの和の結果との和をとり・・・
という説明です。

でもなんか要するに出現数のおおい順にソートして（出現ゼロ回のものは無視する）
A,D,B,C,・・・みたいに配列に入れます。
そして順に、1,10,110,1110,11110・・・
と符号をふればいいだけのように思えてしまいます。
なぜ小さいものを取り出して和を作り、さらに小さいのと和をつくり・・みたいなことをする必要があるのでしょうか？

最初俺もそう思ったけど、ちょっと考えたらそれじゃ意味ないことに気づいたんだよ
なんでかって？忘れたなぁ…

>>466
それは unary 符号（単進符号、一進符号）というもの

符号が最適になるには条件というものがあって、
unary の場合、記号の出現確率が 1/2, 1/4, 1/8, ... となる場合にのみ最適な符号を構成できる
一方、Huffmanはどんな出現確率の記号群に対してでも最適な符号を構成できる

なるほど。よくわからないけど間違っていたことだけはわかりましたｗ
ありがとうございます！！！！！！！！！

JAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト
教えてくれ俺もみたい

データ圧縮法概説
というところ。その名の通り原理や概念を解説しているだけでJAVAどころか
プログラミングにすらふれていない。
でも説明は分かりやすいからJAVAでも作れた。

データ圧縮法概説
ないよ
どうすればいいの？

Internet Archive

つーか、ちょっとリンクを追いかけていけば生きてるサイトにたどり着いたぞ

どうやっておいかけるの？

我楽多頓陳館で検索。
管理人は一人で何役もこなすアニメ好きの54歳
世露死苦!!

見つかった？

今zip圧縮のサンプル作ってる

それはzlibとか使って？それとも圧縮部も自作？
自作だったら性能を上げる工夫とか教えてほしいです。

圧縮部分も自作です。組み込みに乗せるから
パフォーマンスそこそこでだいたい2kから10ｋいないの
zlibを作成しようとしてます。なので性能よりもマシン語
の吐かせた内容をコンパクトにすることに命をかけています。
私も工夫とかよく解らない部分が多いため、IEEEの論文などをいくつか入手し
勉強をしているところです。アルゴリズム的に速度を上げる方法と
コーディングレベルで最適化する方法2つの視点で最適化について
考えていますがまだ道のりは厳しいです

特許まわりはどうなのかしら?

現在猿でも分かるC言語講座をみながらJAVAでブロックソートとMTFとレンジコード制作二日目。
Cはよく分からんがブロックソートの符号化とMTFの符号化･復号化が完成
ブロックソートの復号がうまく行かない…

Huffman圧縮で質問です。
記号が一回しか登場せず、２分木が１つも作成できないような場合、
その記号にはどんな符号を割り当てるのですか？

多分最初に出現する記号の種類の数もカウントしてるんだろ？
俺はその値が1になる場合は2にしてもう一文字あると仮定して
やってる。その文字は何でもいいが大抵は0x0だな

>>483
「記号が1種類しかない」フラグを作って、記号を記録しとく。
「記号がいくつ現れたか」も記録しとけば、記号は全部空ビット列に変換で良い。

ありがとうございます。
>>484
なるほど。それならアルゴリズムに大幅な変更はいらないですね。
>>485
そうですね。Huffmanにこだわらずにってことですね。

今からどっちにするか迷います。ありがとうございました。

動的ハフマンって実装自体は特許事項に
抵触技術内容含まれてないですよね？

大丈夫でしょ。やり方にもよるかもしれないけど、まあ普通に作れば無問題

動画配信のMPEG４とかH264ってのは適合型ハフマンで送るのですか？
もしそうならパケロスしても大丈夫な理由を教えてください。

やっとJAVAでブロックソートとMTFとRLE7とレンジ圧縮(圧縮だけ)
ができた。でもサイトにあるほどの圧縮率が出ないwwwww
なんで…orz

>>490
どこのサイトかしらないけど、結果だけ載せている場合は、かなり細かいチューニングや、
アルゴリズム改良が加えられていることが多い。

ソース・実行プログラムもあるなら、圧縮結果をバイナリ比較するとか、
サイトのプログラムによる出力を自作プログラムで展開させてみるとか（あるいはその逆）、
圧縮結果のバイナリそのものの解析をしてみたらどうだろう。

猿でも分かるプログラミング講座とかいうとこだったはず
Cのソースがあったから移植してみたブロックソートは間違いないからなぁ…
まあいろいろ結果を調べてみる

>>492
Cのソースプログラムが公開されているので、
1ステップずつ動作を追っていけばいいのではないか

途中の変数の状態を確認したり、演算結果に差異がないかを調べたり

いい忘れてたけどCのコンパイラとか持ってないんだ。
落とさなきゃだめかな？

今や、GCCコンパイラだけでなくMSコンパイラも無料。
「資金がない」で逃げる行為はもはや言い訳にならなくなった。

重いの入れたくない。はあり？

なし、軽いの入れればいい

sumという38000byte位のファイルを圧縮した結果250byte位劣って13Kb程になった。
実はヘッダなどの付加のしかたが微妙に違うのだがそれだけで
こんなに差が出るもんかな？ちなみに
BlockSort->MTF->ZLE+RLE7->RCA
って感じで4段階で圧縮してます。ヘッダ情報はどれもこっちの方が少ないのに…

>>498
アルゴリズムや定数も同じで、各段階でのヘッダも小さいのに
出来上がりファイルが大きいのなら何かバグってるんでしょうね。

>>499え!?マジで？℃チクショウーーーーーーーーー!!!!!

困憊羅が雨後かねぇwwwwwwwww!!!!!!

2chの圧縮ダットを解凍するにあたって資料が欲しいのですが、どこか頼みます。

TextSS　の64bit化おながいします

もしくは64bitにネイティブ対応した置換ソフトないですか？

新しい圧縮アルゴリズム考えようぜ!!

>>504は>>1も読めないのか

だってアルゴリズムスレ無いしここの再利用で十分だろ？
2chの無駄も減って一石二鳥だね

昨日、カミさんに怒られてrar圧縮されたさ
めっちゃ苦しかった

KWSK!!!!

へいっ!!!ついにやったぜ
JAVAにブロックソートとMTFとZLE7と適応型RANGEを移植完了!!ながかった〜
圧縮率は7z>BZIP2≒俺の>ZIPという感じ
これからは圧縮されたデータをさらに圧縮できるようにする変換でも考えるﾉｼ

ZIP圧縮について質問です。

zip32.dllに圧縮したいフォルダパスを-rオプションで渡した場合
zip内に格納されたファイルがドライブTOPからのフルパスで格納されてしまいます。

指定したフォルダ以下のみを格納するにはどうすれば、よいのでしょうか？

SetCurrentDirectoryしてから、相対パスで指定すればいいんじゃね？

511>

無事にできました(^-^;
ありがとう

正確には圧縮アーカイブではないですが、ISOイメージファイルのフォーマットが書いてある場所を探しているのですが、いいのはないですか？ とりあえず日本語のは見つかりませんでした。イメージファイルでないISO-9660自体の解説はあるのですが・・・

商用フリーな圧縮解凍ライブラリってありません？
利用はWindowsです。

http://cise.edu.mie-u.ac.jp/~okumura/compression/zlib.html
ここのサンプルcomptest.cで解凍しようとしても、エラー起こして解凍できないんだが、できます？

これで圧縮したのはこれで解凍できるな。
しかし、他で圧縮したのはこれで解凍できないし、これで圧縮したのは他で解凍できない。
ヘッダー？　ヘッダーの処理はzlibはしてくれないんですか？　初期化時にヘッダー付きを渡すとポインターとカウンターが変わるかもしれないと説明には書いてあるが、実際変わらない。　

zlibはdeflate処理をしてくれるだけでZIPファイルフォーマットの解釈はやりませんよ。
その辺は自作汁。

この辺の本を読んでみるとよし…と思う
http://www.amazon.co.jp/exec/obidos/ASIN/4797324287/

zlibを使ってデータの伸張をやろうとしてて

byte *src // 圧縮されたデータ
int len // src の長さ
byte *dst // 解凍されたデータの格納先

dst = malloc(5 * len * sizeof(src));
decompress(dst, src, len); // src を展開して dst に格納
// 適当な処理
free(dst);

みたいなことをやろうかなと考えているんですが、dstで確保したメモリが足りなかったときのことを
考えるとこれじゃあマズいでしょうし、あらかじめ必要なメモリの計算は解凍処理をしないと
分からないようだしでちょっと困っています。
皆さんならどうしますか？

圧縮も自前なら圧縮データとは別に（先頭につけるとかして）、
圧縮前のデータのサイズも持っておく。

ちなみにsizeof(src)は4バイトだろ。

CABについてお願いします。

CABファイル内のデータが欠けている場合にファイルを取り出せる可能性についてですが・・・

<CFFOLDER数=1>
CFFOLDER[0]
CFFILE[0]
CFFILE[1]
CFDATA[0]
CFDATA[1]

このような構造になっていて、CFFILE[1]が指すデータオフセットがCFDATA[1]内を指しているものとします。

この時にCFDATA[0]がまるまる欠けている場合、CFDATA[0]に適当なダミーデータを押し込むことによってCFILE[1]のファイルを取り出すことはできるでしょうか？

MSのツールEXTRACT.EXE等で調べたところ、どうもCFDATA[0]が完全でないとCFFILE[1]のファイルは取り出せないみたいなのですが・・・

圧縮法はLZXです。

後ろの方(例えばCFDATA[2])が欠けている場合はそれがファイル内容にかかっていても途中までですがデコードできるようです。

>513
普通の ISO イメージファイルだったら ISO-9660 に書かれている内容がそのまま直列で入っているだけだと思うが。

圧縮する前に圧縮後のファイルサイズのおおよその見当をつけるプログラムを
書こうと思ったんだけど、(ファイルサイズ) x (情報エントロピー) で計算すると
全然いけてないですか？

>>523
圧縮につかうモデルでのエントロピーでないとまともな数字が出ない。
ある程度でも結局圧縮するのと同じになってしまうのであまりいけてない。
まあ、とりあえずモデルを特定しないでHuffman,算術符号,RangeEncoderなどの
エントロピーを出しておけば最低保証値だけは出せるかな。

> 最低保証値
=元のファイルサイズ

ただ、圧縮アルゴリズムと対象データによってはサイズが増えることもありうる希ガス
もちろんその場合は圧縮しなければ元のサイズなんで圧縮しなければいいんだけど
「元のサイズ分あれば十分だろー」ってメモリ確保してやってみらたオーバーフローとか
かっこわるいことになることがあるかもしれない…？

>>526
そういうときは、1回の処理で増えうる容量分だけ余分に確保しておけばよい

その見積もりができないとか、1回で無限増殖しうるとか、そういうのはしらね
アルゴリズムを見直すか、出力方法を考え直すべきだがな

UDPのパケット（1K〜3K)を圧縮して転送、
受信して展開して、通信をやりたいと思ってます。
流すデータは未圧縮の画像データを分断して送受信します。
LZOのような、圧縮・展開の速いプログラムってないでしょうか？

>>528
LZOではだめなのかい？
Huffmanあたりをまず試してみて、圧縮率・速度の検討をしてみてはどうか

>>529
GPLなので困ってます・・・
＞Huffman
なるほど、試してみます。

LZMA SDKを落としてJavaのソースを動かしてみたところ、
コンパイルは何とか通ったのですが実行できません。

ファイルの初期配置も何だか変な気がするのですが…。

これ、何か不具合でしょうか？
それとも私が何かの設定間違ったのでしょうか？

誰かわかる人いたら教えてください。

てか、やっぱりこういう用途でJavaって邪道なんですかね。
扱ってるサイトも見ません。

>>531
こういう用途ってどんな用途だよ

>>532
その辺からサンプルソースを落として
とりあえずコンパイルすれば何もせずに
目的のものが手に入ると思ってる用途

だろ？

スルーされたと諦めて見てなかったり。
気まぐれで覗いてみたら回答というか煽り文句がついてて
嬉しいんだか悲しいんだか。
亀ﾚｽになるけど、せっかく返事もらったし。

>>532
ツールを作る用途のつもりで書きました。
ゲーム制作だとかは（使えねぇと言いつつ）結構あるんだけど…
ツールの例がちょっと見つからなかったので。

調査不足ですか。ごめんなさい…。

>>533
適切な分析をどうもありがとう。
とりあえず、パッケージの設定と配置されてる階層が明らかに違うものがあったのですよ。
ちゃんと動かしたら治ったけどね。
サイトのミスかこっちのミスか気になったんだけど
自己解決と言うか自己完結。どうでもよくなっちまった。