ファイルのダウンロード中に、 .tarが表示されることは珍しくありません。 、 .zip または.gz 拡張機能。しかし、 TarとZipとGzの違いを知っていますか？ なぜそれらを使用するのですか？tar、zip、gzのどちらがより効率的ですか？
tar、zip、gzの違い
お急ぎの場合、または覚えやすいものを入手したい場合は、zipとtarおよびgzの違いを次に示します。
.tar==非圧縮アーカイブファイル
.zip==（通常）圧縮アーカイブファイル
.gz ==gzipを使用して圧縮されたファイル（アーカイブかどうか）
アーカイブファイルの履歴
UnixおよびUnixライクなシステムに関する多くのことと同様に、物語はずっと昔、70年代と呼ばれるそれほど遠くない銀河で始まります。 1979年1月のある寒い朝、 tar ユーティリティは、新しくリリースされたUnixV7の一部として登場しました。
tar ユーティリティは、テープに多くのファイルを効率的に書き込む方法として設計されました。現在、テープドライブが個々のLinuxユーザーの大多数に知られていない場合でも、 tarballs — tarのニックネーム アーカイブ—現在でも、複数のファイルまたはディレクトリツリー全体（またはフォレスト）を1つのファイルにパッケージ化するために一般的に使用されています。
覚えておくべき重要なことの1つは、プレーンな tar ファイルは単なるアーカイブです そのデータは圧縮されていません。つまり、50kBのファイルを100個タール化すると、アーカイブのサイズは約5000kBになります。 tarのみを使用して期待できる唯一のメリットは、ファイルシステムによって無駄になるスペースを回避することです。これは、ほとんどのファイルがある程度の粒度でスペースを割り当てるためです（たとえば、私のシステムでは、1バイトの長さのファイルは4kBのディスクスペースを使用します。それらは4MBを使用しますが、対応するtarアーカイブは「1MBのみ」です。
| ここで言及する価値がありますtar 確かに、アーカイブを作成するための標準的なUnixツールはこれだけではありません。プログラマーはおそらくar 今日では、静的ライブラリを作成するために主に使用されています。静的ライブラリは、コンパイルされたのアーカイブにすぎません。 ファイル。しかし、 ar あらゆる種類のアーカイブを作成するために使用できます。実際、 .deb Debianシステムで使用されるパッケージファイルは ar アーカイブ！ MacOS Xでは、 mpkg パッケージは（だった？）gzip圧縮された cpio アーカイブ。そうは言っても、 また、 cpio tarと同じくらい人気を博しました ユーザーの間で。 tarコマンドが十分に優れていて使いやすいためかもしれません。 |
アーカイブの作成は便利です。しかし、時が経ち、パソコン時代の到来とともに、人々は圧縮することでストレージを大幅に節約できることに気づきました。 データ。つまり、導入または tarから10年後 、 zip MS-DOSの世界では、圧縮をサポートするアーカイブ形式として登場しました。 。 zipの最も一般的な圧縮方式 収縮 これ自体がLZ77アルゴリズムの実装です。しかし、PKWAREによって商業的に開発されている、zi p フォーマットは何年にもわたって特許の妨害に苦しんでいます。
つまり、並行して gzip PKWAREの特許を破ることなく、LZ77アルゴリズムを自由ソフトウェアに実装するために作成されました。
Unix哲学の重要な要素は、「1つのことを実行してそれをうまく実行する」です。 、 gzip のみに設計されています ファイルを圧縮します。したがって、圧縮されたアーカイブを作成するために 、最初にアーカイブを作成する必要があります タールを使用する たとえば、ユーティリティ。その後、圧縮します そのアーカイブ。これは.tar.gz ファイル（ .tgzと省略されることもあります その混乱を再び増し、長い間忘れられていた8.3 MS-DOSファイル名の制限に準拠するため）。
コンピュータサイエンスが進化するにつれて、他の圧縮アルゴリズムがより高い圧縮率のために設計されました。たとえば、 bzip2 に実装されているBurrows–Wheelerアルゴリズム （ .tar.bz2につながる アーカイブ）。または最近ではxz これはLZMA 7zipで使用されているものと同様のアルゴリズムの実装 ユーティリティ。
可用性と制限
現在、LinuxとWindowsの両方で任意のアーカイブファイル形式を自由に使用できます。
ただし、 zip フォーマットはWindowsでネイティブにサポートされており、これは特にクロスプラットフォーム環境で存在します。 zipも見つけることができます 予期しない場所でのファイル形式。たとえば、そのファイル形式はSunによって JARのために保持されました。 コンパイルされたJavaアプリケーションの配布に使用されるアーカイブ。または、OpenDocumentファイルの場合（ .odf 、 .odp …）LibreOfficeまたは他のオフィススイートで使用されます。これらのファイル形式はすべて、偽装したzipアーカイブです。興味がある場合は、遠慮なく解凍してください。 そのうちの1つで、中身を確認します：
sh$ unzip some-file.odt Archive:some-file.odt extracting: mimetype inflating: meta.xml inflating: settings.xml inflating: content.xm [...] inflating: styles.xml inflating: META-INF/manifest.xml
言うまでもなく、Unixライクな世界では、私 それでもtar zip であるため、アーカイブタイプ ファイル形式は、すべてのUnixファイルシステムメタデータを確実にサポートするわけではありません。最後のステートメントの具体的な説明については、ZIPファイル形式で、各エントリに保存する必須のファイル属性の小さなセット（ファイル名、変更日、権限）のみが定義されていることを知っておく必要があります。これらの基本的な属性に加えて、アーカイバは、ZIPヘッダーのいわゆる追加フィールドに追加のメタデータを格納する場合があります。ただし、追加のフィールドは実装によって定義されるため、準拠しているアーカイバでさえ、同じメタデータのセットを格納または取得する保証はありません。サンプルアーカイブでそれを確認しましょう：
sh$ ls -lsn data/team total 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 Central directory entry #5: --------------------------- data/team [...] apparent file type: binary Unix file attributes (100644 octal): -rw-r--r-- MS-DOS file attributes (00 hex): none The central-directory extra field contains: - A subfield with ID 0x5455 (universal time) and 5 data bytes. The local extra field has UTC/GMT modification/access times. - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes: 01 04 e8 03 00 00 04 d0 07 00 00.
ご覧のとおり、所有権情報（UID / GID）は追加フィールドの一部です。16進数やZIPメタデータがわからない場合は、わかりにくい場合があります。はリトルエンディアンで保存されますが、略して「e803」は「03e8」で、「1000」はファイルUIDです。また、「07d0」は「d007」であり、ファイルGIDである2000です。
その特定のケースでは、Info-ZIP zip 私のDebianシステムで利用可能なツールは、追加のフィールドにいくつかの有用なメタデータを保存しました。ただし、この追加フィールドがすべてのアーカイバによって書き込まれる保証はありません。また、存在する場合でも、アーカイブの抽出に使用されるツールによってこれが理解される保証はありません。
一方、 tarballsを引き続き使用する動機として伝統を否定することはできません。 、この小さな例を使用すると、 tar がまだいくつかの（コーナー？）ケースがある理由を理解できます。 zipに置き換えることはできません 。これは、すべてを保持したい場合に特に当てはまります。 標準のファイルメタデータ。
Tar vs ZipvsGz効率テスト
ここでは、時間効率ではなくスペース効率について説明しますが、経験則として、より潜在的に効率的なのは圧縮アルゴリズムであり、より多くのCPUが必要です。
そして、さまざまなアルゴリズムを使用して得られた圧縮率のアイデアを提供するために、一般的なファイル形式から約100MBのファイルをハードドライブに収集しました。これが私のDebianStretchシステムで得られた結果です（ du -shによって報告されたすべてのサイズ ）：
| ファイルタイプ | 。jpg | 。mp3 | 。mp4 | 。odt | 。png | 。txt |
| ファイル数 | 2163 | 45 | 279 | 2990 | 2072 | 4397 |
| ディスク上のスペース | 98M | 99M | 99M | 98M | 98M | 98M |
| tar | 94M | 99M | 98M | 93M | 92M | 89M |
| zip（圧縮なし） | 92M | 99M | 98M | 91M | 91M | 86M |
| zip（deflate） | 87M | 98M | 93M | 85M | 77M | 28M |
| tar + gzip | 86M | 98M | 93M | 82M | 77M | 27M |
| tar + bz2 | 87M | 98M | 93M | 42M | 71M | 22M |
| tar + xz | 70M | 98M | 22M | 348K | 51M | 19M |
まず、これらの結果を非常に重要なものとして取得することをお勧めします。データファイルは実際にはファイルがぶら下がっていました。私のハードドライブの周りにあり、私は彼らが決して代表的であるとは主張しません。次に、これらのファイルタイプをランダムに選択しなかったことを告白する必要があります。すでに言いましたが、 .odt ファイルはすでにzipファイルです。したがって、それらを2回圧縮することによって得られる適度なゲインは、驚くべきことではありません（bzip2またはxyを除くが、私は これは、データファイルの不均一性が低いことによって引き起こされる統計上の異常であると考えてください。同じドキュメントの複数のバックアップまたは作業バージョンが含まれています。
.jpgについて 、 .mp3 および.mp4 今：多分あなたはそれらがすでにあることを知っています 圧縮データファイル。さらに良いことに、彼らが破壊的圧縮を使用していると聞いたことがあるかもしれません。 。つまり、正確に再構築することはできません JPEG圧縮後の元の画像。そしてそれは本当です。しかし、ほとんど知られていないのは、破壊的な圧縮フェーズ自体の後です 、非破壊ハフマン可変ワード長アルゴリズムを使用してデータを2回圧縮し、データの冗長性を排除します。
これらすべての理由から、JPEG画像またはMP3/MP4ファイルを圧縮しても高いゲインが得られないことが予想されました。通常のファイルには、高度に圧縮されたデータといくつかの非圧縮のメタデータの両方が含まれているため、ここで少し何かを得ることができます。これは、JPEG画像の多くを持っていたのに、まだ顕著な利益がある理由を説明しています。したがって、全体的なメタデータサイズは、ファイルの合計サイズと比較してそれほど無視できませんでした。繰り返しになりますが、 xzを使用してMP4ファイルを圧縮すると驚くべき結果が得られます おそらく、私のテスト中に使用されたさまざまなMP4ファイル間の高い類似性に関連しています。それともそうではありませんか？
最終的にこれらの疑問を解消するために、独自の比較を行うことを強くお勧めします。そして、下のコメントセクションを使用して私たちとあなたの観察を共有することを躊躇しないでください！