Dateien zu kompromieren, ist nützlich, um Ressourcen wie Plattenplatz oder Internetbandbreite zu schonen. Wir erklären, wie Kompression funktioniert, und vergleichen die gängigen Archivformate.

Sicher haben Sie Begriffe wie “Tarball” oder “komprimiertes Archiv” schonmal gehört: Im Linux-Alltag begegnen Ihnen solche Dateien häufig. Auch wenn es auf den ersten Blick nicht so aussieht: Selbst die RPM- oder Deb-Pakete, die OpenSuse- und Ubuntu-Systeme für die Paketverwaltung nutzen, sind komprimierte Software-Archive – wenn auch in einer besonderen Variante. Andere Hersteller verteilen Treiberupdates oder ihre Programme in komprimierten Tar-Archiven. Der Grund für die Nutzung komprimierter Archive ist immer derselbe: Datenkompression ermöglicht es, vorhandene Ressourcen deutlich effizienter zu nutzen. Auf dieselbe Platte passen also mehr komprimierte als unkomprimierte Daten, und auch der Datentransfer über eine Internetverbindung ist schneller, wenn sie komprimierte Daten übertragen.

Die Idee, vorhandene Daten durch geschickte Kompression zu verkleinern, ist dabei so alt wie die Informatik selbst, die Kompressionsformate der Gegenwart haben mit ihren historischen Vorgängern allerdings nicht mehr viel zu tun. Ein Blick auf die Kompressionsurgesteine hilft jedoch dabei, den inneren Mechanismus zu verstehen: Algorithmus-basierte Datenkompression funktioniert nach dem immer gleichen Prinzip, nur die Algorithmen haben sich in den vergangenen Jahren stetig weiter entwickelt. In diesem Artikel erklären wir, welche Kompressionsverfahren es gibt, wie diese funktionieren und welche Algorithmen unter Linux für bestimmte Dateitypen ideal sind. Dabei treten Gzip, Bzip2, Zip, Rar und LZMA gegeneinander an.

Verlustbehaftete und verlustfreie Kompression

Die Frage, wie Kompression eigentlich funktioniert, verlangt nach einer differenzierten Antwort – zwei fundamental unterschiedliche Prinzipien treten gegeneinander an: Auf der einen Seite steht die verlustbehaftete Kompression und auf der anderen die verlustfreie. Beide Kompressionsarten sind Ihnen garantiert schon untergekommen.

Verlustbehaftete Kompression kommt gerne bei Bild- oder Tondokumenten zum Einsatz. Die Idee dabei ist, dass aus dem vorhandenen Rohmaterial solche Sequenzen entfernt werden, die für das menschliche Auge oder das menschliche Ohr nicht erkennbar wären. Typisches Beispiel: Auf eine simple Audio-CD passen im Normalfall 700 MByte Daten, was je nach Liedlänge etwa zehn bis 14 Songs entspricht. Wenn Sie die Lieder der CD per Ripper auf Ihren Computer übertragen und beispielsweise das MP3-Format wählen, sind die einzelnen Lieddateien selbst bei hoher Qualität in der Regel nicht größer als 8 MByte. Selbst geübte Ohren erkennen keinen Unterschied.

Ähnliches gilt für Fotos und Videos: Die RAW-Version eines Fotos, das mit einer digitalen Kamera aufgenommen worden ist, ist unkomprimiert und dadurch schnell mehrere Dutzend Megabyte groß. Nach der üblichen Kompression mit dem JPEG-Algorithmus [1] schrumpft die Datei erheblich, im Schnitt auf 3 MByte bis 6 MByte. Wer mit einer schlechteren Bildqualität leben kann, erreicht auch noch deutlich stärkere Kompression (Abbildung 1). Video-Formate wie MPEG2 oder H.265 [2] arbeiten nach dem gleichen Prinzip.

Abbildung 1: Wie stark der Informationsverlust ist, kann man beim JPEG-Format wählen. Das Bild links oben hat nur ca. ein Zehntel der Größe des Originalbilds (rechts), sieht aber deutlich schlechter aus.

Würden Sie allerdings die MP3-Songs aus dem Musikbeispiel wieder auf CD brennen und dabei eine Audio-CD erstellen, wäre die gebrannte CD nicht identisch mit dem Original, von dem Sie die Lieder ursprünglich kopiert haben. Durch die Komprimierung sind Informationen aus den Liedern unwiderruflich verloren gegangen.

