Das ZIP-Dateiformat (von ‚Reißverschluss‘) ist ein freies und quelloffenes Format für verlustfrei komprimierte Dateien, das einerseits den Platzbedarf bei der Archivierung reduziert und andererseits als Containerdatei fungiert, in der mehrere zusammengehörige Dateien oder auch ganze Verzeichnisbäume zusammengefasst werden können.Die Dateiendung für zip-archivierte Dateien ist .zip. Der MIME-Typ ist application/zip.
Geschichte
Das ZIP-Format wurde ursprünglich 1989 mit den Programmen PKZIP (komprimieren) und PKUNZIP (dekomprimieren) vom US-Amerikaner Phil Katz entwickelt und hat in der Zwischenzeit einige Erweiterungen erfahren. Katz hatte ursprünglich ein anderes Dateiformat (ARC) benutzt. Dieses Format war von Software Enhancements Associates (SEA) entwickelt worden und wurde als Shareware vertrieben. Katz schrieb eine eigene, deutlich schnellere Version dieser Software und verbreitete sie als PKARC. Als ihn daraufhin SEA verklagte, zog er PKARC zurück und entwickelte stattdessen PKZIP, das einen effizienteren Algorithmus benutzte. Durch die schnelle Verbreitung von PKZIP wurden SEA und ARC bedeutungslos.
Seit 2015 ist ZIP auch als ISO/IEC 21320-1:2015 standardisiert.
Merkmale
Container
Das ZIP-Format ist zunächst ein Datencontainer, in den mehrere Dateien komprimiert oder unkomprimiert gespeichert und auch einzeln entkomprimiert (extrahiert) werden können. Darüber hinaus ermöglicht das Format auch das Mitspeichern des dazugehörigen Speicherort-Pfads. Auch eine Verschlüsselung der ansonsten lediglich komprimierten Dateien mit einem Passwort ist möglich.
Keine progressive Kompression
Das ZIP-Format unterstützt keine progressive Kompression (auch genannt), die Dateien werden einzeln komprimiert. Das ermöglicht einerseits eine flexible Handhabung (Löschen/Hinzufügen von Dateien aus dem Archiv, ohne alles neu komprimieren zu müssen; Extraktion einzelner Dateien ohne vorangehende Dateien dekomprimieren zu müssen), hat aber den Nachteil, dass Redundanzen zwischen den Dateien bei der Komprimierung nicht berücksichtigt werden können. Dieser Nachteil kann umgangen werden, indem die Dateien zunächst unkomprimiert archiviert werden und die so erzeugte Zip-Datei in eine weitere komprimiert gespeichert wird (meist nur bei sehr vielen gleichartigen Dateien sinnvoll).
Nicht-sequenzielles Format
Die Dateien sind als Dateieinträge () in beliebiger Reihenfolge gespeichert. Die Dateieinträge beginnen alle mit einem lokalen Dateikopf (), der den Dateieintrag beschreibt und den Datenabschnitt mit den effektiven Inhalten einleitet. Um die Handhabung dieser beliebig angeordneten Einträge zu gewährleisten, befindet sich am Ende der Zip-Datei jeweils ein zentrales Verzeichnis (), welches sämtliche Dateieinträge anhand der lokalen Dateiköpfe referenziert. Die Reihenfolge der Dateieinträge und der entsprechenden Referenzen im zentralen Verzeichnis können sich voneinander unterscheiden. Es handelt sich also um eine nicht-sequenzielle Struktur, die am besten mit dem Konzept des wahlfreien Zugriffs () beschrieben werden kann.
Dieses nicht-sequenzielle Format bewirkt andererseits aber auch, dass, im Gegensatz zum seit 1977 üblichen und seit 1988 standardisierten Tar-Format, unvollständige oder im hinteren Teil defekte Archive gar nicht entpackt werden können.
mini|Struktur einer Zip-Datei
Multivolume
Es ist weiterhin möglich, das Archiv auf mehrere Dateien zu verteilen (zum Beispiel um große Dateien in Stücke zu teilen, die jeweils auf eine CD oder DVD passen).
Packalgorithmen
Neben der bis zur PKZip-Version 2.x am besten packenden Methode Deflate unterstützt ZIP noch eine Reihe weiterer Kompressionsalgorithmen:
Methode Kurztext Kommentar 0 Store Die Datei wird ohne Kompression gespeichert. 1 UnShrinking Dynamischer Lempel-Ziv-Welch-Algorithmus 2 Expanding – Kompressionsstufe 1 3 Expanding – Kompressionsstufe 2 4 Expanding – Kompressionsstufe 3 5 Expanding – Kompressionsstufe 4 6 Imploding 7 Tokenization 8 Deflating LZSS und Huffman-Entropiekodierung 9 Enhanced Deflating (DEFLATE64) 10 PKWARE Data Compression Library Imploding (ehemals IBM TERSE) 11 reserviert 12 Bzip2 13 reserviert 14 LZMApkware.cachefly.netwinzip.com Lempel-Ziv-Markow-Algorithmus 15 reserviert 16 reserviert 17 reserviert 18 IBM TERSE (neu) 19 IBM LZ77 z Architecture (PFS) 20 Zstandard Compression (2020) pkzip 6.3.7 -> deprecated (use method 93 for zstd) 92 Reference Compression (2020) Erweiterung ab Winzip 25https://www.winzip.com/en/support/compression-methods/ 93 Zstandard Compression (2020) Wechsel zu 93 von 20 mit pkzip 6.3.8https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.8.TXT, ab Winzip 24 94 MP3 Compression (2016) ab Winzip 21 95 Xz (LZMA2) 1.0.4 Erweiterung durch WinZIP 18.0 (November 2013)kb.winzip.comwinzip.com 96 JPEG Compressionimagewz.winzip.com (PDF) Erweiterung durch WinZIP 12.0 (September 2008)winzip.com 97 WavPack Erweiterung durch WinZIP 11.0 Beta (Oktober 2006)winzip.com 98 PPMd Version 1, rev 1 Erweiterung durch WinZIP 10.0 Beta (August 2005)winzip.com 99 AES-verschlüsselt Erweiterung durch WinZIPwinzip.com
Aufbau Eine ZIP-Datei wird korrekt durch das Vorhandensein eines Eintrags am Ende des zentralen Dateiverzeichnisses identifiziert, der sich am Ende der Archivstruktur befindet, um das einfache Anhängen neuer Dateien zu ermöglichen. Wenn der Eintrag am Ende des zentralen Verzeichnisses ein nicht leeres Archiv anzeigt, sollte der Name jeder Datei oder jedes Verzeichnisses innerhalb des Archivs in einem Eintrag im zentralen Verzeichnis angegeben werden, zusammen mit anderen Metadaten über den Eintrag und einem Offset in der ZIP-Datei, der auf die tatsächlichen Eintragsdaten verweist.
Dadurch kann eine Auflistung der Dateien eines ZIP-Archivs relativ schnell durchgeführt werden, da nicht das gesamte Archiv gelesen werden muss, um die Dateiliste anzuzeigen. Die Einträge in der ZIP-Datei enthalten diese Informationen aus Redundanzgründen auch in einem lokalen Dateikopf (engl. file header). Weil an ZIP-Dateien komprimierte Daten angehängt werden können, sind nur Dateien gültig, die im zentralen Verzeichnis am Ende der Datei angegeben sind. Das Scannen einer ZIP-Datei nach lokalen Dateiköpfen ist außer im Fall beschädigter Archive ungültig, weil das zentrale Archivverzeichnis erklären kann, dass einige Dateien gelöscht und andere Dateien aktualisiert wurden.
Beispiel
Beginnen wir mit einer ZIP-Datei, die die Dateien A, B und C enthält. Erst wird Datei B gelöscht und dann gelöscht und dann wird C aktualisiert. Dies kann erreicht werden, indem einfach eine neue Datei C an das Ende der ursprünglichen ZIP-Datei angehängt und ein neues zentrales Dateiverzeichnis hinzugefügt wird, das nur Datei A und die neue Datei C auflistet.
Die Reihenfolge der Dateieinträge im zentralen Verzeichnis muss nicht mit der Reihenfolge der Dateieinträge im Archiv übereinstimmen. Jeder in einem ZIP-Archiv gespeicherte Eintrag wird durch einen lokalen Dateikopf mit Informationen über die Datei wie Kommentar, Dateigröße und Dateiname eingeleitet, gefolgt von optionalen zusätzlichen Datenfeldern und dann den möglicherweise komprimierten, möglicherweise verschlüsselten Dateidaten. Die zusätzlichen Datenfelder sind der Schlüssel zur Erweiterbarkeit des ZIP-Formats. Zusätzliche Felder werden genutzt, um das ZIP64-Format, mit WinZip kompatible Verschlüsselung nach dem Advanced Encryption Standard (AES), Dateiattribute und höher aufgelöste NTFS- oder Unix-Dateizeitstempel zu unterstützen. Andere Erweiterungen sind über das zusätzliche Feld möglich.
Software, die ZIP-Archive lesen, erzeugen oder verändern kann, muss gemäß der Spezifikation zusätzliche Felder ignorieren, die sie nicht erkennen. Das ZIP-Format verwendet spezifische 4-Byte-Signaturen, um die verschiedenen Strukturen in der Datei zu kennzeichnen. Jeder Dateieintrag ist durch eine spezifische Signatur gekennzeichnet. Das Ende des zentralen Verzeichnisdatensatzes wird mit seiner spezifischen Signatur angezeigt, und jeder Eintrag im zentralen Verzeichnis beginnt mit der 4-Byte-Signatur des zentralen Dateikopfs. In der ZIP-Spezifikation gibt es keine Markierung für Beginning of File oder End of File. Normalerweise ist das erste Element in einer ZIP-Datei ein ZIP-Eintrag, der leicht anhand seiner lokalen Dateikopfsignatur identifiziert werden kann. Dies ist jedoch nicht unbedingt der Fall, da dies von der ZIP-Spezifikation nicht gefordert wird. Insbesondere beginnt ein selbstextrahierendes Archiv mit einem ausführbaren Dateikopf. Tools, die ZIP-Archive korrekt lesen, müssen nach der Signatur des Endes des zentralen Verzeichnisdatensatzes und dann, falls zutreffend, nach den anderen angegebenen zentralen Verzeichnisdatensätzen suchen. Sie dürfen nicht nach Einträgen vom Anfang der ZIP-Datei suchen, weil nur das zentrale Verzeichnis angibt, wo ein Dateiblock beginnt und dass er nicht gelöscht wurde. Das Scannen könnte zu falschen Positivergebnissen führen, da das Format weder verbietet, dass sich andere Daten zwischen den Blöcken befinden, noch dass Dateidatenströme solche Signaturen enthalten. Tools, die versuchen, Daten aus beschädigten ZIP-Archiven wiederherzustellen, werden das Archiv jedoch höchstwahrscheinlich nach lokalen Dateikopfsignaturen durchsuchen. Dies wird dadurch erschwert, dass die komprimierte Größe eines Dateiblocks nach dem Dateiblock gespeichert werden kann, was die sequentielle Verarbeitung erschwert.
Die ZIP-Spezifikation unterstützt auch das Verteilen von Archiven auf mehrere Dateisystemdateien. Diese Funktion wird zum Versenden von ZIP-Archiven in Teilen per E-Mail, Wechseldatenträger oder andere Wege der Datenübertragung verwendet.
Alle ZIP-Dateien enthalten drei Abschnitte:Algorithms in the Real World - Understanding the Zip Format
local file record (lokaler Dateieintrag) central directory record (zentraler Verzeichniseintrag) end of central directory record (Ende des zentralen Verzeichniseintrags)
Local file record Feldname Länge Beschreibung local file signature 4 Byte0x04034b50 extract version 2 Byte20 general purpose flag 2 Byte0 compression method 2 Byte0: keine, 8: Deflate last mod file time 2 Byte0 last mod file date 2 Byte0 crc-32 4 Byte0xdeadbeef compressed file size 4 Byteinterpretiert als vorzeichenloses 32-Bit-Integer uncompressed file size 4 Byteinterpretiert als vorzeichenloses 32-Bit-Integer file name length 2 Byteinterpretiert als vorzeichenloses 16-Bit-Integer extra field length 2 Byte0 file name variabelDateiname als ASCII String extra field variabeldieses Feld überspringen file data variabel
Central directory record Feldname Länge Beschreibung central directory signature 4 Byte0x02014b50 specification version 1 Byte30 made by 1 Byte65 extract version 2 Byte20 general purpose bit flag 2 Byte0 compression method 2 Byte0: keine, 8: Deflate last mod file time 2 Byte0 last mod file date 2 Byte0 crc-32 4 Byte0xdeadbeef compressed file size 4 Byteinterpretiert als vorzeichenloses 32-Bit-Integer uncompressed file size 4 Byteinterpretiert als vorzeichenloses 32-Bit-Integer file name length 2 Byteinterpretiert als vorzeichenloses 16-Bit-Integer extra field length 2 Byte0 file comment length 2 Byte0disk number start2 Byte0internal file attributes2 Byte1external file attributes4 Byte1offset of local header4 Byte0file namevariabelDateiname als ASCII Stringextra fieldvariabeldieses Feld überspringenfile commentvariabeldieses Feld überspringen
End of central directory record Feldname Länge Beschreibung end of central dir signature 4 Byte0x06054b50 number of this disk 2 Byte0 number of the start disk 2 Byte0 total number of entries on this disk 2 Byte1 total number of entries 2 Byte1 size of the central directory record 4 Byteinterpretiert als vorzeichenloses 32-Bit-Integer offset of start of central directory 4 Byteinterpretiert als vorzeichenloses 32-Bit-Integer .ZIP file comment length 2 Byte0 .ZIP file comment variabeldieses Feld überspringen
Erweiterungen