# ZIP-Dateiformat

Das ZIP-Dateiformat (von englisch zipper ‚Reißverschluss‘) ist ein 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 englisch solid 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 (englisch file entries) in beliebiger Reihenfolge gespeichert. Die Dateieinträge beginnen alle mit einem lokalen Dateikopf (englisch local header), 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 (englisch central directory), 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 (englisch random access) 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.

### 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 | LZMA | 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 25 |
| 93 | Zstandard Compression | (2020) Wechsel zu 93 von 20 mit pkzip 6.3.8, ab Winzip 24 |
| 94 | MP3 Compression | (2016) ab Winzip 21 |
| 95 | Xz (LZMA2) 1.0.4 | Erweiterung durch WinZIP 18.0 (November 2013) |
| 96 | JPEG Compression | Erweiterung durch WinZIP 12.0 (September 2008) |
| 97 | WavPack | Erweiterung durch WinZIP 11.0 Beta (Oktober 2006) |
| 98 | PPMd Version 1, rev 1 | Erweiterung durch WinZIP 10.0 Beta (August 2005) |
| 99 | AES-verschlüsselt | Erweiterung durch WinZIP |

### 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:
* 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 Byte | 0x04034b50 |
| extract version | 2 Byte | 20 |
| general purpose flag | 2 Byte | 0 |
| compression method | 2 Byte | 0: keine, 8: Deflate |
| last mod file time | 2 Byte | 0 |
| last mod file date | 2 Byte | 0 |
| crc-32 | 4 Byte | 0xdeadbeef |
| compressed file size | 4 Byte | interpretiert als vorzeichenloses 32-Bit-Integer |
| uncompressed file size | 4 Byte | interpretiert als vorzeichenloses 32-Bit-Integer |
| file name length | 2 Byte | interpretiert als vorzeichenloses 16-Bit-Integer |
| extra field length | 2 Byte | 0 |
| file name | variablel | Dateiname als ASCII String |
| extra field | variablel | dieses Feld überspringen |
| file data | variablel | |

#### Central directory record

| Feldname | Länge | Beschreibung |
| central directory signature | 4 Byte | 0x04034b50 |
| specification version | 1 Byte | 30 |
| made by | 1 Byte | 65 |
| extract version | 2 Byte | 20 |
| general purpose bit flag | 2 Byte | 0 |
| compression method | 2 Byte | 0: keine, 8: Deflate |
| last mod file time | 2 Byte | 0 |
| last mod file date | 2 Byte | 0 |
| crc-32 | 4 Byte | 0xdeadbeef |
| compressed file size | 4 Byte | interpretiert als vorzeichenloses 32-Bit-Integer |
| uncompressed file size | 4 Byte | interpretiert als vorzeichenloses 32-Bit-Integer |
| file name length | 2 Byte | interpretiert als vorzeichenloses 16-Bit-Integer |
| extra field length | 2 Byte | 0 |
| file comment length | 2 Byte | 0 |
| disk number start | 2 Byte | 0 |
| internal file attributes | 2 Byte | 1 |
| external file attributes | 4 Byte | 1 |
| offset of local header | 4 Byte | 0 |
| file name | variablel | Dateiname als ASCII String |
| extra field | variablel | dieses Feld überspringen |
| file comment | variablel | dieses Feld überspringen |

#### End of central directory record

| Feldname | Länge | Beschreibung |
| end of central dir signature | 4 Byte | 0x04034b50 |
| number of this disk | 2 Byte | 0 |
| number of the start disk | 2 Byte | 0 |
| total number of entries on this disk | 2 Byte | 1 |
| total number of entries | 2 Byte | 1 |
| size of the central directory record | 4 Byte | interpretiert als vorzeichenloses 32-Bit-Integer |
| offset of start of central directory | 4 Byte | interpretiert als vorzeichenloses 32-Bit-Integer |
| .ZIP file comment length | 2 Byte | 0 |
| .ZIP file comment | variablel | dieses Feld überspringen |

### Erweiterungen

Es existieren mittlerweile nachträglich eingeführte Erweiterungen wie die Zip128-Erweiterung.
Das ZIP-Dateiformat ermöglicht einen Kommentar mit bis zu 65535 Bytes Daten am Ende der Datei nach dem zentralen Verzeichnis. Weil das zentrale Verzeichnis den Offset jeder Datei im Archiv in Bezug auf den Start angibt, ist es außerdem möglich, dass der erste Dateieintrag bei einem anderen Offset als Null beginnt, obwohl einige Tools möglicherweise keine Archivdateien verarbeiten, die nicht mit einem Dateieintrag bei Offset Null beginnen. gzip kann beispielsweise einen Eintrag aus einer ZIP-Datei extrahieren, wenn dieser bei Offset Null liegt. Dadurch können beliebige Daten sowohl vor als auch nach den ZIP-Archivdaten in der Datei vorkommen und das Archiv kann weiterhin von einer ZIP-Anwendung gelesen werden. Ein Nebeneffekt davon ist, dass es möglich ist, eine Datei zu erstellen, die sowohl ein funktionierendes ZIP-Archiv als auch ein anderes Format ist, vorausgesetzt, das andere Format toleriert beliebige Daten am Ende, am Anfang oder in der Mitte. Selbstextrahierende Archive (SFX) in der von WinZip unterstützten Form nutzen dies aus, da es sich dabei um ausführbare Dateien handelt, die der PKZIP AppNote.txt-Spezifikation entsprechen und von kompatiblen Zip Tools oder Bibliotheken gelesen werden können. Diese Eigenschaft des ZIP-Formats und des JAR-Formats, einer Variante von ZIP, kann ausgenutzt werden, um betrügerische Inhalte wie schädliche Java-Klassen in einer scheinbar harmlosen Datei zu verbergen, beispielsweise einem ins Internet hochgeladenen GIF-Bild.