Bei der verlustfreien Kompression ist das anders. Sie kommt in der Regel dort zum Einsatz, wo es unerlässlich ist, aus einer komprimierten Datei genau die Daten wiederherzustellen, die vor der Kompression vorhanden waren. Ein Tarball ist ein gutes Beispiel: Wenn Sie auf einem Rechner Dateien in ein Tar-Archiv packen und dieses danach mit gzip komprimieren, können Sie die kleinere Datei auf einen anderen Rechner kopieren und erwarten, dass dort nach dem Dekomprimieren und dem Entpacken des Tarballs exakt die gleichen Daten vorhanden sind, die Sie auf dem ersten Rechner in das Archiv gepackt haben. Verlustfreie Kompression kommt also immer dann zum Einsatz, wenn sich die originalen Daten nicht verändern dürfen.

Von Vergleichen und Algorithmen

Verlustfreie Kompression funktioniert im Grunde recht simpel: Der Kompressionsalgorithmus durchsucht die vorhandenen Daten und überprüft sie auf verschiedene Merkmale hin. Ein solches Merkmal könnte etwa ein Wort sein, das mehrere Male vorkommt: Der Kompressionsalgorithmus könnte dieses lange Wort zum Beispiel durch eine kürzere Zeichenkette ersetzen und sich merken, dass die kürzere Zeichenkette beim Dekomprimieren später wieder durch das eigentliche Wort zu ersetzen ist. Weil dieses Merken in Form eines Wörterbuchs passiert, spricht man von der “Wörterbuchmethode”. Diese Methode liegt fast allen modernen Kompressionsalgorithmen zugrunde.

Dabei gibt es eine direkte Korrelation zwischen der Effizienz des Algorithmus’ und dem Aufwand, den der jeweilige Algorithmus verursacht. Besonders gute Algorithmen sorgen auf der einen Seite für eine beachtliche Reduktion der Größe der ursprünglichen Datei, müssen im Gegenzug aber diese auch besonders gründlich untersuchen und ein entsprechend großes Wörterbuch anlegen. Das schlägt sich unmittelbar auf die Zeit nieder, die für das Komprimieren nötig ist. Grundsätzlich gilt: Je effizienter der Algorithmus, desto länger dauert die Kompression und desto CPU-intensiver ist der Vorgang. Gerade auf langsamen Systemen brauchen Bzip2 oder LZMA bei großen Dateien eine ganze Weile für ihr Werk. Auch auf modernen Computern mit viel CPU-Leistung sind die Unterschiede noch zu bemerken.

Algorithmen und Archive

Bevor wir uns mit den einzelnen Kompressionsalgorithmen und ihrer Wirksamkeit beschäftigen, geben wir noch einen praktischen Hinweis: Die Bezeichnungen der einzelnen Lösungen wie Gzip, Bzip2, Zip oder 7z begegnen Ihnen im Alltag regelmäßig und kommen wild durcheinander zum Einsatz. Tatsächlich gibt es aber einen wichtigen Unterschied: Manche Bezeichnungen beziehen sich auf reine Kompressionsformate (wie Gzip, Bzip2 oder LZMA) während andere Begriffe Archivformate mit oder ohne integrierte Kompression bezeichnen (Tar, Zip, Rar). Der Teufel steckt im Detail: Ein Archivformat dient lediglich dazu, mehrere Dateien in ein einzelnes Archiv zu packen. Dieses ist aber nicht zwangsläufig komprimiert. Der Unix-Allrounder tar legt etwa nicht automatisch ein Archiv mit Kompression an; über Optionen (etwa -z, -j oder -J) aktivieren Sie die Kompression bei Bedarf händisch. Archivformate mit integrierter Kompression sind hingegen automatisch ab Werk komprimiert, das gilt z. B. für Zip, Rar und 7z.

Es kann übrigens durchaus vorkommen, dass Archivformate mit integrierter Kompression dieselben Algorithmen nutzen, die auch in Form eigenständiger Programme verfügbar sind. Das 7z-Archivformat setzt etwa auf den LZMA-Algorithmus, für den auch das Kommandozeilenwerkzeug xz existiert. Mit letzterem lassen sich einzelne Dateien komprimieren, ohne diese vorher in ein Archiv zu stecken.

