Beim Herunterladen von Dateien ist es nicht ungewöhnlich, die .tar-Datei zu sehen , .zip oder .gz Erweiterungen. Aber kennen Sie den Unterschied zwischen Tar und Zip und Gz? Warum verwenden wir sie und was ist effizienter, tar oder zip oder gz?
Unterschied zwischen tar, zip und gz
Wenn Sie es eilig haben oder einfach etwas haben möchten, das Sie sich leicht merken können, hier ist der Unterschied zwischen zip und tar und gz:
.tar ==unkomprimierte Archivdatei
.zip ==(normalerweise) komprimierte Archivdatei
.gz ==mit gzip komprimierte Datei (Archiv oder nicht)
Ein bisschen Geschichte von Archivdateien
Wie vieles bei Unix und Unix-ähnlichen Systemen beginnt die Geschichte vor langer, langer Zeit in einer nicht allzu fernen Galaxie namens Siebziger. An einem kalten Morgen im Januar 1979, der tar Dienstprogramm erschien als Teil des neu veröffentlichten Unix V7.
Der tar wurde entwickelt, um viele Dateien effizient auf Bänder zu schreiben. Auch wenn Bandlaufwerke heutzutage der überwiegenden Mehrheit der einzelnen Linux-Benutzer unbekannt sind, Tarballs — der Spitzname von tar Archive – werden immer noch häufig verwendet, um mehrere Dateien oder sogar ganze Verzeichnisbäume (oder sogar Gesamtstrukturen) in eine einzige Datei zu packen.
Eine wichtige Sache, die Sie sich merken sollten, ist ein einfaches tar Datei ist nur ein Archiv deren Daten nicht komprimiert sind. Mit anderen Worten, wenn Sie 100 Dateien mit 50 KB tarieren, erhalten Sie am Ende ein Archiv mit einer Größe von etwa 5000 KB. Der einzige Gewinn, den Sie erwarten können, wenn Sie tar allein verwenden, besteht darin, den vom Dateisystem verschwendeten Speicherplatz zu vermeiden, da die meisten von ihnen Speicherplatz mit einer gewissen Granularität zuweisen (z sie verbrauchen 4 MB, aber das entsprechende tar-Archiv „nur“ 1 MB).
| Erwähnenswert ist hier tar ist sicherlich nicht das einzige Standard-Unix-Tool zum Erstellen von Archiven. Programmierer kennen wahrscheinlich ar da es heute hauptsächlich verwendet wird, um statische Bibliotheken zu erstellen, die nicht mehr als Archive von kompilierten sind Dateien. Aber ar kann verwendet werden, um Archive jeglicher Art zu erstellen. Genau genommen .deb Paketdateien, die auf Debian-Systemen verwendet werden sind ar Archiv! Und unter MacOS X mpkg Pakete sind (waren?) gzip-komprimierte cpio Archiv. Abgesehen davon, noch ar noch cpio genauso beliebt wie tar unter den Nutzern. Vielleicht, weil der tar-Befehl gut genug und einfacher zu benutzen war. |
Das Erstellen von Archiven ist nett. Aber im Laufe der Zeit und mit dem Aufkommen der PC-Ära erkannten die Menschen, dass sie durch Komprimieren enorme Einsparungen beim Speicherplatz erzielen konnten Daten. Also ein Jahrzehnt nach der Einführung oder tar , zip kam in der MS-DOS-Welt als Archivformat heraus, das Komprimierung unterstützt . Das gebräuchlichste Komprimierungsschema für zip ist deflationieren das selbst eine Implementierung des LZ77-Algorithmus ist. Aber das von PKWARE kommerziell entwickelte zip Format leidet seit Jahren unter Patentbelastungen.
Also parallel dazu gzip wurde erstellt, um den LZ77-Algorithmus in einer freien Software zu implementieren, ohne ein PKWARE-Patent zu brechen.
Ein Schlüsselelement der Unix-Philosophie ist „Do One Thing and Do It Well“ , gzip wurde nur entwickelt Dateien komprimieren. Also, um ein komprimiertes Archiv zu erstellen , müssen Sie zuerst ein Archiv erstellen mit dem tar Dienstprogramm zum Beispiel. Und danach werden Sie komprimieren dieses Archiv. Dies ist eine .tar.gz Datei (manchmal abgekürzt als .tgz um noch einmal zu dieser Verwirrung beizutragen – und um die längst vergessenen Beschränkungen für MS-DOS-Dateinamen in 8.3 einzuhalten).
Als sich die Informatik weiterentwickelte, wurden andere Komprimierungsalgorithmen für eine höhere Komprimierungsrate entwickelt. Beispielsweise der in bzip2 implementierte Burrows-Wheeler-Algorithmus (führt zu .tar.bz2 Archiv). Oder neuerdings xz das ist ein LZMA Algorithmusimplementierung ähnlich der in 7zip verwendeten Dienstprogramm.
Verfügbarkeit und Einschränkungen
Heute können Sie jedes Archivdateiformat sowohl unter Linux als auch unter Windows frei verwenden.
Aber als zip Format wird von Windows nativ unterstützt, dieses Format ist besonders in plattformübergreifenden Umgebungen vorhanden. Sie können sogar die ZIP-Datei finden Dateiformat an unerwarteten Stellen. Dieses Dateiformat wurde beispielsweise von Sun für JAR beibehalten Archive, die zur Verteilung kompilierter Java-Anwendungen verwendet werden. Oder für OpenDocument-Dateien (.odf , .odp …) von LibreOffice oder anderen Office-Suiten verwendet. Alle diese Dateiformate sind getarnte ZIP-Archive. Wenn Sie neugierig sind, zögern Sie nicht, es zu entpacken einer von ihnen, um zu sehen, was drin ist:
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
Alles in allem, in der Unix-ähnlichen Welt ich würde immer noch tar bevorzugen Archivtyp, weil die zip Dateiformat unterstützt nicht alle Metadaten des Unix-Dateisystems zuverlässig. Für einige konkrete Erläuterungen zu dieser letzten Aussage müssen Sie wissen, dass das ZIP-Dateiformat nur einen kleinen Satz obligatorischer Dateiattribute definiert, die für jeden Eintrag gespeichert werden müssen:Dateiname, Änderungsdatum, Berechtigungen. Über diese grundlegenden Attribute hinaus kann ein Archivierer zusätzliche Metadaten im sogenannten Extra-Feld des ZIP-Headers speichern. Da zusätzliche Felder jedoch implementierungsdefiniert sind, gibt es selbst für konforme Archivierer keine Garantien, denselben Metadatensatz zu speichern oder abzurufen. Lassen Sie uns das anhand eines Beispielarchivs überprüfen:
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.
Wie Sie sehen können, sind die Eigentumsinformationen (UID/GID) Teil des zusätzlichen Felds – es ist möglicherweise nicht offensichtlich, wenn Sie weder Hexadezimalzahlen noch diese ZIP-Metadaten kennen sind Little-Endian gespeichert, aber kurz „e803“ ist „03e8“ mit „1000“, der Datei-UID. Und „07d0“ ist „d007“, was 2000 ist, die GID der Datei.
In diesem speziellen Fall ist das Info-ZIP zip Das auf meinem Debian-System verfügbare Tool hat einige nützliche Metadaten im Extra-Feld gespeichert. Es gibt jedoch keine Garantie dafür, dass dieses zusätzliche Feld von jedem Archivierer geschrieben wird. Und selbst wenn es vorhanden ist, gibt es keine Garantie dafür, dass es von dem Tool verstanden wird, das zum Extrahieren des Archivs verwendet wird.
Während wir die Tradition als Motivation für die Verwendung von Tarballs nicht ablehnen können , mit diesem kleinen Beispiel verstehen Sie, warum es immer noch einige (Eck-?) Fälle gibt, in denen tar kann nicht durch zip ersetzt werden . Dies gilt insbesondere dann, wenn Sie alle beibehalten möchten Standarddatei-Metadaten.
Tar- vs. Zip- vs. Gz-Effizienztest
Ich werde hier über Platzeffizienz sprechen, nicht über Zeiteffizienz – aber als Faustregel gilt, dass ein Komprimierungsalgorithmus potenziell effizienter ist, da er mehr CPU benötigt.
Und um Ihnen eine Vorstellung von der Komprimierungsrate zu geben, die mit verschiedenen Algorithmen erzielt wird, habe ich auf meiner Festplatte etwa 100 MB an Dateien aus gängigen Dateiformaten gesammelt. Hier sind die Ergebnisse, die ich auf meinem Debian-Stretch-System erhalten habe (alle Größen wie von du -sh gemeldet ):
| Dateityp | .jpg | .mp3 | .mp4 | .odt | .png | .txt |
| Anzahl der Dateien | 2163 | 45 | 279 | 2990 | 2072 | 4397 |
| Platz auf der Festplatte | 98M | 99M | 99M | 98M | 98M | 98M |
| tar | 94M | 99M | 98M | 93M | 92M | 89M |
| zip (nicht komprimiert) | 92M | 99M | 98M | 91M | 91M | 86M |
| zip (deflation) | 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 |
Zunächst ermutige ich Sie, diese Ergebnisse mit Vorsicht zu genießen:Die Datendateien waren tatsächlich hängende Dateien herum auf meiner Festplatte, und ich würde sie in keiner Weise als repräsentativ bezeichnen. Dann muss ich gestehen, dass ich diese Dateitypen nicht zufällig ausgewählt habe. Ich habe es bereits gesagt, .odt Dateien sind bereits ZIP-Dateien. Daher ist der bescheidene Gewinn, der durch ein zweites Komprimieren erzielt wird, nicht überraschend (außer bei bzip2 oder xy, aber ich würde Betrachten Sie dies als eine statistische Anomalie, die durch die geringe Heterogenität meiner Datendateien verursacht wird – die mehrere Backups oder Arbeitsversionen derselben Dokumente enthalten).
Bezüglich .jpg , .mp3 und .mp4 jetzt:vielleicht weißt du, dass das bereits ist komprimierte Datendatei. Besser noch, Sie haben vielleicht gehört, dass sie destruktive Komprimierung verwenden . Das heißt, Sie können das nicht genau rekonstruieren das Originalbild nach einer JPEG-Komprimierung. Und das stimmt. Was jedoch wenig bekannt ist, ist nach der destruktiven Kompressionsphase per se , werden die Daten ein zweites Mal mit dem zerstörungsfreien Huffman-Algorithmus für variable Wortlänge komprimiert, um Datenredundanz zu entfernen.
Aus all diesen Gründen wurde erwartet, dass das Komprimieren von JPEG-Bildern oder MP3/MP4-Dateien nicht zu hohen Gewinnen führt. Bitte beachten Sie, dass eine typische Datei sowohl die stark komprimierten Daten als auch einige unkomprimierte Metadaten enthält, wir können dort immer noch etwas gewinnen. Dies erklärt, warum ich immer noch einen spürbaren Gewinn für JPEG-Bilder habe, da ich viele davon hatte – also war die Gesamtgröße der Metadaten im Vergleich zur Gesamtdateigröße nicht so vernachlässigbar. Wieder einmal die überraschenden Ergebnisse beim Komprimieren von MP4-Dateien mit xz hängen wahrscheinlich mit den hohen Ähnlichkeiten zwischen den verschiedenen MP4-Dateien zusammen, die während meiner Tests verwendet wurden. Oder nicht?
Um diese Zweifel letztendlich auszuräumen, empfehle ich Ihnen dringend, Ihre eigenen Vergleiche anzustellen. Und zögern Sie nicht, Ihre Beobachtungen mit uns über den Kommentarbereich unten zu teilen!