Tar Vs Zip Vs Gz:違いと効率

ファイルのダウンロード中に、 .tar.zip、または.gzの拡張子が表示されることは珍しくありません。 しかし、あなたはTarとZipとGzの違いを知っていますか なぜ私たちはそれらを使うのか、そしてどちらがより効率的なのか、tar、zip、gzのどれですか。

tar、zip、gzの違い

急いでいる場合や覚えやすいものにしたい場合は、zipとtar、gzの違いを次に示します。

.tar ==非圧縮アーカイブファイル

.zip ==(通常)圧縮アーカイブファイル

gzipを使用して圧縮された.gz ==ファイル(アーカイブかどうか)

アーカイブファイルのちょっとした歴史

UnixやUnix風のシステムに関する多くのことと同じように、物語はずっと前に、70年代と呼ばれるそれほど遠くない銀河の中で始まります。 1979年1月の寒い朝、 tarユーティリティは新しくリリースされたUnix V7の一部として登場しました。

tarユーティリティは、テープに多数のファイルを効率的に書き込むための方法として設計されました。 今日のテープドライブが大多数の個々のLinuxユーザに知られていなくても、 tarball - tarアーカイブのニックネーム - は、依然としていくつかのファイル、あるいはディレクトリツリー全体(あるいはフォレスト)さえも単一のファイルにパッケージするのに使われます。

覚えておくべき重要なことの一つは、普通のtarファイルはデータが圧縮されていない単なるアーカイブです。 言い換えれば、50kBのファイルを100個タールすると、サイズが5000kB前後のアーカイブになってしまいます。 たいていの場合、tarを単独で使用することで期待できるのは、ファイルシステムによって無駄に使用されるスペースを避けることです(たとえば、私のシステムでは、1バイトのファイルは4kBのディスクスペースを使用します)。 4MBを使用しますが、対応するtarアーカイブは「1MB」のみです)。

ここで言及する価値があるのは、アーカイブを作成するための標準のUnixツールがtarだけではないことです。 ほとんどの場合、プログラマはarを知っているので、静的ライブラリの作成に使用されています。静的ライブラリは、 コンパイル済みファイルのアーカイブにすぎません。 しかし、 arはあらゆる種類のアーカイブを作成するために使用することができます。 実際、Debianシステムで使用されている.debパッケージファイル arアーカイブです。 そしてMacOS Xでは、 mpkgパッケージはgzip圧縮されたcpioアーカイブです。 そうは言っても、 arcpioもユーザーの間ではtarほど人気が​​あるわけではありません。 たぶん、tarコマンドが十分に使いやすくて簡単だったからです。

あなたが探している種類のタールではありません

アーカイブを作成するのはいいことです。 しかし、時がたつにつれて、そしてパーソナルコンピュータ時代の到来とともに、人々はデータを圧縮することによってストレージを大幅に節約できることに気づいた。 それで、導入またはtarの 10年後、 zip圧縮をサポートするアーカイブフォーマットとしてMS-DOSの世界で出てきました。 zipの最も一般的な圧縮方式はdeflateです。これは、それ自体がLZ77アルゴリズムの実装です。 しかしPKWAREによって商業的に開発されているため、zi pフォーマットは何年もの間、特許の煩わしさに苦しんできました。

したがって、並行して、 gzipは、PKWAREの特許を侵害することなく、フリーソフトウェアでLZ77アルゴリズムを実装するために作成されました。

Unixの哲学の重要な要素である「1つのことをうまくやる」という gzipは、ファイルの圧縮のみを目的として設計されています。 したがって、 圧縮アーカイブを作成するには、まずたとえばtarユーティリティを使用してアーカイブを作成する必要があります。 そしてその後、そのアーカイブを圧縮します。 これは.tar.gzファイルです(混乱を避けるために.tgzと省略されることがあります - 忘れられていた8.3 MS-DOSファイル名の制限に準拠するため)。

コンピュータサイエンスが進化するにつれて、他の圧縮アルゴリズムがより高い圧縮率用に設計されました。 たとえば、Burrows-Wheelerアルゴリズムはbzip2で実装されています( .tar.bz2アーカイブにつながります)。 もっと最近では、 xz7zipユーティリティで使われているものに似たLZMAアルゴリズムの実装です。

可用性と制限

今日では、LinuxとWindowsの両方で自由にアーカイブファイルフォーマットを使用することができます。

しかし、 zipフォーマットはWindows上でネイティブにサポートされているので、これは特にクロスプラットフォーム環境に存在します。 あなたも、予期しない場所でzipファイル形式を見つけることができます。 たとえば、そのファイル形式は、コンパイルされたJavaアプリケーションの配布に使用されるJARアーカイブのためにSunによって保持されていました。 またはLibreOfficeまたは他のオフィススイートで使用されるOpenDocumentファイル( .odf.odp …)用です。 これらのファイル形式はすべて、偽のzipアーカイブです。 あなたが興味を持っているならば、中にあるものを見るためにそれらのうちの1つを解凍することを躊躇しないでください

 sh $ unzip some-file.odtアーカイブ:some-file.odt抽出:MIMEタイプの膨張:meta.xmlの膨張:settings.xmlの膨張:content.xm [...]膨張:styles.xmlの膨張:META-INF /マニフェスト.xml 