Gzip: Der Veteran

Grau ist alle Theorie, los geht es mit der Praxis. Am Anfang der Liste von gängigen Kompressionsformaten muss zwangsläufig Gzip stehen, denn das Programm ist ein echter Veteran. Der Name “Gzip” [3] steht für “GNU Zip”, es handelt sich also um eine Software des GNU-Projekts. Das Licht der Welt erblickte Gzip im Jahr 1992; gedacht war es als Ersatz für das compress-Format früherer Unix-Varianten, weil jenes patentrechtlich geschützt war und für die Nutzung Gebühren anfielen.

Gzip setzt auf den so genannten Deflate-Algorithmus [4], der Elemente von LZ77- (Lempel-Ziv 77) und Huffman-Kodierung kombiniert. Der Algorithmus gilt als nicht besonders effizient, ist dafür aber selbst auf langsamen Systemen relativ schnell. Außerdem war Gzip über lange Jahre der De-facto-Standard auf praktisch allen Linux-Distributionen: Die zugehörigen Programme (gzip zum Packen und gunzip zum Entpacken) gehören bis heute auf jeder Linux-Distribution zur Grundinstallation. Gzip tritt sowohl als Bezeichnung für das Programm wie auch als Name für das gzip-Dateiformat auf; letzteres begegnet Ihnen regelmäßig in Form von Dateien, deren Endung .gz ist. Gzip selbst enthält keine Archivfunktion, kann also nicht mehrere Dateien zu einer verbinden. Typischerweise kombiniert man Gzip deshalb mit Tar: Wenn Ihnen Dateien begegnen, deren Dateiendung .tar.gz oder auch .tgz lautet, handelt es sich um ein Tar-Archiv, das mit Gzip komprimiert wurde.

Um eine Datei auf der Kommandozeile mit gzip zu komprimieren, nutzen Sie den Befehl gzip Datei. Indem Sie dem Dateinamen noch die Option -9 voranstellen, erhöhen Sie den Grad der Kompression. Dann braucht Gzip zwar etwas länger, auf aktuellen Rechnern fällt das jedoch nicht ins Gewicht. Eine vorhandene .tar.gz-Datei lässt sich so möglicherweise noch stärker verkleinern: gunzip datei.tar.gz dekomprimiert die Datei, lässt das Tar-Archiv aber eingepackt. gzip -9 datei.tar führt danach die Kompression mit höherem Level durch. Alternativ greifen Sie zu einem der vielen GUIs für Gzip: Das KDE-Programm Ark kommt mit dem Format z. B. zurecht.

Der Ex-Kronprinz: Bzip2

Bzip2 [5] ist eine der moderneren Alternativen zu Gzip, konnte sich letztlich aber nicht flächendeckend durchsetzen. Die Entwicklung des Programms begann 1996. Julian Seward, der in der Open-Source-Welt auch für seine Mitarbeit an anderen Projekten wie Valgrind bekannt ist, veröffentlichte Bzip2 damals als Nachfolger von Bzip. Ähnlich wie beim compress-Programm war die Nutzung von Bzip aus Patentgründen eingeschränkt, Bzip2 hat kein solches Problem.

Bzip2 ist obendrein deutlich effizienter als Gzip: Die gleiche Datei mit Bzip2 komprimiert ist häufig rund 20% kleiner als ihre Gzip-gepackte Variante. Wie kommt es also, dass Bzip2 sich trotzdem nicht durchsetzen konnte? Gescheitert ist der Anwärter auf die Kompressionskrone vor allem an der Langsamkeit und den benötigten Ressourcen. Bzip2 ist im direkten Vergleich mit Gzip ausgesprochen langsam: Das Programm kombiniert mehrere Kompressionsalgorithmen miteinander und braucht sehr viel Zeit, um größere Dateien zu verkleinern. Obendrein ist seine Funktionsweise sehr CPU-intensiv: Auf den Rechnern der späten 90er- und frühen 2000er-Jahre war CPU-Leistung eben nicht im Überfluss vorhanden.

