ZIP-Dateiformat

ZIP
Dateiendung:	.zip
MIME-Type:	application/zip
Magische Zahl:	504B.0304 hex PK\x03\x04 (ASCII-C-Notation)
Entwickelt von:	Phil Katz
Art:	Datenkompression
Container für:	beliebige Dateien
Standard(s):	PKWARE/IANA

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

→ Hauptartikel: Containerdatei

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.

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	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.

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

Siehe auch

• Liste von Datenkompressionsprogrammen

Weblinks

• PKWARE: .ZIP File Format Specification, 1. Oktober 2014 (englisch)
• Spezifikation zur AES-Verschlüsselung in Zip-Formaten
• zlib Technical Details (englisch)
• P. Deutsch, J-L. Gailly: RFC: 1950 – ZLIB Compressed Data Format Specification version 3.3. Mai 1996 (englisch).
• Jahr 2038 Jahr-2038-Problem