とにかく、Unixライクな世界でzipファイル形式がすべてのUnixファイルシステムメタデータを確実にサポートしているわけではないので、 は依然としてtarアーカイブタイプを好むでしょう。 この最後のステートメントの具体的な説明については、ZIPファイル形式で各エントリに保存する必須のファイル属性の小セット(ファイル名、変更日、アクセス許可)のみが定義されていることを知っておく必要があります。 これらの基本的な属性以外にも、アーカイバはZIPヘッダーのいわゆるextraフィールドに追加のメタデータを格納することがあります。 しかし、追加のフィールドは実装によって定義されているため、準拠しているアーカイバであっても同じメタデータのセットを格納または取得するという保証はありません。 サンプルアーカイブでそれをチェックしましょう:

 sh $ ls -lsnデータ/チームの合計0 0 -rw-r - r-- 1 1000 2000 0 Jan 30 12:29 team sh $ zip -0r archive.zip data / 
 sh $ zipinfo -v archive.zip data / team中央ディレクトリのエントリ#5:--------------------------- data / team [.. ]見かけのファイルタイプ:バイナリUnixファイル属性(100644 8進数):-rw-r - r-- MS-DOSファイル属性(00 hex):なし中央ディレクトリの追加フィールドには、次のものが含まれます。 - ID 0x5455のサブフィールド世界時)と5データバイト。 ローカル追加フィールドには、UTC / GMT変更/アクセス時間があります。 - ID 0x7875(Unix UID / GID(任意のサイズ))および11データバイトのサブフィールド:01 04 e8 03 00 00 04 d0 07 00 00。 

ご覧のとおり、所有権情報(UID / GID)は余分なフィールドの一部です - 16進数がわからない場合やZIPメタデータがリトルエンディアンで格納されている場合は明らかではありませんが、略して「e803」は“ 03e8”は“ 1000”、ファイルのUIDです。 そして、“ 07d0”は“ d007”で、これはファイルGIDの2000です。

そのような場合、私のDebianシステムで利用可能なInfo-ZIP zipツールは追加フィールドにいくつかの有用なメタデータを格納しました。 しかし、この追加フィールドがすべてのアーカイバによって書き込まれるという保証はありません。 そしてたとえ存在していても、アーカイブを抽出するために使用されるツールによってこれが理解される保証はありません。

tarballをまだ使用している動機として伝統を否定することはできませんが、この小さな例では、 tarzipに置き換えることができない場合がまだいくつかある(コーナー?)場合があることを理解できます。 これは標準のファイルメタデータをすべて保持たい場合に特に当てはまります。

Tar対Zip対Gz効率テスト

ここでは、時間効率ではなく、スペース効率について説明します。ただし、経験則として、より効率的になる可能性があるのは圧縮アルゴリズムで、必要なCPUも多くなります。

また、さまざまなアルゴリズムを使用して得られた圧縮率を把握するために、よく使用されるファイル形式から約100MBのファイルをハードドライブに集めました。 これが私のDebian Stretchシステムで得られた結果です(すべてのサイズはdu -shによって報告されたものと同じです)。

ファイルの種類.jpg.mp3.mp4.odt.png。txt
ファイル数21634527929902072年4397
ディスク上のスペース98M99M99M98M98M98M
タール94M99M98M93M92M89M
zip(圧縮なし)92M99M98M91M91M86M
ジップ(収縮)87M98M93M85M77M28M
tar + gzip86M98M93M82M77M27M
tar + bz287M98M93M42M71M22M
tar + xz70M98M22M348K51M19M

まず、データファイルは実際には私のハードドライブにぶら下がっているファイルであり、決して代表的なものであるとは主張しません。 それから、私はこれらのファイルタイプをランダムに選択しなかったことを告白しなければなりません。 私はすでにそれを言った、 .odtファイルはすでにzipファイルです。 そのため、2回圧縮して得られた控えめな増加は驚くべきことではありません(bzip2またはxyを除く)。ただし、データファイルの異質性が低いことによって引き起こされる統計的な異常としてドキュメント)。

今すぐjpg.mp3 、および.mp4に関して:多分あなたはそれらが既に圧縮されたデータファイルであることを知ってます。 さらに良いことに、あなたは彼らが破壊的な圧縮を使っているのを聞いたかもしれません。 つまり、JPEG圧縮後に元の画像を正確に再構築することはできません。 そしてそれは本当です。 しかし、あまり知られていないことは、破壊的圧縮フェーズ自体の後に、データを冗長性を排除するために非破壊的ハフマン可変ワード長アルゴリズムを使用して2回圧縮されることです。

これらすべての理由から、JPEG画像やMP3 / MP4ファイルの圧縮では大きな効果が得られないと予想されていました。 一般的なファイルには、高度に圧縮されたデータと圧縮されていないメタデータの両方が含まれているため、まだ少し問題がある可能性があります。 これが私がまだ私がそれらの多くを持っていたので私がまだJPEG画像のために顕著な利益を持っている理由を説明します - 従って全体のメタデータサイズは全体のファイルサイズと比較してそれほど無視できませんでした。 繰り返しますが、 xzを使用してMP4ファイルを圧縮したときの驚くべき結果は、私のテストで使用したさまざまなMP4ファイル間の高い類似性におそらく関連しています。 それともそうではありませんか?

最終的にそれらの疑問を持ち上げるために、私はあなたがあなた自身の比較をすることを強く勧めます。 そして、下のコメント欄を使ってあなたの観察を私達と共有することを躊躇しないでください!

推奨されます

Linux Foundation、データ共有用のオープンソースライセンス契約を発表
2019
Linux Machine Vendor System76が独自のLinuxディストリビューションを発表
2019
どのようにNetflixはあなたのお気に入りを明らかにするためにオープンソースAIを展開します
2019