Die 2003 erschienene Variante pbzip2 (Parallel Bzip2) löste zumindest das Geschwindigkeitsproblem [6]. Denn pbzip2 konnte anders als sein Vorgänger die Performance-Vorteile nutzen, die sich aus dem Einsatz mehrerer CPUs oder CPU-Kerne ergeben. Immerhin: Bzip2 gehört mittlerweile ebenfalls zur Standardinstallation der meisten Linux-Distributionen. Die Kommandozeilenbefehle funktionieren ähnlich wie bei Gzip: bunzip2 entpackt eine mit Bzip2 komprimierte Datei, bzip2 komprimiert eine Datei. Bzip2-Dateien enden üblicherweise auf .bz2, komrpimierte Tar-Archive entsprechend auf .tar.bz2 oder .tbz2, und KDEs Ark kann auch diese Archive verarbeiten (Abbildung 2).

Abbildung 2: Der KDE-Kompressionsspezialist Ark beherrscht alle gängigen Formate wie Zip, Gzip und Bzip2.

Zip: Am Anfang war Windows

Das Zip-Format tritt als erstes Archivformat im Vergleich an; anders als bei Gzip oder Bzip2 handelt es sich nicht nur um einen Kompressionsalgorithmus. Das Format zeichnet sich durch große Verbreitung und allgemeine Verfügbarkeit aus. Allerdings hat das mit Linux wenig zu tun, denn Zip hat seine Domäne bis heute unter Windows und auf Apple-Rechnern mit OS X. Zip ist deutlich älter als Gzip oder Bzip2. Phil Katz legte den ersten Entwurf des Archivformats bereits 1989 vor, wobei er mit der Arbeit an Zip viel früher begonnen hatte. Die Geschichte hinter Zip hat gewisse Parallelen zu jener hinter Gzip oder Bzip2: Zip war ursprünglich als Alternative zum Arc-Format konzipiert, das in den frühen Tagen der Mailboxen (Bulletin Board Systems) – sehr populär war.

Arc war maßgeblich von der Firma SEA (System Enhancement Associates) entwickelt und vertrieben worden, wobei das sowohl auf das Format selbst als auch auf das gleichnamige Programm zutrifft. Phil Katz schrieb eine Alternative zum Arc-Programm und zog damit Ende der 80er den Zorn von SEA auf sich. Es folgte ein Rechtsstreit, in dem es um Copyright- und Markenrechte ging und an dessen Ende Phil Katz das Handtuch warf. Damals entbrannte eine Diskussion über offene Dateiformate, die auch heute noch aktuell ist.

Den Durchbruch schaffte das Zip-Format vor allem, weil auf Windows-Systemen in Form von WinZip (Abbildungen 3, 4) [7] schon früh ein leistungsfähiges (Ent)-Packprogramm zur Verfügung stand. WinZip ist in der IT-Szene mittlerweile legendär, weil das Programm zwar offiziell immer nur als Testversion verteilt worden ist; die Testphase war allerdings von unbegrenzter Länge. Für das simple Packen und Entpacken von Archiven war WinZip also ohne Einschränkungen nutzbar, und nicht wenige Anwender installierten auf neuen Computern zuerst WinZip und dann erst andere Programme. Microsoft baute native Unterstützung für das Zip-Format später in Windows ein, und auch OS X beherrscht den Umgang mit .zip-Dateien ab Werk. Da Zip als offenes Format gilt, ist das rechtlich wie technisch problemlos möglich.

Abbildung 3: WinZip ist ein kommerzielles Windows-Programm für das Zip-Format, alle aktuellen Betriebssysteme bearbeiten das Format aber ohne Hilfe durch externe Software.

Abbildung 4: Schon in den frühen 90er Jahren begann der Siegeszug von WinZip, das Bild zeigt die 1992 veröffentlichte Version im Windows-Emulator Wine.

Unter der Haube funktioniert Zip ähnlich wie die Kombination aus tar und gzip auf der Linux-Seite. Wie Gzip nutzt Zip den Deflate-Algorithmus, der ebenfalls als offener Standard dokumentiert ist. Entsprechend ähnlich sind die Resultate, die Zip und Gzip produzieren: In Sachen Effizienz gehört Zip sicher nicht zu den Meistern seines Fachs, aber die weite Verbreitung des Formats sowie die universelle Einsetzbarkeit des Formats gleichen das aus. Auf Linux-Systemen lassen sich Zip-Archive mit zip und unzip auf der Kommandozeile erstellen bzw. entpacken. Die gängigen Desktops wie KDE oder Gnome bringen obendrein grafische Packprogramme mit, die mit dem Zip-Format umgehen können.

