アカウント名:
パスワード:
ついでに xz と zstd に対応してくれ(圧縮も)。
bzip2は……もういらない?
bzip2 は既に役目を終えたのでは? 今さら普及させる意味もなさそう
Unix系 (とMS-DOS系) の圧縮ツールとアルゴリズムの歴史※ ツールによっては副アルゴリズムがあったり複数のアルゴリズムから選択式だったりするので、アルゴリズムは代表的なやつ。細かいミスは詳しい誰かが突っ込むだろう。
pack: 拡張子は z- 太古の Unix 圧縮ツール。アルゴリズムは Huffman- 今から見れば大変残念な圧縮率- 実は gzip は pack 形式も伸張できる- 同世代の MS-DOS (CP/M?) ツールは SQ など
compress: 拡張子は Z- UNIXで標準的に使われていたツール、アルゴリズムは LZW- 小文字 z が pack で使われていたので拡張子が大文字 Z になった- 実は gzip は compress も伸張できる- 同世代の MS-DOS ツールは ARC, ZOO など
gzip: 拡張子は gz- GNU の圧縮ツール、アルゴリズムは Deflate (LZSS + Huffman)- compress が使っている LZW には GIF と同じ特許問題があったので代替が必要だった- compress と同等の速度で圧縮率が非常に高く、バランスが良いため広く普及した- 同世代の MS-DOS ツールは PKZIP/ZIP, LHarc/LHa など- ライブラリの zlib もヘッダやチェックサムが異なるだけで同じアルゴリズム
bzip2: 拡張子は bz2- アルゴリズムは BWT + MTF + Huffman- gzip より圧縮率が高いため普及した- しかし速度が非常に遅いため、gzip を置き換えるには至らず棲み分けになった
xz: 拡張子も xz- アルゴリズムは LZMA (LZSS + Range Corder)- bzip2 よりもさらに圧縮率が高いが少し遅い- bzip2 の用途(遅くても良いから圧縮率を高くしたい)を奪う形で普及した- 同世代の MS-Windows ツールは 7-ZIP (というかこっちが LZMA の本家)- lzip(普及しなかった)もヘッダやチェックサムが異なるだけでほぼ一緒
zstd: 拡張子は zst- 比較的新しいツール、アルゴリズムは LZ77 + FSE- gzip と同じくらいの圧縮率だが、何倍も高速- 今後 gzip の用途(そこそこの圧縮率で高速)を置き換える形になりそう
まとめ:最新の流行は xz と ztsd の棲み分け、この二つのサポートが欲しいところ
あんまり変化や進歩が無いよね。tar と cpio がいつまでも使われている。squashfs はランダムアクセス性を備えたアーカイブと言えなくも無いけど。
lzipも忘れないで
lzip はセンスは良いのだけど xz との普及競争に負けたマイナー品なので忘れても良い。
そして今更誰も言及しないlzh (lha).....パソコン通信時代は標準だったのになぁ。
マイクロソフトは Windows 10 で少し前まで lha 形式をサポートしていたんだけど、アップデートで廃止しちゃったんだよなあ。確か。
セキュリティ的に問題あるんだから、サポート切る方が正しいんじゃないかな
格納ファイル1個につき最大4GB(L1とL3)のヘッダが作れる仕様になってるし、フォーマットそのものに問題ありと言われても仕方ないよーな。
L1はL0と互換性保ちつつL2で導入予定だった拡張ヘッダに対応しようとしたためにL0からはファイルデータに見える位置に拡張ヘッダを置く仕様になってて、結果的にファイルサイズが許容する4GBまで拡張ヘッダ詰め込める仕様になっちゃってる。あと拡張ヘッダに関する仕様も最大ヘッダサイズが64KBのL2を前提に決められているため 4GBまで詰め込めるL1では曖昧な仕様になってる。例えば複数のファイル名ヘッダが現れたら許容するのかエラー扱いするべきなのかとか、許容するとしたら連結するのか最後(最初でもいいけど)を採用するのか実装依存で勝手にやって構わないのか、とか文書化されてないし。
L3に関しては草案段階っぽいけどWindowsで言うところの代替データストリームをヘッダに格納するようにしたのが原因だと思う。
L3に関してはともかくL1に関しては きちんと仕様策定して文書化してればセキュリティソフト側も対応してくれた可能性あるんじゃないかと思うし、全部が全部セキュリティソフト側が悪いってわけじゃないと思うよ。
libarchive自体はlzhに(解凍のみ)対応していて、Windows 10のtarコマンドでは今でもlzh展開できると思います。
未だにlzhデータをダウンロードさせる某役所。何とかして貰えませんか。
未だにlzhデータをダウンロードさせる美佳タイプ。展開方法は説明してるのにFランの悲しさ、開けないと学生から苦情の嵐です。何とかして貰えませんか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
xz, zstd (スコア:0)
ついでに xz と zstd に対応してくれ(圧縮も)。
Re: (スコア:0)
bzip2は……もういらない?
Re: (スコア:0)
bzip2 は既に役目を終えたのでは? 今さら普及させる意味もなさそう
Re:xz, zstd (スコア:2, 参考になる)
Unix系 (とMS-DOS系) の圧縮ツールとアルゴリズムの歴史
※ ツールによっては副アルゴリズムがあったり複数のアルゴリズムから選択式だったりするので、アルゴリズムは代表的なやつ。細かいミスは詳しい誰かが突っ込むだろう。
pack: 拡張子は z
- 太古の Unix 圧縮ツール。アルゴリズムは Huffman
- 今から見れば大変残念な圧縮率
- 実は gzip は pack 形式も伸張できる
- 同世代の MS-DOS (CP/M?) ツールは SQ など
compress: 拡張子は Z
- UNIXで標準的に使われていたツール、アルゴリズムは LZW
- 小文字 z が pack で使われていたので拡張子が大文字 Z になった
- 実は gzip は compress も伸張できる
- 同世代の MS-DOS ツールは ARC, ZOO など
gzip: 拡張子は gz
- GNU の圧縮ツール、アルゴリズムは Deflate (LZSS + Huffman)
- compress が使っている LZW には GIF と同じ特許問題があったので代替が必要だった
- compress と同等の速度で圧縮率が非常に高く、バランスが良いため広く普及した
- 同世代の MS-DOS ツールは PKZIP/ZIP, LHarc/LHa など
- ライブラリの zlib もヘッダやチェックサムが異なるだけで同じアルゴリズム
bzip2: 拡張子は bz2
- アルゴリズムは BWT + MTF + Huffman
- gzip より圧縮率が高いため普及した
- しかし速度が非常に遅いため、gzip を置き換えるには至らず棲み分けになった
xz: 拡張子も xz
- アルゴリズムは LZMA (LZSS + Range Corder)
- bzip2 よりもさらに圧縮率が高いが少し遅い
- bzip2 の用途(遅くても良いから圧縮率を高くしたい)を奪う形で普及した
- 同世代の MS-Windows ツールは 7-ZIP (というかこっちが LZMA の本家)
- lzip(普及しなかった)もヘッダやチェックサムが異なるだけでほぼ一緒
zstd: 拡張子は zst
- 比較的新しいツール、アルゴリズムは LZ77 + FSE
- gzip と同じくらいの圧縮率だが、何倍も高速
- 今後 gzip の用途(そこそこの圧縮率で高速)を置き換える形になりそう
まとめ:最新の流行は xz と ztsd の棲み分け、この二つのサポートが欲しいところ
アーカイブは (スコア:0)
あんまり変化や進歩が無いよね。tar と cpio がいつまでも使われている。
squashfs はランダムアクセス性を備えたアーカイブと言えなくも無いけど。
Re: (スコア:0)
lzipも忘れないで
Re: (スコア:0)
lzip はセンスは良いのだけど xz との普及競争に負けたマイナー品なので忘れても良い。
Re: (スコア:0)
そして今更誰も言及しないlzh (lha).....
パソコン通信時代は標準だったのになぁ。
Re: (スコア:0)
マイクロソフトは Windows 10 で少し前まで lha 形式をサポートしていたんだけど、アップデートで廃止しちゃったんだよなあ。確か。
Re: (スコア:0)
セキュリティ的に問題あるんだから、サポート切る方が正しいんじゃないかな
Re: (スコア:0)
lha形式の圧縮ファイルを展開できないアンチウイルスソフトの方なので
OS標準で対応されればセキュリティ問題だって解決されるのでは。
Re:xz, zstd (スコア:2)
格納ファイル1個につき最大4GB(L1とL3)のヘッダが作れる仕様になってるし、フォーマットそのものに問題ありと言われても仕方ないよーな。
L1はL0と互換性保ちつつL2で導入予定だった拡張ヘッダに対応しようとしたためにL0からはファイルデータに見える位置に拡張ヘッダを置く仕様になってて、結果的にファイルサイズが許容する4GBまで拡張ヘッダ詰め込める仕様になっちゃってる。あと拡張ヘッダに関する仕様も最大ヘッダサイズが64KBのL2を前提に決められているため 4GBまで詰め込めるL1では曖昧な仕様になってる。例えば複数のファイル名ヘッダが現れたら許容するのかエラー扱いするべきなのかとか、許容するとしたら連結するのか最後(最初でもいいけど)を採用するのか実装依存で勝手にやって構わないのか、とか文書化されてないし。
L3に関しては草案段階っぽいけどWindowsで言うところの代替データストリームをヘッダに格納するようにしたのが原因だと思う。
L3に関してはともかくL1に関しては きちんと仕様策定して文書化してればセキュリティソフト側も対応してくれた可能性あるんじゃないかと思うし、全部が全部セキュリティソフト側が悪いってわけじゃないと思うよ。
Re: (スコア:0)
libarchive自体はlzhに(解凍のみ)対応していて、Windows 10のtarコマンドでは今でもlzh展開できると思います。
Re: (スコア:0)
未だにlzhデータをダウンロードさせる某役所。何とかして貰えませんか。
Re: (スコア:0)
未だにlzhデータをダウンロードさせる美佳タイプ。展開方法は説明してるのにFランの悲しさ、開けないと学生から苦情の嵐です。何とかして貰えませんか。