## Verbreitung, Bedeutung

Das Dateiformat und das Kompressionsverfahren Deflate sind Public Domain und erlangten unter anderem dadurch eine weltweite Verbreitung und Bedeutung.
Die Deflate-Methode findet sich als Quasi-Standard in zahlreichen weiteren Formaten, wie den Bilddateiformaten Portable Network Graphics (PNG) und Tagged Image File Format (TIFF), dem OpenDocument- und dem Office-Open-XML-Format der ISO wieder.

## Programme

Neben PKZIP existieren zahlreiche andere Programme, die dieses Dateiformat bearbeiten können. Dazu zählen freie Programme wie Info-ZIP, PeaZip, Xarchiver oder 7-Zip, dessen optimierter Deflate-Algorithmus obendrein geringfügig kleinere PKZIP-2.xx-kompatible Dateien erzeugen kann. Ferner existieren kommerzielle Programme, wie WinRAR oder WinZip.
Programm- und Klassenbibliotheken für den Zugriff auf ZIP-Dateien stehen für zahlreiche Programmiersprachen zur Verfügung. So enthält beispielsweise die Java Platform, Standard Edition (Java SE) seit 1997 (Version 1.1) das Paket „java.util.zip“ mit entsprechenden Klassen für Komprimierung und Dekomprimierung. Weiter gibt es die Klassenbibliothek Zip64File, welche ZIP-Dateien als sogenannte Direktzugriffsdateien (englisch random access files) handhaben kann. Zip64File steht der Öffentlichkeit vollumfänglich, kostenfrei und inklusive Quellcode zur Verfügung.
Das im System macOS integrierte Programm BOMArchiveHelper erzeugt und dekomprimiert ebenfalls im ZIP-Format. Auch der Datei-Explorer unter Windows ist in der Lage, ZIP-Dateien zu packen und zu entpacken, sodass hier in der Regel keine weitere Software installiert werden muss. Aus lizenzrechtlichen Gründen durfte die Implementierung in Windows nicht in der Lage sein, programmierbar benutzt werden zu können.

## Namensgebung

Nach Auskunft der Firma PKWare bezieht sich der Name zip (englisch für Reißverschluss) auf das Verpacken von vielen Einzeldateien in einen größeren Container und nicht auf die Komprimierungsfunktion des Programms.
Nicht jedes Kompressionsprogramm, dessen Name die Zeichenkette „ZIP“ enthält, arbeitet mit dem ZIP-Dateiformat. Die wichtigsten Beispiele sind gzip vom GNU-Projekt und bzip2, die jeweils in einem eigenständigen Format nur eine einzelne Datei komprimieren. Zum Archivieren mehrerer Dateien muss in diesem Fall vor der Komprimierung ein anderes Programm verwendet werden (im Zusammenhang mit gzip und bzip2 meist tar). Auch bei 7-Zip wird zwar das ZIP-Dateiformat voll unterstützt, aber das eigene Archivformat 7z ist nicht mit ZIP kompatibel.
WinZip führte mit Version 12.1 die Erweiterung zipx des ZIP-Formats ein, die die Verwendung neuerer Kompressionsmethoden als DEFLATE, insbesondere BZip, LZMA, PPMd, Jpeg and Wavpack, kennzeichnet.
Das Wort „zippen“ wird gelegentlich als Deonym für „komprimiert archivieren“ verwendet, jedoch muss dabei nicht zwangsläufig das Packen als Zip-Datei gemeint sein.

## ZIP-Komprimierung in anderen Datei-Formaten

Bei folgenden Dateiformaten handelt es sich um ZIP-Dateien, in denen sich allerdings bestimmte Dateien befinden müssen:
* Java Archive (JAR) – ein auf Zip basierendes Format für Java-Programmdaten
* Android Package (APK) – ähnlich wie JAR-Dateien jedoch für Android
* OpenDocument (ODF) – das unter anderem von Apache OpenOffice verwendete Dateiformat ist ein auf mehrere XML-Dateien aufbauendes Format, welches mithilfe von Zip zu einzelnen Dateien komprimiert wird
* Office Open XML von Microsoft Office enthält ebenfalls ZIP-komprimierte XML-Dateien
* EPUB – E-Book-Dateiformat