Proprietär: Rar

Rar-Dateien sind wie Zip-Dateien Archive mit eingebauer Kompression. Das Rar-Format unterscheidet sich von allen anderen vorgestellten Formaten vor allem dadurch, dass es sich nicht um einen öffentlich dokumentierten Standard handelt. Rar ist ein kommerzielles Archivformat, dessen Nutzungsrechte von der deutschen win.rar GmbH verwaltet werden. Nutzer gibt es vorrangig auf Windows-basierten Plattformen, und auch die Standardimplementierung des Rar-Formats, WinRar (Abbildung 5), ist ein Windows-Programm [8]. Unter der Haube werkelt ein Wörterbuch-Algorithmus auf Basis von LZSS (Lempel-Ziv-Storer-Szymanski) [9], in Sachen Effizienz unterscheidet Rar sich nicht maßgeblich von anderen Archivformaten mit Kompression.

Abbildung 5: WinRar ist unter Windows das Standardtool für Rar-Archive. Für Linux gibt es Kommandozeilentools.

Freunde freier Software raten jedenfalls von der Benutzung des Rar-Formats ab, da es sich um keinen offenen Standard handelt. Immerhin: Neben Windows stehen Rar-Tools auch für OS X und Linux zur Verfügung, unrar und rar bieten zumindest auf der Kommandozeile die Möglichkeit, vorhandene .rar-Archive (so die typische Dateiendung) zu entpacken oder eigene zu erstellen.

Der Senkrechtstarter: LZMA

Besonders in den letzten Jahren hat sich der letzte Proband im Vergleich eine breite Nutzerbasis aufgebaut: Das LZMA-Kompressionsformat [10] stößt auf immer größeren Zuspruch bei Nutzern und Entwicklern. Seit einigen Monaten stellt Linus Torvalds etwa die offiziellen Quelltextarchive des Linux-Kernels auch im LZMA-Format zur Verfügung. Die übliche Dateiendung für solche Dateien lautet .xz. Wer nicht nur den Kompressionsalgorithmus nutzen möchte, sondern auch ein passendes Archivformat benötigt, setzt auf 7-Zip [11]: Davon erzeugte Dateien mit der Endung .7z tauchen immer häufiger auf.

Das Kompressionsformat LZMA und das dazu gehörende Archivformat 7z sind der letzte Schrei in Sachen Kompression: Selbst im direkten Vergleich mit Bzip2, das bisher als das effizienteste Kompressionsverfahren galt, ist LZMA ausgesprochen potent und verkleinert die ursprünglichen Dateien deutlich stärker. Die Entwicklung von LZMA begann bereits 1996. Dass sich das Format erst in letzter Zeit verstärkt durchsetzen konnte, ist seiner Komplexität geschuldet: LZMA ist die Abkürzung für “Lempel-Ziv-Markov Chain Algorithm”. Im Vergleich mit dem Deflate-Algorithmus oder dem Burrows-Wheeler-Algorithmus von Bzip2 benötigt LZMA besonders viel Rechenleistung.

Beachtung verdient auch das Archivformat 7p, das zusammen mit LZMA üblicherweise genutzt wird. Die Referenzimplementierung von 7z ist 7-Zip von Igor Pavlov, das in einer öffentlich verfügbaren Version erstmals 1999 vorlag. 7z-Archive sind nicht fix an den LZMA-Algorithmus gekoppelt. Dieser ist zwar die Standardwahl, wenn Sie als Nutzer keinen anderen Algorithmus angeben. Grundsätzlich kommt 7z aber auch mit dem Bzip2-Algorithmus oder Deflate zurecht, womit automatisch Kompatibilität zu Bzip2, Gzip und Zip gegeben ist. Sowohl der LZMA-Algorithmus selbst als auch das Archivformat 7z und das Archivprogramm 7-Zip stehen unter einer freien GNU-Lizenz. Wer einen aktuellen Rechner besitzt, kann das Format etwa mit dem KDE-Archivmanager Ark verwenden (wenn das Paket p7zip installiert ist).

Auf der Kommandozeile steht das Werkzeug xz zur Verfügung, um einzelne Dateien mit LZMA zu komprimieren, 7z verarbeitet 7-Zip-Archive.

Der direkte Vergleich

