03/09/30 00:32
>>158
その違いが辞書の違い、すなわち、手法の違い。
LZ'77, LZ'78 くらいでよいから、参考書で勉強すべし。
160:155
03/09/30 09:34
なるほど。もちっと本読んで勉強します。
ありがとうございました
161:デフォルトの名無しさん
03/10/01 03:23
LZSSのソース（作者が使用してもよいと言ってる物）欲しいんですがどこにありますか？
へたれなのでアルゴリズムﾊﾟｸﾘたいのですが。
162:デフォルトの名無しさん
03/10/01 09:05
>>161
おまいは奥村先生の「最新アルゴリズム事典」を枕にして勉強しる。
163:デフォルトの名無しさん
03/10/01 11:55
>>161
おまいは奥村先生に足を向けて寝ていはいけない。
URLﾘﾝｸ(www.matsusaka-u.ac.jp)
164:デフォルトの名無しさん
03/10/01 12:38
>>162-163
奥村先生のソースコードは落としましたがあれは本当にLZSSの基本実装みたいな形ですよね？
だもんで速度的にちょっといけてないかなーとへたれ心に思ってみてり。
因みにツリーを使わずハッシュを使うと特許に触れるんでしたっけ？
165:デフォルトの名無しさん
03/10/01 12:42
>>164
LHA, gzip はハッシュを使って実装されている。
つーか、へたれを自称する人は基本をおろそかにしてはいけない。
とりあえず、LHA か gzip のソースを読んでみてわからなかったら、
素直に奥村先生を拝むこと。
166:デフォルトの名無しさん
03/10/01 16:20
>>161
これはどうだ？
URLﾘﾝｸ(www.ingnet.or.jp)
167:161
03/10/01 18:31
>>164
へたれだからこそｺﾋﾟﾍﾟなんだよ!
ハッシュ化するのは問題ないんですね。少し勉強して奥村先生コードに手を加えるか…。
>>166
確か最初に落としたけど研究目的以外はx(ﾒｯ)なんすﾖ。
168:デフォルトの名無しさん
03/10/03 19:24
>>164
LZSS系列だとツリー使っても特許の地雷だらけなのよね。
ハッシュ使っても地雷だらけ、ってのは変わらんけど。
169:デフォルトの名無しさん
03/10/30 00:40
>>168
特許の有効期限、いつになったら切れるんだ？
170:デフォルトの名無しさん
03/10/31 19:29
特許発効から20年ほど
171:デフォルトの名無しさん
03/12/10 17:03
MACのsit形式の仕様書はいつになったら公開されるんですか
不便でしようがありませんよ！
どこかに解析資料とかないでしょうか
172:デフォルトの名無しさん
03/12/10 18:27
>>171
こんなのとか。
URLﾘﾝｸ(www.stuffit.com)
173:デフォルトの名無しさん
03/12/10 20:54
>20年ほど
長いよねぇ
174:デフォルトの名無しさん
03/12/11 09:10
>>172
ありがとう
登録制なのか…やだなぁ
175:デフォルトの名無しさん
03/12/12 18:03
URLﾘﾝｸ(www.cmagazine.jp)
この本とかはどうだろ？
176:Ｃ+++
03/12/21 01:28
>>10
激しくﾜﾛﾀ（笑）。
177:デフォルトの名無しさん
03/12/29 14:16
>>171
URLﾘﾝｸ(www.speakeasy.org)
178:デフォルトの名無しさん
03/12/31 05:25
圧縮といえば、2年くらい前にすげー大ボラ吹いた奴が
海外にいなかったっけ？
179:デフォルトの名無しさん
04/01/04 19:53
>>178
1/100に圧縮できるってヤツか?
180:デフォルトの名無しさん
04/02/03 08:06
あげ
181:デフォルトの名無しさん
04/02/03 13:15
おまえらエントロピーくらいわかってるよな？
182:デフォルトの名無しさん
04/02/03 13:17
圧縮・燃焼について語れ
183:デフォルトの名無しさん
04/02/03 13:23
ロータリーエンジンはすごいって事話す事になったんですか？
184:デフォルトの名無しさん
04/02/03 13:27
ロリータエンジン
185:デフォルトの名無しさん
04/02/03 13:32
LZ系で小さいやつ
(コードサイズが小さくて、
符号化・復号化だけで余計な機能がなく、
復号が速いやつ)
ない？
アプリにこっそり組み込んで使いたいんだが。
186:デフォルトの名無しさん
04/02/03 13:40
>>178-179
ZeoSyncｷﾀｰｗ
懐かしいな。
187:デフォルトの名無しさん
04/02/03 14:24
>>185
奥村LZSSでもつかっとけ
188:デフォルトの名無しさん
04/02/03 14:27
THCompが最強
189:デフォルトの名無しさん
04/02/03 15:16
>>185
MS-COMPRESSを呼び出すのが簡単かつ確実
190:デフォルトの名無しさん
04/02/04 16:08
>>189
WinでもAIXでも使えるのをおながいします。
191:185
04/02/04 17:25
昔の7行スレのやつ使うことにしました。
ちょっと遅いけどすげー小さいので。
ちなみに190は偽物です。
192:デフォルトの名無しさん
04/02/05 14:15
む、7行であったのか
193:デフォルトの名無しさん
04/02/06 03:04
>>192
7行のだと、Huffman, rangecoder, LZ77系, RLEなら、
それぞれ2つ以上の実装が出ていたはず。
LZ78とかBPEとかもあった。
194:デフォルトの名無しさん
04/02/15 14:20
>>192
これかな？
URLﾘﾝｸ(www.isl.cs.gunma-u.ac.jp)
195:デフォルトの名無しさん
04/02/16 06:46
違う
196:デフォルトの名無しさん
04/04/04 02:30
数MのXMLを短時間で圧縮解凍したいんですが、圧縮率とパフォーマンスのバランス
の取れた圧縮アルゴリズムってなんでしょう？
XML → 無駄なコード削除 → ブロックソーティング → MFT → ランレングス
でやってみたんですが、圧縮率は満足なもののブロックソーティングが遅すぎて
使えませんでした。もちろん、高速化は可能だと思うのですが…
197:デフォルトの名無しさん
04/04/04 10:23
>>196
まずbzip2で試してみて、それでも遅ければブロックソートは向いてない、
十分な速度ならブロックソートの高速化が甘いかと。
ブロックソートの高速化についてはこちらなど
M.Hiroi's Home Page URLﾘﾝｸ(www.geocities.co.jp)
white page URLﾘﾝｸ(homepage3.nifty.com)
198:じんばん
04/04/19 20:46
すいません、javaで圧縮・解凍プログラムの作成を試みているのですが、
どこか良いサイトあれば教えてください。
jarでなくてgzipの話です、念のため。
199:デフォルトの名無しさん
04/04/19 21:13
そういったアルゴリズム関連の場合、
いきなりJavaソースを探すのではなく、
C/C++をJavaに翻訳することを薦める。
200:じんばん
04/04/19 21:16
>199
javaには、圧縮関連のインタフェースが提供されているはずなのですが。。
圧縮クラスだとか圧縮メソッドのような。。
201:デフォルトの名無しさん
04/04/20 00:11
>>198
> 標準的な ZIP ファイル形式および ＧＺＩＰ ファイル形式を読み取ったり、書き出したりするためのクラスを提供します。
URLﾘﾝｸ(java.sun.com)
202:じんばん
04/04/20 00:34
そこはおとずれました。サンプルプログラムを教えてください。
203:じんばん
04/04/20 00:55
見つけた。
URLﾘﾝｸ(www.atmarkit.co.jp)
204:デフォルトの名無しさん
04/04/20 06:49
マルチメディアのファイルフォーマットを作成中なのですが
ストリーミングに向いた、圧縮方法を教えてください。
205:デフォルトの名無しさん
04/04/20 06:51
>>204
うぐっ！
書き損ねた。>>204は携帯電話によく搭載されてるSMAFみたいな
奴を考えてます。
206:デフォルトの名無しさん
04/04/20 06:57
ストリーミングと圧縮はあまり関係ないんじゃないのか？
あえて言うなら、ストリーミングにはデータ欠損が付き物なので
データが足りなくても質を下げて再生できるようなフォーマットが必要だろう。
最初の数パケットで数フレーム分を荒く再生できるとか。
207:デフォルトの名無しさん
04/04/20 07:24
>>206
すると、圧縮しないほうがいいってことでしょうか？
208:デフォルトの名無しさん
04/04/20 07:35
いや、そういう意味ではなくて、ストリーミングに適しているかどうかは
アルゴリズムよりも実装の問題だという事。
圧縮は当然する。
しないと送受信が間に合わないでしょ。
といっても具体的に知っている訳じゃないので一般論でしかないけどね。
とりあえずmpegとか調べてみては如何かな？
209:デフォルトの名無しさん
04/04/20 10:06
>>204
「携帯 ムービー フォーマット」でググればそれらしい形式が出てくるんだから
更にそれらのフォーマットを調べれば済むんじゃないかなぁ。
210:デフォルトの名無しさん
04/05/17 18:53
質問です。
backup[1]という名前のフォルダの中に次のようなファイルが入っているとします。
regcopy.exe
help.chm
online.htm
readme.txt
別のbackup[2]というフォルダの中にもbackup[1]と全く同じファイルが入っているとします。
このbackup[1]とbackup[2]のフォルダをそれぞれLZH形式に圧縮します。
圧縮したこれら２つのファイルのバイナリを比較したところバイナリが一致しません。
上記４つの各ファイルのバイナリは一致しているのに、なぜ圧縮すると圧縮ファイルのバイナリが一致しなくなるのでしょうか？
宜しくお願いします。m(ﾟдﾟ)m
211:デフォルトの名無しさん
04/05/17 18:55
釣りか?
フォルダごと圧縮してるなら、フォルダの名前が違うから。
212:210
04/05/17 19:13
>>211
いや、最初はそれが原因かと思ったので、フォルダ名を同じにして圧縮してみたんですが、
やはりバイナリが一致しないんですよ。
どうやら、フォルダ名はバイナリに反映されないようですね。
今度はZIP形式に圧縮し直して試してみたんですが、やはりバイナリが一致しません。
うーん、、何故？なぜなんだろう。。
213:デフォルトの名無しさん
04/05/17 20:50
フォルダのタイムスタンプが違うんだろ。たぶん。
タイムスタンプも統一(偽造)してやってみて。
214:210
04/05/17 21:30
>>213
レスありがとうございます。
タイムスタンプは一致させているんですが、やはりバイナリが一致しません。
どうやら、ファイルの圧縮順が違ってみたいです。
例えば、backup[1]では、
regcopy.exe→help.chm→online.htm→readme.txt
のような順で圧縮処理しているのに対し、backup[2]では、
help.chm→online.htm→readme.txt→regcopy.exe
のような順で圧縮処理しているようなのです。
つまり、圧縮書庫内に格納されているファイル順が異なるため、バイナリが一致しないようなのです。
そこで、フォルダ内のファイルを名前順で並べかえてから圧縮したのですが、圧縮順は変わらないままです。
何か良い方法はないものでしょうか？
OS：WinME
アーカイバ：Easy圧縮
215:デフォルトの名無しさん
04/05/17 22:19
ファイルの列挙順はファイルシステムに依存するから、
それを制御するのはWindowsでは難しいだろうな。
ところで個人的には「どうしてそうしたいのか」が不明なんだが。
216:210
04/05/17 22:35
>>215
なるほど、やはりファイルシステム依存でしたか。
アーカイバ側の設定で名前順でソートしたらバイナリ一致確認できました。
＞ところで個人的には「どうしてそうしたいのか」が不明なんだが。
書庫内の格納順が名前順になってないと、解凍後に名前順に並べ替えないといけないんですよ。
これって気になりませんか？
217:デフォルトの名無しさん
04/05/18 02:51
いや別に並び順なんてのは表示の問題であって
内部処理がどうなってようが気にならんがね。
実際FATだかNTFSだかがどんな順番で格納してるかなんか
気にしてないだろ？ もちろんファイラで一覧表示するときは
なんかの基準でソートされてないと見づらいけどね。
アーカイブも同じだと思う。実際にどの順で格納されてようが
別に気にならないな。中に何が入ってるか表示するときに
ソートすればいいだけの話だから。
218:デフォルトの名無しさん
04/05/21 20:25
>>216
勝手に並べ替えされると「あぁ、名前順に格納されてるのか」とか考えるバカが出るような気もするが。
219:デフォルトの名無しさん
04/05/25 02:38
ファイルを圧縮するんじゃなくてメモリ内のデータをファイル名を指定して直接
ＬＺＨ圧縮ファイルに出力したいんだけどやっぱハフマン法とか勉強しなきゃできないん？
220:デフォルトの名無しさん
04/05/25 02:45
>>219
zlibならそういう使い方もできるんだが、LHAでは聞いたことないな。
LHAという縛りがあるなら勉強してクローン作るしかないかもしらん。
LHAじゃなくても良くて単に圧縮したいだけならzlibが使えると思う。
221:デフォルトの名無しさん
04/05/25 02:55
>>220
レスサンクス
ＬＺＨ圧縮しる！っていわれてるんで参考書でも買ってきて勉強しマフ
222:デフォルトの名無しさん
04/05/25 09:58
>>219
unlha32.dll で UnlhaCompressMem とか使えばできなかったっけ？
223:デフォルトの名無しさん
04/05/25 11:26
>>222
情報サンクス
ちょっと試してみますた
メモリ圧縮は可能だけど解凍ソフトで解凍してもファイルが出来ないよ・・orz
やはり自作しるしかないのか・・はぁ・・
224:223
04/05/25 13:18
出来ないと思ってたのは自分のミスですた・・・
これでデータ長がDWORDの設定範囲を超えるデータを
１ファイルにまとめることが可能なら・・・これで十分いけそうでつ
>>220さん
>>222さん
ありがたう！
225:デフォルトの名無しさん
04/06/05 19:13
自動解凍のプログラムを作るのに参考になるページはありませんか？
解凍後にいろいろ処理をしたいのですが、既存のをそのまま使うのは
無理そうなんです。
解凍後に指定のEXEファイルを実行、というのでは解凍中のエラー時の
処理などがカスタマイズできないので使えないんです。
226:login:Penguin
04/06/05 23:20
>>225
makeとかantとかを強制させるとか
227:デフォルトの名無しさん
04/06/06 03:31
>>225
installshield(?)を参考にしる
228:デフォルトの名無しさん
04/06/07 18:21
>>225
プログラムの参考にはならないだろうが、
DGCAが、自動解凍後に任意のプログラムを実行する機能を持っている。
229:デフォルトの名無しさん
04/06/09 06:11
>>228
そんなんlhaだって持ってるぞ。
っつーか普通は持ってるんじゃないか？
230:デフォルトの名無しさん
04/06/09 16:25
>>229
% lha --version
lha for unix version 1.14g
% lha
...
LHa for UNIX V 1.14i Modified 2000 Tsugio Okamoto
ごめん。よくわかんない。
DOS版にはそういう機能があるの???
231:デフォルトの名無しさん
04/06/10 02:40
>>230
そもそもunix版では自己解凍書庫つくれんだろーが。
232:デフォルトの名無しさん
04/06/10 12:26
>>230-231
sharの仕組みを導入して何でも自己解凍化してしまえばok
233:デフォルトの名無しさん
04/06/16 19:54
234:デフォルトの名無しさん
04/06/20 20:35
235:デフォルトの名無しさん
04/06/20 20:53
既存圧縮アルゴリズムを上回る圧縮率を開発できれば食いっパくれないんだろうなぁ
236:デフォルトの名無しさん
04/06/20 21:00
たかだか 1%程度改善できても誰もよろこばんと思われ。
237:デフォルトの名無しさん
04/06/20 21:04
開発しただけではどうだかな。その後のマーケティング次第でなんとでも。
それに圧縮率だけなら既存のでもシャノン限界に肉薄しているのがあるし、
圧縮速度やメモリ効率や使い勝手も優れてないとこれから普及するのは難しい。
238:デフォルトの名無しさん
04/06/29 10:52
いま，バッファにあるデータを
圧縮したり，展開したりする必要があるんだが，
統合アーカイバプロジェクトにあるような
圧縮展開ライブラリは「ことごとく」，
ファイルから入れて，ファイルに出すような，
API しか用意していない．
バッファで使えるようなライブラリ知らない？
239:デフォルトの名無しさん
04/06/29 11:02
>>238
少なくとも unlha32.dll と unzip32.dll はメモリから圧縮、解凍できるが。
っつか、>>222 で既出。
240:デフォルトの名無しさん
04/06/29 13:33
>>239
lnlha32.dll では圧縮したデータを直接バッファに
出すことはできない
unzip32.dll では圧縮そのものができない
241:デフォルトの名無しさん
04/06/29 13:39
だとすると素直にzlib使う感じかなぁ。
242:デフォルトの名無しさん
04/06/29 18:29
すいません。馬鹿な質問かも知れませんが圧縮ってどうやってやるんですか?
例えばバイナリは1バイトで必ず0～255の値しか取らないじゃないですか。
それを圧縮したら戻らなくなっちゃう気がするんですけど…
243:デフォルトの名無しさん
04/06/29 19:01
>>242
まずはこの辺読めば？
URLﾘﾝｸ(homepage1.nifty.com)
244:デフォルトの名無しさん
04/06/29 19:15
>>240
それなら、バッファにあるデータをバッファに圧縮、展開と書かないと分からないよ。
展開はともかく、圧縮データをバッファに吐くのは
圧縮できなくてデータが増える事も考慮すると、ちと面倒くさいね。
245:デフォルトの名無しさん
04/06/29 22:07
要するに可逆圧縮は連続データがなければ圧縮というよりファイルサイズが増えるってことですかね…
なんとなくわかりました。ありがとうございます。
246:デフォルトの名無しさん
04/06/29 22:31
>>245
ほとんどわかってないぞお前。
247:デフォルトの名無しさん
04/06/30 07:19
>>243
そこはLZ78符号 ≒ LZ77符号 ＞＞ 算術符号 ＞ ハフマン符号 ＞＞ 連長符号
みたいな比較をしていて解説としてはちょっとおかしいぞ。
LZ符号と算術・ハフマン符号を比較するのは無理がある。
248:デフォルトの名無しさん
04/06/30 08:59
>>244
> 展開はともかく、圧縮データをバッファに吐くのは
> 圧縮できなくてデータが増える事も考慮すると、ちと面倒くさいね
ん？ 意味わからん
ちぢまない最悪のケースを考慮して，
バッファを用意させればいいだけの話じゃないか
249:デフォルトの名無しさん
04/06/30 09:29
>>248
最悪のケースを調べるのが面倒くさいって事。
deflate でやるなら deflate のフォーマットを調べないと最悪のケースはわからん。
適当にやると不具合が出たときに泣きを見ることになる。
250:デフォルトの名無しさん
04/06/30 09:36
GCAってのはどれだけ優秀なの？
解凍速度優先型らしいけど、ホントにゲームに使ってる方いらっしゃる？
251:デフォルトの名無しさん
04/07/03 03:22
たとえばランレングス法とかのように("aaabbc" => "a3b2")
日本語を含む文字列(char型の配列)を圧縮して、
出力がバイナリでない圧縮方法はないですか？
ランレングス法は通常のテキストだとあんまり意味がないもんで。
252:デフォルトの名無しさん
04/07/03 04:36
>>251
そんな特異な圧縮方法はありそうにない。
ってか、ほとんど仕様が決まってるじゃん。自前で用意しる！
253:デフォルトの名無しさん
04/07/03 06:35
>>251
君は>>242だな？
>出力がバイナリでない
意味が良く分からん。
もう少し圧縮について勉強しなさいな。
254:デフォルトの名無しさん
04/07/04 22:44
失礼いたします。
LHAやzlibでの、LZ系の高速化手法について詳しく述べられている
サイトってございませんでしょうか？
255:デフォルトの名無しさん
04/07/05 12:01
>>254
サイトは知らないが、論文はいくつかある。
256:デフォルトの名無しさん
04/07/05 17:44
>>254
ランペル・ジブ系一般に対する高速化の手法ではなくて、
LHAやzlibが採用してる手法について知りたいってこと？
後者なら、LHAについては1970～80年台の古い雑誌に解説記事が載ってたな。
zlibはソース見るのが早いかも。いずれにしても、奥村先生のとこの記述がとっかかりになるはず。
URLﾘﾝｸ(oku.edu.mie-u.ac.jp)
前者だと、論文とか特許文書あたりの範疇になるのかな。これはさすがによくわかんね。
257:デフォルトの名無しさん
04/07/05 18:54
教えて頂いてどうもありがとうございます。
>>256
後者の方です。
258:デフォルトの名無しさん
04/07/05 19:37
gzip.dll用のCのヘッダーファイルが存在するのかどうか、
どなたかご存知でしたら教えてください。
当方VC6.0で圧縮モジュールを作成したいと考えています。
259:デフォルトの名無しさん
04/07/16 12:43
260:デフォルトの名無しさん
04/07/16 12:54
>>258
URLﾘﾝｸ(www.gzip.org)
261:デフォルトの名無しさん
04/07/16 13:04
人生に密着した、圧縮と解凍。
URLﾘﾝｸ(www.newforeskin.biz)
262:デフォルトの名無しさん
04/07/26 19:06
LZとかその他の理論を基本的な手法を解説した本ってあまりないよね
なので、見つけたら即買ってしまう・・・
263:デフォルトの名無しさん
04/07/26 19:48
「ＬＨＡとＺＩＰ」つー、マンマの本はどうなのかな。
オレは読んだこと無いけど(苦笑)。
Cが読めるなら、理解できるんじゃないかな。
オレはCを読めないので本当のトコは知らないけど(苦笑)。
アルゴリズムだけなら、上の本の作者の若い片割れの
ウェブサイトに、基本的にトコがカンタンに載ってるよ。
オレはそこ読んでLZSS+ハフマンのアーカイバを作った。
264:デフォルトの名無しさん
04/07/27 15:20
>>262
理論を解説した文書が欲しければ論文を読むか、情報理論の教科書を探せ
手法を解説した文書ともども、amazonで買える
そもそもの大問題として、LZそのものの理論解析が実はあまり進んでいないという
確率推定問題に置き換えての証明やらは腐るほどあるが、派生手法に適用が困難
265:は ◆cplnFO9T0I
04/07/27 21:39
gzipの解凍と圧縮の仕方を知りたい。
266:デフォルトの名無しさん
04/07/28 00:48
>>265
ソースプログラムを読もう
アルゴリズムを知りたければRFCを読めばおｋ
267:デフォルトの名無しさん
04/07/28 07:35
LZMAをマイナーOS環境にポーティングしようと思ったら、LZMA SDKの
コードそのままでメークできてしまった。色々いじって楽しもうと思ったのになあ・・・。
268:デフォルトの名無しさん
04/10/18 13:37:47
zip32.dllをダウンロードする場所を教えてください
269:デフォルトの名無しさん
04/10/18 13:44:18
>>268
googleで検索することをオススメします
270:デフォルトの名無しさん
04/10/18 13:45:23
いいから直アド教えれこのくずが
271:デフォルトの名無しさん
04/10/18 13:49:52
_, ._
（ ﾟ Дﾟ）
272:デフォルトの名無しさん
04/10/18 14:29:44
ごめん・・・
もうゲットしちゃった(*´д`*)
273:デフォルトの名無しさん
04/10/18 15:01:19
(ﾟдﾟ)
274:デフォルトの名無しさん
04/10/18 16:13:16
>>270
氏ね
275:デフォルトの名無しさん
04/10/18 19:14:17
lzw圧縮ってもう使ってもいいんだよね？
あとでまた特許云々…とかなったりしないよね？
276:デフォルトの名無しさん
04/10/18 19:58:14
> lzw圧縮ってもう使ってもいいんだよね？
Unisysが持ってた特許は失効した。
> あとでまた特許云々…とかなったりしないよね？
可能性はある。
実際に Unisys が関連特許で gif からライセンス料を徴収を続けるかも、って記事もあったし。
277:275
04/10/18 20:46:19
>実際に Unisys が関連特許で gif からライセンス料を徴収を続けるかも、って記事もあったし。
マジですか('A`)
携帯アプリのデータ圧縮に使おうと思ってたんだけど、やめといたほうがいいのかな…。
278:デフォルトの名無しさん
04/10/18 22:10:25
>>277
>>276 は脅しただけだと思うが。
まぁ、油断はしない方がいいやね。
lzwってsuffix treeが必要になるから携帯でやるとメモリきつくない？
279:デフォルトの名無しさん
04/10/18 22:34:04
各ノードの前後のインデックスを保持するだけだからそんなにメモリ使わないと思う。
280:デフォルトの名無しさん
04/10/18 23:02:21
前後のインデックスってわかんないや。
親ノードのインデックスだったらわかるけど。
最近勉強してなかったからなぁ。
281:デフォルトの名無しさん
04/10/18 23:08:38
ああ、親子のインデックスって言った方がよかったか。
lzwなら、親ノードのインデックスと１字のデータ(ある意味、子ノードのインデックス)ってことだよ。
282:デフォルトの名無しさん
04/10/18 23:11:55
>>277
>>276 が言ってるのと同じかはしらんけど、こんなん見つけた。
URLﾘﾝｸ(pcweb.mycom.co.jp)
> 現在、米UnisysはLZWの技術に関連する2件の特許を出願中であり、
> 近い将来において特許成立が見込まれると発表している。
> 画像フォーマットとの関係は不明だが、その内容次第では
> 今回解決に至ったGIF問題の再発も懸念される。
283:275
04/10/18 23:29:25
まあ特許切れてる間に発表すれば後で公開停止求められることはないと思うけど、
作ってる間に関連特許取られたら怖いなー。後々使いまわす予定のコードだし。
短いコードで圧縮率高いから使いたかったんだけど…lzw以外でそういう圧縮方法ってないよね？
284:デフォルトの名無しさん
04/10/18 23:37:18
lzss もハッシュテーブルと連結リストだけでできるっしょ。
こっちも特許ヤバそうだけど。
285:281
04/10/23 14:44:39
ごめん、今更だが子のインデックスって言い方はまずかった。
要は、辞書X番の情報は「辞書Ｙ番の子である」と「その後ろにつく１文字」ということなんで、
ノードの持つデータと親のインデックスだけでいいんだな。
286:デフォルトの名無しさん
04/11/05 23:13:50
cabinet SDK(cabinet.dll)のAPIが日本語で説明されてるサイトってありませんか？
287:デフォルトの名無しさん
04/11/06 00:28:35
大阪（西梅田）、新宿（JR駅前）のそれぞれ一等地に
拠点を構え、業績急上昇中！未経験者大募集中！の
ソフトウェア開発会社
グリーンシステムを応援するＨＰです。
URLﾘﾝｸ(www.geocities.jp)
応援するスレはこちら！
ｽﾚﾘﾝｸ(job板)
最高の会社にするため、みんな頑張ってます！
288:デフォルトの名無しさん
04/11/07 11:17:24
高速ブラウザ「Opera」、SlipStreamの圧縮技術でさらに加速
URLﾘﾝｸ(pcweb.mycom.co.jp)
の記事で、
「SlipStreamが開発したWebやEメールのアクセラレーション技術である。同社独自のデータ圧縮アルゴリズム」
とあるけど、
またまた、何かのパクリなのか？
こういう紛いもんみたいな新技術の話って、よくもまあホイホイ出てくるよなぁ。
289:デフォルトの名無しさん
04/12/29 23:48:16
教えてください。私目のバカ脳では、限界です。
JavaのZGIPOutputStreamクラスでgzip形式で圧縮が可能なのですが、
同じファイルでも、プログラムで圧縮プログラムを実行するたびに、
出力された圧縮ファイルが異なります。サイズも中身もです。
解凍すれば、同じデータであるので、別に良いのですが、
会社で資産管理作業を行う際に面倒です。
そもそも、gzipや他の名のある圧縮アルゴリズムの
仕様なのでしょうか？
290:デフォルトの名無しさん
04/12/30 00:37:54
>>289
適当な圧縮ソフトで実験してみれば？
291:デフォルトの名無しさん
04/12/30 15:15:30
拡張子ｆｃｄってどうやって復元するの?
サイズ400メガ
292:デフォルトの名無しさん
04/12/30 15:55:44
>>291
とりあえず吊っとく？
293:デフォルトの名無しさん
04/12/31 06:35:30
ＦＣＤ・・わからん
吊っとく・・わからん
294:デフォルトの名無しさん
04/12/31 15:10:11
割れだろ？放置推奨
295:デフォルトの名無しさん
05/01/02 11:32:51
圧縮ソフトを作りたくて圧縮技術に関する本をamazonで検索しています。
URLﾘﾝｸ(www.amazon.co.jp)
圧縮アルゴリズム―符号化の原理とC言語による実装 C magazine
↑は購入を決めたのですが、他にお勧めの本はありますか？
できればプログラムのソースの解説については少なくて
アルゴリズムの解説に重みを置いている本を読みたいのです。
上記の本は知人から見せてもらって
自分のそばに置こうと考えたので購入することにしました。
296:デフォルトの名無しさん
05/01/02 11:37:21
URLﾘﾝｸ(www.amazon.co.jp)
図解入門 よくわかる最新データ圧縮技術の基本と仕組み
―情報圧縮技術とアルゴリズムの基礎講座
How‐nual Visual Guide Book
こちらも候補に入れております。
297:デフォルトの名無しさん
05/01/03 09:06:09
保守
298:デフォルトの名無しさん
05/01/04 19:20:04
あとはこれ。
「LHAとZIP―圧縮アルゴリズム×プログラミング入門」
URLﾘﾝｸ(www.amazon.co.jp)
299:デフォルトの名無しさん
05/01/04 22:00:58
>>298
その本は 1/3 が LHA の作者の一人の奥村氏による昔話とアルゴリズム解説、
2/3 が DeepFreezer作者による LHA の独自実装のソースと解説。
ついでに ZIP も実装できちゃいましたって感じの本だよ。
アルゴリズムの解説が読みたいっていう >>295 にオススメできるような本じゃない。
仕様を網羅してるか、という点で見ても LHA も ZIP も中途半端だし。
300:デフォルトの名無しさん
05/01/05 02:31:34
そうだねぇ。私も買ったけど、仕様がどうこうって本ではないですね。
圧縮アルゴリズムのさわりと、プログラミングの入門って感じの本でした。
ていうか、サブタイトルがそのまんまなんで、タイトル通りの本ってことだけど。
301:295
05/01/05 08:59:20
図解入門 よくわかる最新データ圧縮技術の基本と仕組み
―情報圧縮技術とアルゴリズムの基礎講座
How‐nual Visual Guide Book
圧縮アルゴリズム―符号化の原理とC言語による実装 C magazine
上二つの本を購入することにしました。
みなさんありがとうございました。
302:デフォルトの名無しさん
05/01/05 18:26:26
>>296 >>301
よくわかる～ はさわりしか書いてないので、物足りなくなったら原論文を当たるとよいでしょう
ただ、オリジナルの論文では正確なところがわからないこともあるので、
解説的な論文を読むのもいいでしょう
303:デフォルトの名無しさん
05/01/05 20:37:45
突っ込みたい。「さわり」を突っ込みたいー。
304:デフォルトの名無しさん
05/01/06 15:55:51
昔買った、文書データ圧縮アルゴリズム入門 というのは様々な圧縮方法が書いてあって
よかったけど、今は絶版らしい。
305:デフォルトの名無しさん
05/01/06 23:08:35
>>304
URLﾘﾝｸ(www.cqpub.co.jp)
漏れが圧縮にハマるきっかけになった名著。絶版でなければ、>>301で不足してる分はこれが補ってくれると思うんだが…
復刊.comでリクエストするか、それとも改訂版をリクエストするか？
306:デフォルトの名無しさん
05/01/06 23:17:08
改訂版のほうが良いんじゃないかな
307:デフォルトの名無しさん
05/01/07 02:55:38
掲示板を作りました
URLﾘﾝｸ(scs.dip.jp)
情報通信に関する学術的および技術的な議論の場を
提供することを目的としています。
勉強するためのテキストの紹介、技術的な質問、
産業界の動向、議論などご自由にお使いください。
308:デフォルトの名無しさん
05/01/07 16:43:33
ランタイムライブラリ含まない大きさが2kバイトぐらいの
小さくて展開の速い圧縮ありませんか？
圧縮する対象は主にexeとかの実行イメージです。
今はひそかにスライド辞書(LZ77)を使ってますが
アルゴリズム同じだと特許に触れるんでしょうか。
せっかく苦労して作ったのにやだなあ。
309:デフォルトの名無しさん
05/01/07 16:54:06
>>308
子供は早く寝ろ
310:デフォルトの名無しさん
05/01/09 03:12:24
LZ77なら全く問題なし
311:デフォルトの名無しさん
05/01/09 13:15:26
>>310
富士通はLZ77+ハッシュ使うとダメって言ってるし、
LHA作者の奥村教授はLZ77+ツリー使うとダメって言ってるが。
312:デフォルトの名無しさん
05/01/09 17:11:36
LZ77+何か：×の可能性が高い
LZ77のみ ：
って事
313:デフォルトの名無しさん
05/01/09 17:13:29
文字化けしてたらｽﾏｿ
は○
314:デフォルトの名無しさん
05/01/10 18:08:56
LZ77 + 普通のハフマンは×ですか？(LHAではないです)
ハフマンって圧縮以上に見た目のランダム性上がるから
使いでがあるんですが。
というかLZ77のみは可ですか。
とりあえずLZ77だけでいきます。
こういう思いつきそうな事を特許で縛るのって卑怯ですよね。
そういえば、バイオハザードの視点固定は特許になったのかな。
あれも酷いですよね。
315:デフォルトの名無しさん
05/01/10 19:51:08
>>314
> というかLZ77のみは可ですか。
LZ77のみっつーか LZ77 + 単純検索だけでhashもツリーも使ってないなら、たぶん可。
LZ77 + 自分でゼロから考えた高速化をしてる場合は特許の調査をしてみんとわからん。
hashとかツリーとか言われて理解できないようなら、たぶん不可。
一般にwebや本に書かれてるLZ77のプログラムは、全てhashかツリーを使ってるから。
316:デフォルトの名無しさん
05/01/11 04:04:32
>>314
誰でも思いつきそうで、特定の誰かが思いつくものは多々ありますが、結局早い者勝ちです。
それに、もう20年近く前に「開発され尽くした」といわれた手法に、
いまさらどうこう言ってもしょうがないかと。
LZW同様、ぞくぞく特許が切れつつあるので、ちゃんと調べるなら、使うことができますよ。
あと、LZ77の大多数の特許は、圧縮時の手法（ハッシュも木も）なので、
LZ77オリジナルと同じ圧縮後データをもち、展開するだけなら、特許は全く関係ないわけです。
317:デフォルトの名無しさん
05/01/11 04:38:54
> ちゃんと調べるなら、使うことができますよ。
ちゃんと調べるならって、>>314 には使えないって遠まわしに言ってるだけのような。
318:デフォルトの名無しさん
05/01/11 10:21:21
>>317
特許専門の弁護士やら技術者やらを用意しても回避困難
一般人ならなおさら
319:デフォルトの名無しさん
05/01/11 14:52:34
・ソース非公開
・リバースエンジニアリング、解析を禁止
しておけば大丈夫。
特許の有効期限分経過してからソースは公開すればいい。
後で特許とられても、先に実装が存在する場合は特許が成立しないので、
この場合も安全となる。
320:デフォルトの名無しさん
05/01/11 16:40:38
> 特許の有効期限分経過してからソースは公開すればいい。
特許が無効になるまでの期間分の特許料払わなきゃいかんと思うが。
> 後で特許とられても、先に実装が存在する場合は特許が成立しないので、
実装が存在しただけで公知と言えるのかは疑問。
321:デフォルトの名無しさん
05/01/11 17:13:07
>>320
>> 特許の有効期限分経過してからソースは公開すればいい。
>特許が無効になるまでの期間分の特許料払わなきゃいかんと思うが。
特許の存在を知らなかったといえば回避できる。
>実装が存在しただけで公知と言えるのかは疑問。
公知でなくとも存在を証明できれば問題ない。
そのためにはネット上で配布などをあらかじめ利用する。
322:デフォルトの名無しさん
05/01/11 17:38:37
> 特許の存在を知らなかったといえば回避できる。
著作権じゃないんだから……
それが通るなら特許なんて法制度はあっというまに崩壊するな。
> 公知でなくとも存在を証明できれば問題ない。
改竄が比較的容易なネットでの配布が法的にどーゆー位置づけになるか、って問題と
実装だけで存在を証明できるかって問題が……
323:デフォルトの名無しさん
05/01/11 18:21:01
>>319 >>321
特許は、
知らなかったでは回避できないし、
その期間分を遡って賠償も請求されるし、
(著作権と異なり)偶然一致した場合でも侵害したことになる。
ネット上での公開は、現在は灰色。
ソースコードを登録機関に提出しておくべし。
・・・はず、有識者もとむ(特許出しているくせに、未熟ですまぬ)・・・
324:デフォルトの名無しさん
05/01/12 01:43:30
じゃあ組み込むのは展開部分のみなんで関係ないですね
325:デフォルトの名無しさん
05/01/12 07:50:30
>>323
回避できる。例えばGIF関連では、期限が切れた今現在、過去に上って請求されることは無い。
ポイントは、経過したことと、相手に請求されていないこと。
期限が切れてしまえば、知らなかったで済む。大抵は時効だ。
ソースコードの提出は、逆に自分を危険に晒す。
自分が権利を主張しないなら、バイナリが存在すれば、それで十分。
バイナリ自体が、アセンブリ言語のソースになる。
326:デフォルトの名無しさん
05/01/12 07:52:45
>>322
お前は馬鹿か。特許制度が、どういう理念で作られたかわかっていないな。
著作権などの法制度とは全く異なる。もともと技術が隠されるのを防ぐためだ。
327:デフォルトの名無しさん
05/01/12 11:13:00
>>325
無根拠で知らなかったで済むとか言われても……
それに Unisys が現実に特許料を請求するかは別にして、
今現在でも Unisys は2004年6月（だっけ？）までの特許料を請求する権利を持ち続けてるだろ。
あとバイナリ自体がアセンブリ言語のソースって考え方なら
バイナリもソースコードと同程度に危険なはずだが。
328:デフォルトの名無しさん
05/01/12 11:27:56
>>324
奥村教授を信じるなら、LZ77の展開部分だけなら大丈夫だと思われ？
ハフマンの展開部分も大丈夫か、ハフマンの展開部分とLZ77の展開部分くっつけて大丈夫かは知らんが。
329:デフォルトの名無しさん
05/01/12 21:25:04
>>326
特許の目的は人類の知的財産の共有が目的だよ
みんなで一歩一歩進みましょう。
って感じの。
特許対象となるようなすばらしいアイデアはみんなのものです。
でも、発明人にもなにかおいしいことがないといけないので
20年間は発明を特許で保護されるわけです。
あんまり恥ずかしいこといわないでね。
330:デフォルトの名無しさん
05/01/12 21:37:39
no patent!!
no patent!!
331:デフォルトの名無しさん
05/01/14 01:57:08
ん？LZWはもう使って大丈夫なんですか？
332:デフォルトの名無しさん
05/01/14 02:02:40
解禁です。
あの子のへあーも
333:デフォルトの名無しさん
05/01/14 23:08:40
>>331
>>275-276,>>281
334:デフォルトの名無しさん
05/01/14 23:09:44
× >>281
○ >>282
335:デフォルトの名無しさん
05/01/16 06:08:40
rarて何使ってるの？
最近の圧縮アルゴリズムはさっぱりわからん
336:デフォルトの名無しさん
05/01/25 16:00:11
自己解凍書庫ってのは『解凍Exe』＋『圧縮データ』って形になってると思うんですが
『解凍Exe』はどのようにして『圧縮データ』の位置を取得してるんでしょう？
337:デフォルトの名無しさん
05/01/25 16:46:35
自分のサイズがわかってればいいんじゃない？
338:デフォルトの名無しさん
05/01/25 19:10:43
ここに詳しい人がいる
ｽﾚﾘﾝｸ(tech板)
339:デフォルトの名無しさん
05/01/25 20:59:47
>>335
とりあえず
r a r は 最 近 で き た 圧 縮 形 式 で は な い ｗ
340:デフォルトの名無しさん
05/01/25 21:03:48
>自分のサイズがわかってればいいんじゃない？
ふむ．．．
『解凍Exe』内部にハードコードで書込んでおく。ってのも有りか．．．しかしなんかイヤな感じが
統合アーカイバとかの自己解凍書庫てどーゆー作りになってんだろ？
341:デフォルトの名無しさん
05/01/25 21:10:29
>>340
良くわからんけどID3みたいにファイル末尾に前のブロックの末尾位置だの
最終ブロックないのデータの先頭位置だののテーブル持ってるんじゃない？
342:デフォルトの名無しさん
05/01/25 21:49:39
>>341
おいおい憶測で物言うのもいい加減にしろよ。
ストリームでもなければ末尾にヘッダを置く意味がない。
自己解凍書庫の作成はあらかじめ用意した解凍ロジック付きexeの
PEヘッダに適当なデータセクションを追加修正すれば終わり。
解凍ロジックはデータセクションで定めた決めうちベースアドレスから
データを読み取るだけでOK。
PEの仕組みとローダの知識が多少あればできる。
343:sage
05/01/28 01:13:21
ソースコードが移植可能なライセンス携帯で、3kbぐらいのオブジェクトサイズの
圧縮ライブラリ知りませんか？ちょっとSymbianに乗せるアプリに実装したい
と考えています。
344:デフォルトの名無しさん
05/01/28 01:17:54
>>343
Huffman自作しなされ。以上
345:デフォルトの名無しさん
05/01/28 03:00:24
344の意訳
知りません。でも知らないって言うの恥ずかしいから煽ります。
346:デフォルトの名無しさん
05/01/28 10:44:41
MPGかWAVからAFSファイルを作りたいんだけど、ツールないですか？
347:デフォルトの名無しさん
05/01/28 11:11:10
>>346
板違い
ソフトウェア
URLﾘﾝｸ(pc5.2ch.net)
348:デフォルトの名無しさん
05/01/29 21:18:14
Lhaplusの作者のWebページどこへいっちゃたんだろ？
Lhaplusってあれだね、ファイル数が多いといつまで待っても
圧縮が始まらんねｗ
349:デフォルトの名無しさん
05/01/29 23:00:14
> Lhaplusの作者のWebページどこへいっちゃたんだろ？
URLﾘﾝｸ(park14.wakwak.com)
350:348
05/01/30 17:00:43
>>349
サンクス。
lhaplusをver1.50β11にしたらサクッとスタートしてくれました。
351:デフォルトの名無しさん
05/02/03 18:05:41
LZ77の圧縮にハッシュも木も使ったらまずいってどうすりゃいいんだ？
LZ77を少し改造してLZ77じゃありませんよ～とかいったらOKなんだろうか。
352:デフォルトの名無しさん
05/02/04 03:39:17
>>351
2-3文字をインデクスするリストを使えばいい
木とほぼ同程度の速度で動く
・・・ぶっちゃけ、2-3文字のハッシュと同じなんだがなｗ
353:デフォルトの名無しさん
05/02/11 10:42:32
なんか圧縮のことよくわからなくてはじめてここに来たんだけど、
とりあえず３バイト連続する同じデータがあれば２バイトに圧縮したらＯＫなんですね。
あと連続するパターン見つけるんだろうけど、俺がプログラム書いたらそんなの
時間かかってぐっちゃぐちゃでめっちゃめちゃでアウトだ
354:デフォルトの名無しさん
05/02/11 20:20:42
>>353
専門書も扱っている本屋へ行って、圧縮とかアルゴリズムとか、の本を買うと良い。
パターン検索は >>351-352 のキーワードを参考に。
355:デフォルトの名無しさん
05/02/12 17:46:17
>>352
それだとハッシュ使う特許に引っかかる可能性が残ると思われ。
356:デフォルトの名無しさん
05/02/12 18:02:28
圧縮率上げる工夫よりも特許を回避する方に労力を費やしてる矛盾
357:デフォルトの名無しさん
05/02/12 18:12:25
>>353
unsigned char c = in[i];
int count = 0;
while (c == in[++i]) count++;
out[j++] = c;
out[j++] = count;
こんな感じのルーチンで出来る。
358:デフォルトの名無しさん
05/02/13 08:34:10
>>355
ハッシュとは別の論文で発表されていたから、大丈夫だとは思うがどうだろう。
Bell and Kurp, 1991. だったかな？
359:デフォルトの名無しさん
05/02/13 11:50:47
>>358
ハッシュの特許に触れるか、だけが問題で
ハッシュと同じ論文で発表されたかは問題にはならないと思われ。
ちなみに、その論文の方法が特許化されてないのは確認済み？
360:デフォルトの名無しさん
05/02/15 22:29:54
とりあえず何も考えずに zlib 使っとくのが一番現実的なのかね。
仮に問題があったとしても、みんな闘ってくれるはず。きっと。多分。
361:デフォルトの名無しさん
05/02/16 02:46:58
>>360
zlibに採用されているハッシュ法って、まんま>>352 >>358 だよね
3文字でインデックスしたチェインリストを順に読むわけだから…
362:デフォルトの名無しさん
05/02/18 12:41:14
installshield の cab 形式への圧縮が出来るツールってないですか？
既存のcabを展開して、パッチを当てて、また再圧縮したいんですけど・・
363:デフォルトの名無しさん
05/02/18 13:08:11
>>340
UpdateResource()を使うのもありかもね。
364:デフォルトの名無しさん
05/02/18 16:38:46
>>361
zlibとかのは先頭3文字を加工して使ってるからなぁ。
ハッシュでないというのは通らんと思うぞ。
加工せず使うなら、なんとかなるかもしれんが
3文字だとテーブルだけで16M*sizeof(テーブルの要素)バイトかかる。
365:デフォルトの名無しさん
05/02/18 18:26:13
デコードするだけなら引っかからないんでしょ？
普通のアプリなら解凍できれば十分だし
366:みゆき
05/02/23 21:19:47
100個くらいあるファイルを、それぞれ違うパスワード(予めエクセル等でファイル名とパスワードの対応は作成しておきます)でzip圧縮したいのですが、やり方がわかりません。
エクセルのVBAで、UNZIP32.DLLを使えば良い、というのは想像出来るのですが、記述方法がわかりません。
お知恵をお貸しください。よろしくお願いいたします。
367:デフォルトの名無しさん
05/02/23 21:45:51
普通にコマンドライン呼び出せばいいんちゃう・・・？
368:366
05/02/23 22:55:32
解決しました！！
369:デフォルトの名無しさん
05/02/24 09:52:03
どうやって解決したのか書けよ
370:みゆき
05/02/24 11:56:21
誰か366を語って書き込みしたようです。まだ解決してません。
よろしくお願いいたします。
371:デフォルトの名無しさん
05/02/24 11:59:46
zipファイルにパスワード付けるのは安全ですか？
372:デフォルトの名無しさん
05/02/24 12:33:40
>>371
はい
373:デフォルトの名無しさん
05/02/24 12:35:58
>>371
危険です
なぜなら371はパスワード掛けてみたはいいもののそのパスワードを忘れてしまうでしょう
374:デフォルトの名無しさん
05/02/24 12:54:42
>>371
zipパスワード検出プログラムが出回ってるから気休めにしかならない
本気で保護を考えてるなら止めといた方がいい
375:デフォルトの名無しさん
05/02/24 12:56:00
そういうときのために、ファイル名をパスワードにしておくとよいよね。
376:デフォルトの名無しさん
05/02/24 13:31:00
zipそのものを暗号化してしまえ
377:デフォルトの名無しさん
05/03/04 20:56:00
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 ・・・
---------------------
URLﾘﾝｸ(www.futomi.com)
URLﾘﾝｸ(www.futomi.com)
をみるとzipの先頭データは8かFかってことっぽいので
このデータはzip圧縮されたデータとしてはおかしいと
思っていいのでしょうか？
378:デフォルトの名無しさん
05/03/05 01:04:40
>377
>をみるとzipの先頭データは8かFかってことっぽいので
どうしてそういう結論になる。
先頭バイトが 0x78 なんだから、CM=8, CINFO=7 でウィンドウサイズ 32k の deflate じゃないの？
あと、zlib も zip も deflate を使っているかもしれないが、zip圧縮という言い方は語弊が
あるのではないだろうか。
379:デフォルトの名無しさん
05/03/05 02:35:46
>>378
二桁目がCMなんですね
ドキュメントをよく理解できてませんでした。
>zip圧縮という言い方は語弊が
このへんはよくわかってないです。紛らわしくて申し訳ないです
380:デフォルトの名無しさん
05/03/05 14:07:03
>379
バイトの並びとビットの並びに注意しよう。
リンク先の zlib の資料でも「2.1. 全般的な規約」に書いてあるよね？
>>zip圧縮という言い方は語弊が
>このへんはよくわかってないです。紛らわしくて申し訳ないです
俺もよく分からんが、
・zlib はライブラリおよびフォーマットの名前
・zip はフォーマットの名前
・deflate は圧縮アルゴリズムおよびそのフォーマットの名前
ってことでいいの？教えてエロい人！
381:デフォルトの名無しさん
05/03/05 21:26:07
deflate 圧縮アルゴリズム
zlib 圧縮ファイルフォーマット
zip 圧縮形式の名称及び拡張子
こんな感じか？
382:デフォルトの名無しさん
05/03/05 22:59:22
zlibは圧縮ライブラリの名前でいいと思うけど
383:デフォルトの名無しさん
05/03/08 08:24:49
deflate アルゴリズム
zlib バイトストリームを圧縮するライブラリ。ファイルの概念は無い。
zip 複数のファイルを圧縮したアーカイブファイルのフォーマット。
じゃないの？
384:デフォルトの名無しさん
05/03/08 11:58:14
>>383
それが正解
385:デフォルトの名無しさん
05/03/09 12:30:08
>>383
意味なんて人それぞれ。
zipを圧縮フォーマット（たぶんdeflate）の意味で使う奴もいる。
俺は deflate はフォーマットだと思うけど、アルゴリズムだと言う奴もいるしね。
deflate がアルゴリズムなら、zlib の deflate と 7zip の deflate は
同じアルゴリズムを使用してる事になるけど、俺は別のアルゴリズムだと思ってるから。
386:デフォルトの名無しさん
05/03/09 13:18:54
↑こういう意識のやつはこの業界に必要ない
387:デフォルトの名無しさん
05/03/09 13:40:23
↑オレ用語が否定されてムキになってる人？
388:デフォルトの名無しさん
05/03/09 21:12:40
deflateはRFCで記述された通りでいいんじゃないか?
389:デフォルトの名無しさん
05/03/10 00:35:45
どっちでもいい。
390:デフォルトの名無しさん
05/05/17 22:42:40
今、圧縮解凍ツール作ってるんですけど、
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
391:デフォルトの名無しさん
05/05/18 00:17:41
a
392:デフォルトの名無しさん
05/05/18 00:45:04
>>391
追加圧縮はできるんですけど、書庫内のディレクトリ指定がうまくいかなくて困っています。（；_；）
393:デフォルトの名無しさん
05/05/18 15:48:52
Unixで暗号化ZIPファイルをプロンプトを出さずにCプログラムから作成する方法を教えてください
394:デフォルトの名無しさん
05/05/18 23:32:38
キーをテキストに書き出す
テキストを読む
以下略
395:デフォルトの名無しさん
05/05/22 15:43:51
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 となった圧縮形式があったんだが、これなんだっけ？
ヘッダとかついてないのかね。
396:デフォルトの名無しさん
05/05/22 15:57:49
あげ
397:デフォルトの名無しさん
05/05/25 11:34:46
UNZIP32.DLLやUnGCA32.dllでパスワードがかけられてるファイルかどうか見る方法をおしえて
398:デフォルトの名無しさん
05/05/25 21:53:48
書庫のヘッダに書いてあるよ
399:デフォルトの名無しさん
05/05/26 14:24:32
パスワード付きZIPをパスワードWindowを開かずに作成する方法を教えてください
400:デフォルトの名無しさん
05/05/26 19:18:10
コマンドラインで入れる
401:デフォルトの名無しさん
05/05/27 02:50:42
もう少し詳しく教えてください
402:デフォルトの名無しさん
05/05/27 07:48:48
ソフトウェア板かwindows板の話題だと思うんだそれは。
実装でもアルゴリズム概念を聞いている訳でもなし。
403:デフォルトの名無しさん
05/05/28 02:00:36
>>402
ま、巷じゃ「圧縮がわかる本」とかいって圧縮ツールの使い方だけ教えてるのが何百冊も出てるしな…
404:デフォルトの名無しさん
05/05/28 02:22:08
漏れもいっちょ書いてみるか！
405:デフォルトの名無しさん
05/05/29 11:44:42
>>399 無理
406:デフォルトの名無しさん
05/06/25 07:17:01
統合アーカイバのDLLを使ってプログラミングをしているのですが、静的インポートの場合、付属のインポートライブラリを使用しますよね？
これってVC++(MS-LINK)用COFFのようですが、BCC++(ILINK32)でうまく使えないみたいなんですが・・・？(UNZIP32.DLL)
BC++付属のCOFF2OMFで変換するも、デフォルトでは利用できず、-lib:stスイッチで変換しました。
しかし名前インポートができず、オーディナルになってしまいます。
BCC++で名前インポートするにはどうしたらよいでしょうか？
407:406
05/06/25 08:55:05
って、しまった！全然間違えた！
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++でも名前インポートにはならないですよね・・・？
名前インポートにするにはどうしたら・・・？
408:デフォルトの名無しさん
05/06/25 09:32:50
>407
各処理系のスレで聞いた方がいいと思う。
409:デフォルトの名無しさん
05/06/25 09:34:51
implib
410:デフォルトの名無しさん
05/06/25 09:58:18
名前でのインポートにこだわる訳は？
411:407
05/06/25 22:28:30
>>409
IMPLIBなら確かに付属のインポートライブラリはいらないですが・・・MS-LINKはOBJ型ライブラリが使えないようなんですが・・・？
>>410
オーディナルのインポートって信用できないんですよね・・・
DLLのバージョンが上がると変わらない保証ってないじゃないですか・・・？
412:デフォルトの名無しさん
05/06/25 22:50:29
>>411
BCCで使うのになんでMS-LINKが出てくるんだ? わけ分からん
MS-LINKなら付属のLIB使えば済む話だろ
413:411
05/06/25 23:01:26
>>412
ですから間違えました。BCCじゃなくてMASMです。
414:デフォルトの名無しさん
05/06/25 23:07:26
ヒント: /coffオプション
415:デフォルトの名無しさん
05/06/26 01:30:55
完全に特許に引っかからない技術を教えてクレイ
416:デフォルトの名無しさん
05/06/26 03:21:54
>>415
特許の期限が切れたもの
417:デフォルトの名無しさん
05/06/26 07:12:59
>>415
bzip2,gzip
418:デフォルトの名無しさん
05/06/26 07:29:29
完全と言い切れるものは多分ないんじゃないかな。
知られてないだけで、所謂サブマリン特許の類のパテントが存在するかも知れないし。
bzip2のBWTも発案者が特許を取らないといっているだけだし。
圧縮ソフト作るのって床から刃の出ている廊下を歩くような感じだよ。
時々踏むと刃のでる罠が仕掛けてあったりして。
最初にアルゴリズムに特許を与えたバカは誰なんだろう。
419:デフォルトの名無しさん
05/06/26 10:33:39
>418
アルゴリズム特許は暗号が初めてじゃないっけ
それならこれもそれならこれもとずるずる範囲が広がっていった。
暗号の場合は納得できるんだけどねー
420:デフォルトの名無しさん
05/06/26 15:19:36
フラクタル圧縮もダメなんでしたっけ
421:デフォルトの名無しさん
05/06/26 17:41:04
>418 >419
線形計画法のカーマーカー法じゃないの？
>カーマーカー特許とソフトウェア―数学は特許になるか 中公新書
>URLﾘﾝｸ(www.amazon.co.jp)
元々の圧縮アルゴリズムはともかく、○○＋ハッシュとかいうのになってくるとどんどん納得できなく
なっていくんだが。
422:419
05/06/26 20:43:13
>421
すまんこった、カーマーカー法が最初の特許アルゴリズムだった。
ほら吹いてしまいました。ごめんさない。
423:デフォルトの名無しさん
05/07/01 09:17:37
Info-ZIP社のZIP32.DLLって商用で使用するにはライセンスがいるのでしょうか？
UNZIP32はいるみたいなのですが。HP読んでもわからない･･･
424:デフォルトの名無しさん
05/07/02 03:14:07
zip32.dllは知らんが、zlibならいらないはず。
425:413
05/07/02 07:57:25
>>414
どの/coffですか?
mlなら/coffつけてますが?>>407
426:デフォルトの名無しさん
05/10/12 02:59:27
hosyu
427:デフォルトの名無しさん
05/10/25 10:46:17
質問です。
DEFLATE圧縮では元データはバイトごとに圧縮されるのですか？
それとも6ビットや5ビットなどビット単位ですか？
RFCと一緒にzlibやgzipのソースを読んでいるのですが
自分の読解力ではわかりません。
428:デフォルトの名無しさん
05/10/25 11:33:32
バイト単位
429:427
05/10/25 11:37:52
>>428
バイト単位ですか。ありがとうございます。
その線で読んでみます。
430:デフォルトの名無しさん
05/10/25 11:44:07
ソース読んで理解できないなら>>298
431:427
05/10/25 12:56:37
>>430
やっぱりその本を買った方がよさそうですね。
今から買ってきます。
432:デフォルトの名無しさん
05/10/30 11:38:36
書庫が１バイト足りずに破損している場合、末尾に00を付加するという話を聞いたんですがどうやって付加するんでしょうか？
調べようと思ったんですが検索ワードが思いつかない…
433:デフォルトの名無しさん
05/10/30 14:54:09
>432
君が何を聞きたいかが理解できない。
とりあえず付加するのは誰？
特定のソフトの話か、特定のファイル形式の話？
434:デフォルトの名無しさん
05/10/30 18:22:37
>>433
漏れの予想では、ファイルの末尾に00を付加させるのに、
どんな関数orAPIをコールすれば良いか判らない
そういうレベルの質問だと思う
435:デフォルトの名無しさん
05/11/01 00:17:17
板違いの予感。まさかnarがどうとかって話じゃないだろうな。
1 バイトのファイルを作っておいて copy /b とか cat とか、
そんなスキルもないならバイナリエディタ。
ってところだったりして。
436:デフォルトの名無しさん
05/11/01 02:01:51
narってなにさ？
437:デフォルトの名無しさん
05/11/04 11:05:22
もしかして null ?
438:デフォルトの名無しさん
05/11/04 11:16:46
ナルほど
439:デフォルトの名無しさん
05/11/04 20:13:26
>>438
誰がうま(ry
>>432, >>435
出てきて釈明しる！
440:435
05/11/04 22:15:29
済まん、あっさりスルーされると思ってた。
「伺か」が使うアーカイブ(実態はzip)の拡張子。
公開終了したアーカイブをWebArchiveから拾ってくるって話。
まあ、オタネタだ。
441:435
05/11/04 22:26:30
補足。
WevArchiveにはファイル末尾の0を切り捨ててしまうというバグ(?)がある。
そのためせっかく昔のアーカイブを見つけてもzipが解凍できないことがある。
末尾に0を付加してやると正常に解凍できるようになる。
というのがこちらで想定した問題のバックグラウンド。
442:432
05/11/04 22:31:07
自己解決したから書き込まなかったんだけど、WebArchiveのzipファイルで～て事が聞きたかった。
narは良く分からなかったけど、435が書いてくれたからまぁ良いかと思ってた
オレのせいで微妙な話が続いて悪かったです
443:デフォルトの名無しさん
05/11/12 12:52:07
zlibの使い方を詳しく丁寧に説明してる日本語サイトを教えてください。
あと、gzip（と可能ならzipも）の中のファイル名を解凍せずに知りたいんですが、できませんか？
444:デフォルトの名無しさん
05/11/12 18:30:27
zlib.hの英語を読むのが一番確実だと思うけど。
別に読みにくくは無いし、そんなに長くもないし。
gzio.cも。
445:デフォルトの名無しさん
05/11/17 22:59:07
>>443
ヘッダにテキストで書いてあるけど。
446:デフォルトの名無しさん
05/11/17 23:36:52
>>445
日本語って言ってるだろうが、馬鹿
447:デフォルトの名無しさん
05/11/18 00:43:37
日本語なかったっけ？ どっかでzlib.hのコメント日本語訳みたことがあるんだけどどこだったか…
448:デフォルトの名無しさん
05/11/18 15:11:28
>>446
日本語読めないのに日本語要求してたんですね。
# 単に駄々をこねてみたかっただけかな? :-P
449:443
05/11/18 23:21:09
ありがとうございました。
日本語訳はこれですね。
URLﾘﾝｸ(www.sra.co.jp)
450:デフォルトの名無しさん
05/12/25 22:34:49
zlib の deflate を利用して
自前でzipファイルを作るプログラムを作ろうと思います。
とりあえず、ここの仕様書を見たのですが、
URLﾘﾝｸ(www.pkware.com)
extra fieldの意味がよくわからないです。
私の場合は、この部分は出力しなくて良いのでしょうか？
451:デフォルトの名無しさん
05/12/26 16:51:16
あげます
452:デフォルトの名無しさん
05/12/26 23:35:03
遠慮なく頂きます
453:デフォルトの名無しさん
06/02/09 06:24:45
前スレ
圧縮アルゴリズム考えたんですが
ｽﾚﾘﾝｸ(tech板)
テンプレは >>1-3 あたりには無い。
454:デフォルトの名無しさん
06/02/10 23:16:40
乗っ取るの？
455:デフォルトの名無しさん
06/02/26 18:38:09
圧縮アルゴリズム2
ｽﾚﾘﾝｸ(tech板)
456:デフォルトの名無しさん
06/02/27 10:56:10
圧縮アルゴリズム考えたんですが
まずデータの中にフラグの立ったビットがいくつか数えます。
そしてデータは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バイト悔いました。
Ｃ(コンビネーション)て恐ろしいな
457:デフォルトの名無しさん
06/02/28 00:49:54
俺を圧縮してみろ！！
458:デフォルトの名無しさん
06/02/28 09:12:37
>>456
Lynch-Davisson 符号とか数え上げ符号を調べてみて
459:デフォルトの名無しさん
06/02/28 10:27:28
圧縮にはならないって事か？調べたけどあまり無くて分からなかった
460:デフォルトの名無しさん
06/02/28 16:19:05
10年くらい前、bzip で使われている
ブロックソートが何故圧縮にいいのか証明されていない、
と聞いた気がするんだけど、今はもう証明されているの？
461:蕪木ら某 ◆Googl8RmwA
06/03/01 03:29:22
( >>460 URLﾘﾝｸ(www.google.com) )
462:デフォルトの名無しさん
06/03/01 03:52:31
>>460
有村 とか Effros の論文読んでみて
463:デフォルトの名無しさん
06/03/01 04:02:46
>>456 >>459
Schalkwijk の数え上げ符号
長さ n のバイナリ文字列中に 1 の個数が w 個あるものを考える
このとき、インデクス i
i = Σj=1,n x[j] n-j C w[j]
を用いて1対1に対応付けすることができる。ただし、w[j] = Σi=j, n x[i]
符号化は、まず、1 の個数 w を ceil(log n) ビットの2進数で出力する
次に、インデクス i を ceil(log k C w) ビットの2進数で出力する
なお、ceil() は切り上げ
この符号化は、1記号あたりエントロピーまで漸近的に圧縮可能
464:デフォルトの名無しさん
06/03/01 14:26:02
>>463ごめん後半からわかんなかった…
ところでJAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト見ながら自分なりの解釈で作ったんだけど
76Kbのビットマップをデフレで圧縮したら44Kbになったのね。
で、7zのZIPで圧縮したら37Kbになったのよ。
これって何がいけないの？Lhacaも7zより圧縮率悪いけど
どういう工夫すれば縮むようになるん？
教えてエロい人！
465:デフォルトの名無しさん
06/03/02 18:09:48
AGE
466:デフォルトの名無しさん
06/03/02 23:20:46
ハフマン圧縮について教えてください。
よくあるのは、出現率の低いものを２個取り出して、その和をつくり、さらに残ったなかから一番出現率が小さいものをとりだし、
これと、先ほどの和の結果との和をとり・・・
という説明です。
でもなんか要するに出現数のおおい順にソートして（出現ゼロ回のものは無視する）
A,D,B,C,・・・みたいに配列に入れます。
そして順に、1,10,110,1110,11110・・・
と符号をふればいいだけのように思えてしまいます。
なぜ小さいものを取り出して和を作り、さらに小さいのと和をつくり・・みたいなことをする必要があるのでしょうか？
467:デフォルトの名無しさん
06/03/02 23:35:09
最初俺もそう思ったけど、ちょっと考えたらそれじゃ意味ないことに気づいたんだよ
なんでかって？忘れたなぁ…
468:デフォルトの名無しさん
06/03/03 00:01:40
>>466
それは unary 符号（単進符号、一進符号）というもの
符号が最適になるには条件というものがあって、
unary の場合、記号の出現確率が 1/2, 1/4, 1/8, ... となる場合にのみ最適な符号を構成できる
一方、Huffmanはどんな出現確率の記号群に対してでも最適な符号を構成できる
469:466
06/03/03 00:41:32
なるほど。よくわからないけど間違っていたことだけはわかりましたｗ
ありがとうございます！！！！！！！！！
470:デフォルトの名無しさん
06/03/04 00:41:35
JAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト
教えてくれ俺もみたい
471:デフォルトの名無しさん
06/03/04 10:02:12
データ圧縮法概説
というところ。その名の通り原理や概念を解説しているだけでJAVAどころか
プログラミングにすらふれていない。
でも説明は分かりやすいからJAVAでも作れた。
472:デフォルトの名無しさん
06/03/04 21:26:39
データ圧縮法概説
ないよ
どうすればいいの？
473:デフォルトの名無しさん
06/03/04 21:37:29
Internet Archive
474:デフォルトの名無しさん
06/03/04 21:39:06
つーか、ちょっとリンクを追いかけていけば生きてるサイトにたどり着いたぞ
475:デフォルトの名無しさん
06/03/04 21:54:37
どうやっておいかけるの？
476:デフォルトの名無しさん
06/03/04 23:53:49
我楽多頓陳館で検索。
管理人は一人で何役もこなすアニメ好きの54歳
世露死苦!!
477:デフォルトの名無しさん
06/03/05 14:04:16
見つかった？
478:デフォルトの名無しさん
06/03/05 19:46:29
今zip圧縮のサンプル作ってる
479:デフォルトの名無しさん
06/03/05 20:51:59
それはzlibとか使って？それとも圧縮部も自作？
自作だったら性能を上げる工夫とか教えてほしいです。
480:デフォルトの名無しさん
06/03/06 00:58:20
圧縮部分も自作です。組み込みに乗せるから
パフォーマンスそこそこでだいたい2kから10ｋいないの
zlibを作成しようとしてます。なので性能よりもマシン語
の吐かせた内容をコンパクトにすることに命をかけています。
私も工夫とかよく解らない部分が多いため、IEEEの論文などをいくつか入手し
勉強をしているところです。アルゴリズム的に速度を上げる方法と
コーディングレベルで最適化する方法2つの視点で最適化について
考えていますがまだ道のりは厳しいです
481:デフォルトの名無しさん
06/03/06 01:23:44
特許まわりはどうなのかしら?
482:デフォルトの名無しさん
06/03/06 13:05:55
現在猿でも分かるC言語講座をみながらJAVAでブロックソートとMTFとレンジコード制作二日目。
Cはよく分からんがブロックソートの符号化とMTFの符号化･復号化が完成
ブロックソートの復号がうまく行かない…
483:デフォルトの名無しさん
06/03/07 01:43:41
Huffman圧縮で質問です。
記号が一回しか登場せず、２分木が１つも作成できないような場合、
その記号にはどんな符号を割り当てるのですか？
484:デフォルトの名無しさん
06/03/07 06:59:12
多分最初に出現する記号の種類の数もカウントしてるんだろ？
俺はその値が1になる場合は2にしてもう一文字あると仮定して
やってる。その文字は何でもいいが大抵は0x0だな
485:デフォルトの名無しさん
06/03/07 08:28:48
>>483
「記号が1種類しかない」フラグを作って、記号を記録しとく。
「記号がいくつ現れたか」も記録しとけば、記号は全部空ビット列に変換で良い。
486:デフォルトの名無しさん
06/03/07 21:31:22
ありがとうございます。
>>484
なるほど。それならアルゴリズムに大幅な変更はいらないですね。
>>485
そうですね。Huffmanにこだわらずにってことですね。
今からどっちにするか迷います。ありがとうございました。
487:デフォルトの名無しさん
06/03/08 00:50:18
動的ハフマンって実装自体は特許事項に
抵触技術内容含まれてないですよね？
488:デフォルトの名無しさん
06/03/08 07:25:58
大丈夫でしょ。やり方にもよるかもしれないけど、まあ普通に作れば無問題
489:デフォルトの名無しさん
06/03/08 22:54:08
動画配信のMPEG４とかH264ってのは適合型ハフマンで送るのですか？
もしそうならパケロスしても大丈夫な理由を教えてください。
490:デフォルトの名無しさん
06/03/14 19:13:07
やっとJAVAでブロックソートとMTFとRLE7とレンジ圧縮(圧縮だけ)
ができた。でもサイトにあるほどの圧縮率が出ないwwwww
なんで…orz
491:デフォルトの名無しさん
06/03/14 19:38:26
>>490
どこのサイトかしらないけど、結果だけ載せている場合は、かなり細かいチューニングや、
アルゴリズム改良が加えられていることが多い。
ソース・実行プログラムもあるなら、圧縮結果をバイナリ比較するとか、
サイトのプログラムによる出力を自作プログラムで展開させてみるとか（あるいはその逆）、
圧縮結果のバイナリそのものの解析をしてみたらどうだろう。
492:デフォルトの名無しさん
06/03/14 21:50:38
猿でも分かるプログラミング講座とかいうとこだったはず
Cのソースがあったから移植してみたブロックソートは間違いないからなぁ…
まあいろいろ結果を調べてみる
493:デフォルトの名無しさん
06/03/15 12:29:54
>>492
Cのソースプログラムが公開されているので、
1ステップずつ動作を追っていけばいいのではないか
途中の変数の状態を確認したり、演算結果に差異がないかを調べたり
494:デフォルトの名無しさん
06/03/15 19:31:53
いい忘れてたけどCのコンパイラとか持ってないんだ。
落とさなきゃだめかな？
495:デフォルトの名無しさん
06/03/15 22:51:59
今や、GCCコンパイラだけでなくMSコンパイラも無料。
「資金がない」で逃げる行為はもはや言い訳にならなくなった。
496:デフォルトの名無しさん
06/03/16 07:09:38
重いの入れたくない。はあり？
497:デフォルトの名無しさん
06/03/16 15:00:59
なし、軽いの入れればいい
498:デフォルトの名無しさん
06/03/16 16:44:24
sumという38000byte位のファイルを圧縮した結果250byte位劣って13Kb程になった。
実はヘッダなどの付加のしかたが微妙に違うのだがそれだけで
こんなに差が出るもんかな？ちなみに
BlockSort->MTF->ZLE+RLE7->RCA
って感じで4段階で圧縮してます。ヘッダ情報はどれもこっちの方が少ないのに…
499:デフォルトの名無しさん
06/03/16 19:09:09
>>498
アルゴリズムや定数も同じで、各段階でのヘッダも小さいのに
出来上がりファイルが大きいのなら何かバグってるんでしょうね。
500:デフォルトの名無しさん
06/03/16 21:24:35
>>499え!?マジで？℃チクショウーーーーーーーーー!!!!!
501:デフォルトの名無しさん
06/03/18 08:49:04
困憊羅が雨後かねぇwwwwwwwww!!!!!!
502:デフォルトの名無しさん
06/03/18 11:09:59
2chの圧縮ダットを解凍するにあたって資料が欲しいのですが、どこか頼みます。
503:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 18:35:48
TextSS の64bit化おながいします
もしくは64bitにネイティブ対応した置換ソフトないですか？
504:デフォルトの名無しさん
06/03/19 19:48:35
新しい圧縮アルゴリズム考えようぜ!!
505:デフォルトの名無しさん
06/03/19 20:22:48
>>504は>>1も読めないのか
506:デフォルトの名無しさん
06/03/19 20:51:34
だってアルゴリズムスレ無いしここの再利用で十分だろ？
2chの無駄も減って一石二鳥だね
507:デフォルトの名無しさん
06/03/19 23:20:14
昨日、カミさんに怒られてrar圧縮されたさ
めっちゃ苦しかった
508:デフォルトの名無しさん
06/03/20 08:55:07
KWSK!!!!
509:デフォルトの名無しさん
06/03/20 22:28:21
へいっ!!!ついにやったぜ
JAVAにブロックソートとMTFとZLE7と適応型RANGEを移植完了!!ながかった～
圧縮率は7z>BZIP2≒俺の>ZIPという感じ
これからは圧縮されたデータをさらに圧縮できるようにする変換でも考えるﾉｼ
510:デフォルトの名無しさん
06/03/28 22:15:14
ZIP圧縮について質問です。
zip32.dllに圧縮したいフォルダパスを-rオプションで渡した場合
zip内に格納されたファイルがドライブTOPからのフルパスで格納されてしまいます。
指定したフォルダ以下のみを格納するにはどうすれば、よいのでしょうか？
511:デフォルトの名無しさん
06/03/29 01:03:46
SetCurrentDirectoryしてから、相対パスで指定すればいいんじゃね？
512:510
06/03/29 02:44:16
511>
無事にできました(^-^;
ありがとう
513:デフォルトの名無しさん
06/04/22 06:43:41
正確には圧縮アーカイブではないですが、ISOイメージファイルのフォーマットが書いてある場所を探しているのですが、いいのはないですか？ とりあえず日本語のは見つかりませんでした。イメージファイルでないISO-9660自体の解説はあるのですが・・・
514:デフォルトの名無しさん
06/04/23 19:25:43
商用フリーな圧縮解凍ライブラリってありません？
利用はWindowsです。
515:デフォルトの名無しさん
06/04/23 21:59:31
URLﾘﾝｸ(cise.edu.mie-u.ac.jp)
ここのサンプルcomptest.cで解凍しようとしても、エラー起こして解凍できないんだが、できます？
516:515
06/04/24 11:44:22
これで圧縮したのはこれで解凍できるな。
しかし、他で圧縮したのはこれで解凍できないし、これで圧縮したのは他で解凍できない。
ヘッダー？ ヘッダーの処理はzlibはしてくれないんですか？ 初期化時にヘッダー付きを渡すとポインターとカウンターが変わるかもしれないと説明には書いてあるが、実際変わらない。
517:デフォルトの名無しさん
06/04/25 00:08:09
zlibはdeflate処理をしてくれるだけでZIPファイルフォーマットの解釈はやりませんよ。
その辺は自作汁。
この辺の本を読んでみるとよし…と思う
URLﾘﾝｸ(www.amazon.co.jp)
518:デフォルトの名無しさん
06/04/27 18:33:29
zlibを使ってデータの伸張をやろうとしてて
byte *src // 圧縮されたデータ
int len // src の長さ
byte *dst // 解凍されたデータの格納先
dst = malloc(5 * len * sizeof(src));
decompress(dst, src, len); // src を展開して dst に格納
// 適当な処理
free(dst);
みたいなことをやろうかなと考えているんですが、dstで確保したメモリが足りなかったときのことを
考えるとこれじゃあマズいでしょうし、あらかじめ必要なメモリの計算は解凍処理をしないと
分からないようだしでちょっと困っています。
皆さんならどうしますか？
519:デフォルトの名無しさん
06/04/27 21:25:40
圧縮も自前なら圧縮データとは別に（先頭につけるとかして）、
圧縮前のデータのサイズも持っておく。
520:デフォルトの名無しさん
06/04/27 22:28:48
ちなみにsizeof(src)は4バイトだろ。
521:デフォルトの名無しさん
06/04/29 06:05:34
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])が欠けている場合はそれがファイル内容にかかっていても途中までですがデコードできるようです。
522:デフォルトの名無しさん
06/05/04 15:17:36
>513
普通の ISO イメージファイルだったら ISO-9660 に書かれている内容がそのまま直列で入っているだけだと思うが。
523:デフォルトの名無しさん
06/05/04 22:41:50
圧縮する前に圧縮後のファイルサイズのおおよその見当をつけるプログラムを
書こうと思ったんだけど、(ファイルサイズ) x (情報エントロピー) で計算すると
全然いけてないですか？
524:デフォルトの名無しさん
06/05/05 00:07:25
>>523
圧縮につかうモデルでのエントロピーでないとまともな数字が出ない。
ある程度でも結局圧縮するのと同じになってしまうのであまりいけてない。
まあ、とりあえずモデルを特定しないでHuffman,算術符号,RangeEncoderなどの
エントロピーを出しておけば最低保証値だけは出せるかな。
525:デフォルトの名無しさん
06/05/05 00:21:23
> 最低保証値
=元のファイルサイズ
526:デフォルトの名無しさん
06/05/05 14:18:48
ただ、圧縮アルゴリズムと対象データによってはサイズが増えることもありうる希ガス
もちろんその場合は圧縮しなければ元のサイズなんで圧縮しなければいいんだけど
「元のサイズ分あれば十分だろー」ってメモリ確保してやってみらたオーバーフローとか
かっこわるいことになることがあるかもしれない…？
527:デフォルトの名無しさん
06/05/05 15:17:36
>>526
そういうときは、1回の処理で増えうる容量分だけ余分に確保しておけばよい
その見積もりができないとか、1回で無限増殖しうるとか、そういうのはしらね
アルゴリズムを見直すか、出力方法を考え直すべきだがな
528:デフォルトの名無しさん
06/05/05 21:42:11
UDPのパケット（1K～3K)を圧縮して転送、
受信して展開して、通信をやりたいと思ってます。
流すデータは未圧縮の画像データを分断して送受信します。
LZOのような、圧縮・展開の速いプログラムってないでしょうか？
529:デフォルトの名無しさん
06/05/06 00:10:44
>>528
LZOではだめなのかい？
Huffmanあたりをまず試してみて、圧縮率・速度の検討をしてみてはどうか
530:デフォルトの名無しさん
06/05/06 09:04:06
>>529
GPLなので困ってます・・・
＞Huffman
なるほど、試してみます。
531:デフォルトの名無しさん
06/05/10 20:46:46
LZMA SDKを落としてJavaのソースを動かしてみたところ、
コンパイルは何とか通ったのですが実行できません。
ファイルの初期配置も何だか変な気がするのですが…。
これ、何か不具合でしょうか？
それとも私が何かの設定間違ったのでしょうか？
誰かわかる人いたら教えてください。
てか、やっぱりこういう用途でJavaって邪道なんですかね。
扱ってるサイトも見ません。
532:デフォルトの名無しさん
06/05/13 00:35:47
>>531
こういう用途ってどんな用途だよ
533:デフォルトの名無しさん
06/05/13 09:31:01
>>532
その辺からサンプルソースを落として
とりあえずコンパイルすれば何もせずに
目的のものが手に入ると思ってる用途
だろ？
534:531
06/05/16 19:41:24
スルーされたと諦めて見てなかったり。
気まぐれで覗いてみたら回答というか煽り文句がついてて
嬉しいんだか悲しいんだか。
亀ﾚｽになるけど、せっかく返事もらったし。
>>532
ツールを作る用途のつもりで書きました。
ゲーム制作だとかは（使えねぇと言いつつ）結構あるんだけど…
ツールの例がちょっと見つからなかったので。
調査不足ですか。ごめんなさい…。
>>533
適切な分析をどうもありがとう。
とりあえず、パッケージの設定と配置されてる階層が明らかに違うものがあったのですよ。
ちゃんと動かしたら治ったけどね。
サイトのミスかこっちのミスか気になったんだけど
自己解決と言うか自己完結。どうでもよくなっちまった。
535:デフォルトの名無しさん
06/05/16 23:40:15
>>534
それを作者にフィードバックしてこそ、ネットの意義じゃないか・・・
536:デフォルトの名無しさん
06/05/17 03:08:09
商用配布フリーな圧縮解凍ライブラリを探しています。
おすすめなどありますか？
537:デフォルトの名無しさん
06/05/17 05:35:14
>>536
zlib
538:531
06/05/17 08:10:47
>>535
それはそうなんだけどね。私チキンだから…。
それに、いまだに誰もフィードバックしていないという点が
用途に関する疑問につながってるわけで…
まあ、そんな御託というか言い訳はどうでもいいか。
それより改めて聞きたいことができてしまいました。
7z形式のデータ書式がどんな構造してるかわかる人いませんか？
バイナリで開いてみたりしたところ
7z～（たぶんヘッダ）圧縮したファイルのデータ… ファイル名らしきもの（たぶんフッタ）
って構造になってたのですが、これの細かい仕様がわからないのですよ。
使ってる間は保存形式なんて気にもしてなかったんですけどね…
使う側から弄る側に来て、自分の無能っぷりを痛感しております。ﾊｲ。
539:デフォルトの名無しさん
06/05/17 16:35:50
統合アーカイバプロジェクトのいろんなヤツを落とせば
開発用のヘッダとかに書いてあるんじゃねーの、そんなもん。
540:531
06/05/17 18:31:07
>>539
統合アーカイバプロジェクトとは何ぞや…っと。
googleで検索→（ﾟ∀ﾟ；）ｱﾊﾊハ…orz
情報提供ありがとうございます。
理解できるか怪しげですが…やるだけやってみます。
541:531
06/05/18 10:28:18
＞7-zip32.dll は基本的に本家 7-Zip の 7za.exe のソースの
＞main() を呼び出しているだけに過ぎません。
＞理由は 7-Zip は現在進行形で日々進歩しているのでフォーマットを解析して
＞独自に作成すると新しい形式にすぐに対応する事が出来ないためです。
ｳﾎﾞｧｰ(ﾟДﾟ)
542:デフォルトの名無しさん
06/05/18 15:01:52
>>531
本家は最初に見たんだよね？
>>541
統合アーカイバは、
基本的にこの手のものはライブラリで済ますか、
引数の統一を行うインタフェースであることが多い。
543:531
06/05/18 15:50:56
>>542
7-zipの日本語サイトは見ました。
…もしかして、ここで言う本家って、英語ページのことだったりします？
やっぱり見なきゃダメかな…。
byteで取り出してあとはループで解読していけばいいかなーとか考えてたら
解読部分のソースjavaで置いてないし。
7z書庫のフォーマットもわからないし。
フォーマットの解析からするしかないのかな…。
544: ◆rK6fgwCWsM
06/05/18 17:44:01
>>543
7zFormat.txtというそのまんまな文書がLZMA SDKに入っているように思うのですが、気のせいでしょうか。
545:デフォルトの名無しさん
06/05/18 21:09:23
英語のドキュメント読む練習しておくと絶対に役立つよ。
546:531
06/05/18 22:59:37
>>544
…。
('A`)ｳﾎﾞｧｰ
しかもなんか、このﾃｸｽﾄ見覚えがある気がするぞ('A`)ｳﾎﾞｧｰ。
ご指摘ありがとうございます。明日にでも中身見てみます。
やっぱり英語は大事ですね…。
でもノバとか行く気無いしなー。
547:デフォルトの名無しさん
06/05/18 23:50:12
>>546
日本語の読み書き・会話がフツーにできても日本語の難しい技術資料を読むのは大変。
それと同じで、どんなに英語ができるようになっても技術系の情報はどうしても読み辛さがつきまとう。
だからもう英語の技術情報の読み辛さは開き直って受け入れるしかないよ。
ちなみに逆にある程度、英語になれちゃうと日本語と違ってあいまいさが少なく直接的な表現が
多いから下手な日本語の技術資料よりもよっぽど読み易いこともある。
548:デフォルトの名無しさん
06/05/19 01:57:46
>>547
それって逆だろ
英会話はからっきしできなくて英語の小説もさっぱりワカンネ
英語は専門書ぐらいしか読めないやって理系は多いと思うぞ
549:デフォルトの名無しさん
06/05/19 08:13:35
>>548
>英会話はからっきしできなくて英語の小説もさっぱりワカンネ
>英語は専門書ぐらいしか読めないやって理系は多いと思うぞ
俺の経験からすると全く逆だ。俺も英語は技術資料を読むためだけにしか使ってなくて
自分の英語力の低さを嘆いたんだけど、こんなことじゃいかんと英語圏のメーリングリスト
に参加してみたらそこでやりとりされてる会話が思いの外スラスラ読めてビックリした。
それで俺は、あー、やっぱり英会話って中学生の英語レベルで十分意思疎通は可能
なんだなぁと思ったもんだけど。
550:デフォルトの名無しさん
06/05/19 08:39:30
ぶっちゃけ、外国語は才能。
才能の無い奴はいくら勉強しても無駄。
一方で、できる奴がやたら必死に「努力すれば誰でもできる」
ことにしたがるのも外国語という分野。
551:デフォルトの名無しさん
06/05/19 08:57:03
>一方で、できる奴がやたら必死に「努力すれば誰でもできる」
>ことにしたがるのも外国語という分野。
それはその他の多くの分野でもそうだろ。
俺も、中学生の頃ぐらいまではプログラミングを「努力すれば誰でもできる」ものだと吹いていた。
いまじゃ、ほとんど逆のこと言ってるけどねｗ
552:デフォルトの名無しさん
06/05/19 14:16:14
仕事になればかなりのアフォでもアフォなりにプログラムは書けるようになるよ。
仕事じゃないなら、プログラミング自体が趣味だとか、
興味の対象とすることに応用できるとか（音楽家が演奏PG作るとか）何か理由がないと
向いてる人以外はそもそも学習意欲がわかないだろうね。
553:デフォルトの名無しさん
06/05/20 01:10:51
俺みたいに、才能ないけど、好きで趣味でやってるやつもいますよ。お忘れなく。
554:デフォルトの名無しさん
06/05/20 04:33:37
野暮な突込みで恐縮ですが
>>552にも「プログラミング自体が趣味だとか」と書かれておりますし
忘れたわけではないと思いますよ。
555:デフォルトの名無しさん
06/05/21 17:34:54
仕事で、多少リアルタイム性が必要な不定長バイナリの通信データを圧縮
しろって言われてしまいました。データ自体のパターンは限定せず、場合に
よっては1バイトから即時送信できないといけないようです。もちろん、最初の
方のデータが増えるのは構わないのですが、「データ送信を継続しているうち
にだんだん圧縮が効いてくる」ようにしたいのです。
一応売り物に組み込むものなので、自分で作るのは信頼性&手間&特許絡み
でめんどいので、できればzlibあたりを使いたいのですが、こういう場合にも
使えるものなのでしょうか ? おそらく、任意のタイミングで出力バッファを
flushしてデータを送信してしまっても、蓄積した圧縮に必要な情報がそのまま
残って以降のデータに適用できれば使えるとは思うのですが。
556:デフォルトの名無しさん
06/05/21 19:23:27
仕事
しろ
まで読んだ
557:デフォルトの名無しさん
06/05/22 22:32:53
俺は
仕事
しろ
よ
まで読んだ
558:デフォルトの名無しさん
06/05/23 04:51:04
> バイト
> が増えるのは
>
>
> めんどいので、
> おそらく
> そのまま
> 残って ると 思う
559:解凍されたい
06/07/03 18:08:33
Info-ZipのUnzip32.dllのAPIを用いて解凍を行うプログラムを作って
いるのですが、サンプルを参考にして下記のようにしてみても、解凍
後のファイルが作成されません。
m_hUnzipDll = LoadLibrary( "unzip32.dll" );
if( m_hUnzipDll != NULL ){
m_pWiz_SingleEntryUnzip = (_DLL_UNZIP)GetProcAddress( m_hUnzipDll, "Wiz_SingleEntryUnzip" );}
else{ MessageBox( 0, _TEXT("ERROR on LoadLibrary"), 0 ); return;
}
m_lpUnzipUserFunctions.password = Password;
m_lpUnzipUserFunctions.print = DisplayBuf;
m_lpUnzipUserFunctions.sound = NULL;
m_lpUnzipUserFunctions.replace = GetReplaceDlgRetVal;
m_lpUnzipUserFunctions.SendApplicationMessage = ReceiveDllMessage;
m_lpUnzipUserFunctions.ServCallBk = ServerCallback;
LPSTR acArchiveName = "C:\\testdir.zip";
m_lpDcl.ncflag = 1;
m_lpDcl.fQuiet = 2;
m_lpDcl.ntflag = 0;
m_lpDcl.nvflag = 0;
m_lpDcl.nzflag = 0;
m_lpDcl.ndflag = 1;
m_lpDcl.naflag = 0;
m_lpDcl.nfflag = 0;
m_lpDcl.noflag = 1;
m_lpDcl.ExtractOnlyNewer = 0;
m_lpDcl.PromptToOverwrite = 0;
m_lpDcl.lpszZipFN = acArchiveName;
m_lpDcl.lpszExtractDir = NULL;
(*m_pWiz_SingleEntryUnzip)( 0, NULL, 0, NULL, &m_lpDcl, &m_lpUnzipUserFunctions );
FreeLibrary( m_hUnzipDll );
560:解凍されたい
06/07/03 18:09:51
上のプログラムではあらかじめ作成してある C:\testdir.zip という
zipファイルを指定して、unzip32.dllのAPIであるWiz_SingleEntryUnzip
を上記のように呼び出して解凍を試みています。
マニュアルによると、圧縮ファイル内のすべてのファイルを解凍する場合、
第1引数と第2引数は上のように出来るはずなのですが、どこが間違ってい
るのかわからなくなってしまいました。
どなたかよいサンプルプログラム（動くもの）等をご存知の方がいらっし
ゃいましたら教えてはいただけないでしょうか？
561:デフォルトの名無しさん
06/07/04 00:58:13
zlibとかってストリーム形式でデータ扱えるけど、あれ内部的には小さなブロックサイズになって処理されてるの？
もしそうなら、前後の依存関係が問題になって、なかなかいい圧縮率を出せないような・・・
562:デフォルトの名無しさん
06/07/04 03:19:56
zlibはdeflate、deflateはlz77。
lz77は出力したビットへのポインタを符号化する。
なので、後方の依存関係はなくて、常に前方依存。
だからストリームに出来る。
といっても32KBのバッファは必要。
圧縮率の問題は依存とかじゃなくてアルゴリズムの問題。
PPMも前方依存でストリーム可能だけど多くの場合で圧縮率はlzよりもずっと高い。
こっちはメモリ沢山使うし遅いから少し使いにくい。
ちなみにこの前方依存は有限文脈とかマルコフモデルとか呼ばれる。
BWT(ブロックソート)は少し違う。
563:デフォルトの名無しさん
06/07/04 03:46:50
すみません。どこで質問していいのか、わからないのでここで質問させてください。
ウィルス検索について質問です。
ウィスル検索ソフトで圧縮ファイルを検査した場合、ウィルスを検索するのはファイルを一度解凍してから検索しているのでしょうか？
それとも、圧縮されたまま検索されているのでしょうか？
また、どのようにして、検索ソフトはウィルスを発見しているのでしょうか？
回答、お願いいたします。
564:デフォルトの名無しさん
06/07/04 04:19:43
本当にスレ違いなのだが一応。
ソフトによるとしか言いようがない。
圧縮されたものは解凍しなきゃならんわけだから
ファイルが圧縮されているのかどうか調べなきゃならん。
数ある圧縮形式全てを調べるのは不可能だから
普通に考えれば解凍はしないだろう。
ただしOSが扱える形式(WinXPならzip, cab等)は解凍して調べてるかもしれん。
ウィルスは大概怪しげなコードが入っているから、
既知のウィルスに共通している部分をハッシュ化して比較するんじゃないかと予想。
自己参照して実行可能アドレスにロードするとか。
あとは他で聞いとくれ。
565:デフォルトの名無しさん
06/07/04 16:25:05
>>564
大抵は解凍するんじゃない？
以前にどっかのウィルス保護ソフトが日本中の大量のPCを麻痺させた原因が、
圧縮ファイルの展開のバグでCPU100%使い続けてしまうって奴だった。
566:デフォルトの名無しさん
06/07/05 20:37:14
初歩的過ぎる質問でわるいのですけど、
Zlib.dll を使った場合のファイル解凍を行うとき、
使うソフトはなにを使えばよいのでしょうか？
Explzh 等のDLLを組み込んで使うタイプのソフトを探しています。
567:デフォルトの名無しさん
06/07/06 08:33:30
板違いだろ
568:解凍されたい
06/07/07 17:16:51
ネットワーク等のストリームを介してアーカイビング、圧縮／解凍、暗号化
にまで対応した商用ライブラリってありますか？
569:デフォルトの名無しさん
06/07/07 21:39:16
あるよ。
570:デフォルトの名無しさん
06/07/19 16:31:39
商用可能な圧縮・解凍ライブラリを探してるんだけど
zlibだと、ちょっとソースが大きすぎ
このliblzf位の規模で、もう少し圧縮効率が良いのは無いかな？
URLﾘﾝｸ(www.goof.com)
571:デフォルトの名無しさん
06/09/04 22:07:30
保守
572:デフォルトの名無しさん
06/09/07 18:48:02
>>570
奥村先生のアルゴリズム本なんかどうよ
URLﾘﾝｸ(oku.edu.mie-u.ac.jp)
あと、英語が読めるならここも参考になるかも
URLﾘﾝｸ(oku.edu.mie-u.ac.jp)
573:デフォルトの名無しさん
06/09/07 20:20:01
鯖からzipのストリームを貰ってきて
オンザフライでデコードして手に入ったプレインデータから順次描画とかしたいのですが
近道を教示して下さい。
574:デフォルトの名無しさん
06/09/07 20:51:32
URLﾘﾝｸ(www.google.com)
575:デフォルトの名無しさん
06/09/08 12:17:10
>>570
普通のlz77(lzss)のがコード量同規模で数割程度圧縮率高いけど圧縮速度が
576:デフォルトの名無しさん
06/09/08 13:43:27
>>573
zlib のソース・アーカイブの examples/ ディレクトリをまず見たら。
zpipe.c ってのもあるし。
そうそう、ソース とか 英文ドキュメントなら
URLﾘﾝｸ(zlib.net) から辿れるよん。
577:デフォルトの名無しさん
06/09/08 16:23:59
ﾖﾝｻﾏを呼び捨てにするな
578:デフォルトの名無しさん
06/09/11 08:24:10
>>492
今更だけどもう公開してないのね