Nachdem Sie nun einen grundlegenden Überblick über die einzelnen Archivformate und Kompressionsverfahren haben, fragen Sie sich vielleicht, welches Format für welchen Einsatzzweck das bessere ist. Ein einfacher Test für die Effizienz der Kompressionsformate steht Ihnen im Grunde bereits zur Verfügung: Der Quelltext des Linux-Kernels ist auf der Kernel-Website [12] samt Größenangaben zum Download verfügbar. Die Kernel-Entwickler bieten den Kernel als Tar-Archiv an, als Kompressionsverfahren kommt wahlweise Gzip oder LZMA zum Einsatz. Der Linux-Kernel 4.2 belegt als Gzip-Tarball 124 MByte Speicher, beim LZMA-Tarball sinkt der Speicherbedarf auf 82 MByte. Das ursprüngliche Tar-Archiv ist dabei 602 MByte groß.

Gzip führt also zu einer Reduktion der Dateigröße von fast 79%. LZMA bringt es auf beachtliche 86%. Ein spontaner Test mit dem gleichen Tarball und bzip2 führte zu einer Dateigröße von 98 MByte, schlägt also Gzip, ist aber LZMA unterlegen. Der sichere Sieger in Sachen Geschwindigkeit ist hingegen eindeutig Gzip: Das Komprimieren der 602*MByte großen Datei dauert ca. 42 Sekunden. Bzip2 braucht eine Minute und drei Sekunden. Die Kompression mit xz ins LZMA-Format dauert sogar fast sechs Minuten und sorgte auf dem Test-Laptop dafür, dass zwischenzeitlich der CPU-Lüfter ansprang (Abbildung 6).

Abbildung 6: LZMA (xz) komprimiert mit Abstand am besten, braucht dafür aber fast sechsmal so lang wie Bzip2 oder Gzip.

Der Quelltext des Linux-Kernels ist hilfreich, um die Zahlen beim Komprimieren von meist textbasiertem Inhalt zu dokumentieren. Ein realistisches Alltagsszenario ist das aber nicht, schließlich werden regelmäßig auch Bilder und Dateien anderen Typs Bestandteil von komprimierten Archiven sein. Ein realistischeres Szenario ist also ein Ordner mit Inhalten verschiedenen Typs, im Beispiel ein Verzeichnis mit einer ursprünglichen Größe von ca. 400 MByte. Hier lagen die Probanden näher beieinander, im Wesentlichen bestätigte der Test aber die Erkenntnisse des vorherigen Tests mit dem Kernel-Quellcode. 7z ging klar in Führung und sorgte für ein rund 250 MByte großes Archiv, brauchte aber auch mit Abstand am längsten. Die Reduktion betrug mithin rund 38%. Der deutlich schlechtere Wert im Vergleich mit dem Kernel-Quelltext ist dadurch zu erklären, dass im Testordner auch Bilder und kleine Videodateien lagen, die bereits verlustbehaftet komprimiert waren. Der Spielraum nach unten ist gerade bei schon komprimierten Videos und Bildern eher gering.

Bzip2, Gzip und Winzip komprimierten schlechter und schneller mit nur geringen Unterschieden zwischen den drei Tools. Die effizientesten Komprimierer brauchten auch hier für ihre Arbeit am längsten.

Fazit

Die Rangfolge in Sachen Kompressionsleistung ist klar: Wer einen modernen Rechner hat und kein Problem darin sieht, auf die Kompression eines Archivs oder einer einzelnen Datei ein wenig zu warten, erreicht mit LZMA die besten Resultate. Wenn es schnell gehen muss, sind das Zip-Format und Gzip geeignete Alternativen, die aber deutlich schlechter komprimieren. Den idealen Kompressionsalgorithmus für spezifische Dateitypen gibt es indes nicht. Ein realistisches Kriterium für die Auswahl eines Algorithmus sollte eher die Verfügbarkeit auf einzelnen Plattformen sein. Zip-Dateien unterstützt Windows seit Windows XP nativ, Formate wie Gzip oder Bzip2 setzen dort die Installation von WinZip voraus. OS X und Linux kommen hingegen mit allen vorgestellten Formaten problemlos klar. Rar-Archive sollten Sie nach Möglichkeit vermeiden, weil Sie unter Windows und OS X spezielle Zusatzsoftware zum Handling der Archive benötigen – und genug freie Alternativen verfügbar sind.