.ZIP-Dateien sind Archive, die mehrere Dateien speichern. ZIP ermöglicht die Komprimierung der enthaltenen Dateien mit vielen verschiedenen Methoden sowie die einfache Speicherung einer Datei, ohne sie zu komprimieren. Jede Datei wird separat gespeichert, so dass verschiedene Dateien im selben Archiv mit unterschiedlichen Methoden komprimiert werden können. Da die Dateien in einem ZIP-Archiv einzeln komprimiert werden, ist es möglich, sie zu extrahieren oder neue Dateien hinzuzufügen, ohne das gesamte Archiv zu komprimieren oder zu dekomprimieren. Dies steht im Gegensatz zum Format von komprimierten tar-Dateien, bei denen eine solche Verarbeitung mit wahlfreiem Zugriff nicht ohne weiteres möglich ist.
Am Ende einer ZIP-Datei wird ein Verzeichnis eingefügt. Dieses gibt an, welche Dateien im ZIP enthalten sind und wo im ZIP sich die jeweilige Datei befindet. Dadurch können ZIP-Leser die Liste der Dateien laden, ohne das gesamte ZIP-Archiv zu lesen. ZIP-Archive können auch zusätzliche Daten enthalten, die nicht mit dem ZIP-Archiv zusammenhängen. So kann ein ZIP-Archiv zu einem selbstextrahierenden Archiv gemacht werden (eine Anwendung, die die enthaltenen Daten dekomprimiert), indem der Programmcode einem ZIP-Archiv vorangestellt und die Datei als ausführbar gekennzeichnet wird. Die Speicherung des Katalogs am Ende ermöglicht es auch, eine gezippte Datei zu verstecken, indem sie an eine harmlose Datei, wie z. B. eine GIF-Bilddatei, angehängt wird.
Das ZIP-Format verwendet einen 32-Bit-CRC-Algorithmus und enthält zwei Kopien der Verzeichnisstruktur des Archivs, um einen größeren Schutz gegen Datenverlust zu bieten.
StructureEdit
Eine ZIP-Datei wird durch das Vorhandensein eines End-of-Central-Directory-Records korrekt identifiziert, der sich am Ende der Archivstruktur befindet, um das einfache Anhängen neuer Dateien zu ermöglichen. Wenn das Ende des zentralen Verzeichniseintrags auf ein nicht leeres Archiv hinweist, sollte der Name jeder Datei oder jedes Verzeichnisses innerhalb des Archivs in einem zentralen Verzeichniseintrag angegeben werden, zusammen mit anderen Metadaten über den Eintrag und einem Offset in der ZIP-Datei, der auf die eigentlichen Eintragsdaten verweist. Auf diese Weise kann eine Dateiliste des Archivs relativ schnell erstellt werden, da nicht das gesamte Archiv gelesen werden muss, um die Liste der Dateien anzuzeigen. Die Einträge innerhalb der ZIP-Datei enthalten diese Informationen zur Redundanz auch in einem lokalen Dateikopf. Da an ZIP-Dateien Anhänge angefügt werden können, sind nur die im zentralen Verzeichnis am Ende der Datei angegebenen Dateien gültig. Das Durchsuchen einer ZIP-Datei nach lokalen Dateikopfzeilen ist ungültig (außer bei beschädigten Archiven), da das zentrale Verzeichnis angeben kann, dass einige Dateien gelöscht und andere Dateien aktualisiert wurden.
Beispielsweise können wir mit einer ZIP-Datei beginnen, die die Dateien A, B und C enthält. Dazu wird einfach eine neue Datei C an das Ende der ursprünglichen ZIP-Datei angehängt und ein neues zentrales Verzeichnis hinzugefügt, das nur die Datei A und die neue Datei C enthält. Als ZIP entwickelt wurde, war die Übertragung von Dateien per Diskette üblich, doch das Schreiben auf Disketten war sehr zeitaufwändig. Wenn man eine große ZIP-Datei hatte, die sich möglicherweise über mehrere Disketten erstreckte, und nur einige wenige Dateien aktualisieren musste, war es wesentlich schneller, nur das alte zentrale Verzeichnis zu lesen, die neuen Dateien anzuhängen und dann ein aktualisiertes zentrales Verzeichnis anzuhängen, anstatt alle Dateien zu lesen und neu zu schreiben.
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 „Extra“-Datenfeldern und dann den möglicherweise komprimierten, möglicherweise verschlüsselten Dateidaten. Die „Extra“-Datenfelder sind der Schlüssel zur Erweiterbarkeit des ZIP-Formats. „Extra“-Felder werden zur Unterstützung des ZIP64-Formats, der WinZip-kompatiblen AES-Verschlüsselung, von Dateiattributen und höher aufgelösten NTFS- oder Unix-Datei-Zeitstempeln genutzt. Andere Erweiterungen sind über das „Extra“-Feld möglich. ZIP-Tools sind gemäß der Spezifikation verpflichtet, Extra-Felder, die sie nicht kennen, zu ignorieren.
Das ZIP-Format verwendet spezifische 4-Byte-„Signaturen“, um die verschiedenen Strukturen in der Datei zu kennzeichnen. Jeder Dateieintrag wird durch eine bestimmte Signatur gekennzeichnet. Das Ende des zentralen Verzeichnisdatensatzes wird mit einer spezifischen Signatur gekennzeichnet, und jeder Eintrag im zentralen Verzeichnis beginnt mit der 4-Byte-Signatur des zentralen Datei-Headers.
In der ZIP-Spezifikation gibt es keine BOF- oder EOF-Markierung. Konventionell ist der erste Teil einer ZIP-Datei ein ZIP-Eintrag, der leicht durch seine lokale Datei-Header-Signatur identifiziert werden kann. Dies ist jedoch nicht notwendigerweise der Fall, da dies von der ZIP-Spezifikation nicht verlangt wird – insbesondere beginnt ein selbstextrahierendes Archiv mit einem Header für eine ausführbare Datei.
Werkzeuge, die ZIP-Archive korrekt lesen, müssen nach der Signatur des Endes des zentralen Verzeichniseintrags suchen und dann gegebenenfalls nach den anderen, angegebenen zentralen Verzeichniseinträgen. Sie dürfen nicht nach Einträgen am Anfang der ZIP-Datei suchen, da (wie bereits in diesem Abschnitt erwähnt) nur das zentrale Verzeichnis angibt, wo ein Datei-Stück beginnt und dass es nicht gelöscht wurde. Das Scannen könnte zu falsch-positiven Ergebnissen führen, da das Format weder verbietet, dass sich andere Daten zwischen den Chunks befinden, noch dass Dateidatenströme solche Signaturen enthalten. Werkzeuge, die versuchen, Daten aus beschädigten ZIP-Archiven wiederherzustellen, werden jedoch höchstwahrscheinlich das Archiv nach lokalen Datei-Header-Signaturen durchsuchen; dies wird durch die Tatsache erschwert, dass die komprimierte Größe eines Datei-Chunks nach dem Datei-Chunk gespeichert werden kann, was eine sequentielle Verarbeitung erschwert.
Die meisten Signaturen enden mit der kurzen Ganzzahl 0x4b50, die in Little-Endian-Reihenfolge gespeichert ist. Als ASCII-Zeichenkette betrachtet bedeutet dies „PK“, die Initialen des Erfinders Phil Katz. Wenn also eine ZIP-Datei in einem Texteditor angezeigt wird, sind die ersten beiden Bytes der Datei normalerweise „PK“. (DOS-, OS/2- und Windows-ZIP-Dateien, die sich selbst entpacken, haben ein EXE vor der ZIP-Datei und beginnen mit „MZ“; selbstentpackenden ZIP-Dateien für andere Betriebssysteme kann ebenfalls ein ausführbarer Code vorangestellt werden, um den Inhalt des Archivs auf der jeweiligen Plattform zu entpacken.)
Die ZIP-Spezifikation unterstützt auch die Verteilung von Archiven auf mehrere Dateien im Dateisystem. Ursprünglich für die Speicherung großer ZIP-Dateien auf mehreren Disketten gedacht, wird diese Funktion jetzt für den Versand von ZIP-Archiven in Teilen per E-Mail oder über andere Transportmittel oder Wechselmedien verwendet.
Das FAT-Dateisystem von DOS hat eine Zeitstempelauflösung von nur zwei Sekunden; ZIP-Dateidatensätze imitieren dies. Folglich beträgt die eingebaute Zeitstempelauflösung von Dateien in einem ZIP-Archiv nur zwei Sekunden, obwohl zusätzliche Felder verwendet werden können, um genauere Zeitstempel zu speichern. Das ZIP-Format kennt keine Zeitzone, so dass Zeitstempel nur dann sinnvoll sind, wenn bekannt ist, in welcher Zeitzone sie erstellt wurden.
Im September 2007 veröffentlichte PKWARE eine Überarbeitung der ZIP-Spezifikation, die die Speicherung von Dateinamen in UTF-8 vorsieht und ZIP endlich Unicode-Kompatibilität verleiht.
Datei-HeaderBearbeiten
Alle Multi-Byte-Werte im Header werden in Little-Endian-Byte-Reihenfolge gespeichert. Alle Längenfelder zählen die Länge in Bytes.
Lokaler DateikopfBearbeiten
| Offset | Bytes | Beschreibung |
|---|---|---|
| 0 | 4 | Lokale Dateikopfsignatur = 0x04034b50 (gelesen als little-Endian-Zahl) |
| 4 | 2 | Zur Extraktion benötigte Version (Minimum) |
| 6 | 2 | Allgemeines Bit-Flag |
| 8 | 2 | Komprimierungsmethode |
| 10 | 2 | Datei letzte Änderungszeit |
| 12 | 2 | Datei letztes Änderungsdatum |
| 14 | 4 | CRC-32 unkomprimierte Daten |
| 18 | 4 | Komprimierte Größe (oder 0xffffffff für ZIP64) |
| 22 | 4 | Unkomprimierte Größe (oder 0xffffffff für ZIP64) |
| 26 | 2 | Dateinamenlänge (n) |
| 28 | 2 | Extra Feldlänge (m) |
| 30 | n | Dateiname |
| 30+n | m | Zusatzfeld |
Das Zusatzfeld enthält eine Reihe optionaler Daten wie OS-spezifische Attribute. Es ist in Chunks unterteilt, die jeweils einen 16-Bit-ID-Code und eine 16-Bit-Länge haben. Bei ZIP64 ist immer mindestens ein Chunk (mit ID-Code 0001 und einer Größe von 32 Byte) vorhanden, siehe unten.
Diesem folgen unmittelbar die komprimierten Daten.
Data descriptorEdit
Wenn das Bit an Offset 3 (0x08) des Allzweck-Flag-Feldes gesetzt ist, sind die CRC-32 und die Dateigrößen nicht bekannt, wenn der Header geschrieben wird. Die Felder im lokalen Header werden mit Null gefüllt, und die CRC-32 und die Größe werden in einer 12-Byte-Struktur (optional mit vorangestellter 4-Byte-Signatur) unmittelbar nach den komprimierten Daten angefügt:
| Offset | Bytes | Beschreibung |
|---|---|---|
| 0 | 0/4 | Optionale Datendeskriptor-Signatur = 0x08074b50 |
| 0/4 | 4 | CRC-32 der unkomprimierten Daten |
| 4/8 | 4 | Komprimierte Größe |
| 8/12 | 4 | Unkomprimiert size |
Zentrale Verzeichnisdatei headerEdit
Der zentrale Verzeichniseintrag ist eine erweiterte Form des lokalen Headers:
| Offset | Bytes | Beschreibung |
|---|---|---|
| 0 | 4 | Zentral Header-Signatur der Verzeichnisdatei = 0x02014b50 |
| 4 | 2 | Version erstellt von |
| 6 | 2 | Version zum Extrahieren erforderlich (Minimum) |
| 8 | 2 | Allzweck-Bitflag |
| 10 | 2 | Komprimierungsmethode |
| 12 | 2 | Datei letzte Änderungszeit |
| 14 | 2 | Datei letztes Änderungsdatum |
| 16 | 4 | CRC-32 unkomprimierte Daten |
| 20 | 4 | Komprimierte Größe (oder 0xffffffff für ZIP64) |
| 24 | 4 | Unkomprimierte Größe (oder 0xffffffffff für ZIP64) |
| 28 | 2 | Länge des Dateinamens (n) |
| 30 | 2 | Länge der Zusatzfelder (m) |
| 32 | 2 | Dateikommentarlänge (k) |
| 34 | 2 | Datenträgernummer, auf der die Datei beginnt |
| 36 | 2 | Interne Dateiattribute |
| 38 | 4 | Externe Dateiattribute |
| 42 | 4 | Relativer Offset des lokalen Dateiheaders. Dies ist die Anzahl der Bytes zwischen dem Beginn des ersten Datenträgers, auf dem sich die Datei befindet, und dem Beginn des lokalen Dateikopfes. Dies ermöglicht es Software, die das zentrale Verzeichnis liest, die Position der Datei innerhalb der ZIP-Datei zu lokalisieren. |
| 46 | n | Dateiname |
| 46+n | m | Extrafeld |
| 46+n+m | k | Dateikommentar |
End of central directory record (EOCD)Edit
Nach allen Einträgen des zentralen Verzeichnisses kommt der end of central directory (EOCD) record, der das Ende der ZIP-Datei markiert:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | End of Signatur des zentralen Verzeichnisses = 0x06054b50 |
| 4 | 2 | Nummer dieser Festplatte |
| 6 | 2 | Platte, auf der das zentrale Verzeichnis beginnt |
| 8 | 2 | Anzahl der zentralen Verzeichniseinträge auf diesem Laufwerk |
| 10 | 2 | Gesamtzahl der zentralen Verzeichniseinträge |
| 12 | 4 | Größe des zentralen Verzeichnisses (Bytes) |
| 16 | 4 | Offset des Beginns des zentralen Verzeichnisses, relativ zum Beginn des Archivs |
| 20 | 2 | Kommentarlänge (n) |
| 22 | n | Kommentar |
Durch diese Anordnung kann eine ZIP-Datei in einem Durchgang erstellt werden, aber das zentrale Verzeichnis wird auch an das Ende der Datei gesetzt, um das einfache Entfernen von Dateien aus mehrteiligen (z. B.
KomprimierungsmethodenBearbeiten
Die ZIP-Dateiformatspezifikation dokumentiert die folgenden Komprimierungsmethoden: Store (keine Komprimierung), Shrink (LZW), Reduce (Level 1-4; LZ77 + probabilistisch), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd und eine LZ77-Variante, die von der IBM z/OS CMPSC-Anweisung bereitgestellt wird. Die am häufigsten verwendete Komprimierungsmethode ist DEFLATE, die im IETF RFC 1951 beschrieben ist.
Weitere Methoden, die in der Spezifikation zwar erwähnt, aber nicht im Detail dokumentiert sind, sind unter anderem: PKWARE DCL Implode (alte IBM TERSE), neue IBM TERSE, IBM LZ77 z Architecture (PFS) und eine JPEG Variante. Eine „Tokenize“-Methode war für Dritte reserviert, wurde aber nie unterstützt.
Das Wort Implode wird von PKWARE überstrapaziert: Das DCL/TERSE-Implode unterscheidet sich vom alten PKZIP-Implode, einem Vorgänger von Deflate. Der DCL-Implode ist undokumentiert, teilweise aufgrund seiner proprietären Natur, die von IBM gehalten wird, aber Mark Adler hat dennoch einen Dekompressor namens „blast“ neben zlib zur Verfügung gestellt.
EncryptionEdit
ZIP unterstützt ein einfaches passwortbasiertes symmetrisches Verschlüsselungssystem, das allgemein als ZipCrypto bekannt ist. Es ist in der ZIP-Spezifikation dokumentiert und bekanntermaßen mit erheblichen Mängeln behaftet. Insbesondere ist es anfällig für Angriffe mit bekanntem Klartext, die in einigen Fällen durch schlechte Implementierungen von Zufallszahlengeneratoren noch verschlimmert werden.
Neue Funktionen, einschließlich neuer Komprimierungs- und Verschlüsselungsmethoden (z. B. AES), sind seit Version 5.2 in der ZIP-Dateiformatspezifikation dokumentiert. Ein von WinZip entwickelter AES-basierter offener Standard („AE-x“ in APPNOTE) wird auch von 7-Zip und Xceed verwendet, aber einige Anbieter verwenden andere Formate. PKWARE SecureZIP (SES, proprietär) unterstützt auch RC2-, RC4-, DES- und Triple-DES-Verschlüsselungsmethoden, auf digitalen Zertifikaten basierende Verschlüsselung und Authentifizierung (X.509) sowie Archiv-Header-Verschlüsselung. Es ist jedoch patentiert (siehe § Kontroverse über starke Verschlüsselung).
Die Verschlüsselung von Dateinamen wurde in der ZIP-Dateiformat-Spezifikation 6.2 eingeführt, die die im zentralen Verzeichnisteil eines Archivs gespeicherten Metadaten verschlüsselt, während die lokalen Header-Abschnitte unverschlüsselt bleiben. Ein konformes Archivierungsprogramm kann die Local Header-Daten bei Verwendung der Central Directory Encryption fälschen. Ab Version 6.2 der Spezifikation sind die Felder „Compression Method“ und „Compressed Size“ im Local Header noch nicht maskiert.
ZIP64Edit
Das ursprüngliche ZIP-Format hatte ein Limit von 4 GiB (232 Bytes) für verschiedene Dinge (unkomprimierte Größe einer Datei, komprimierte Größe einer Datei und Gesamtgröße des Archivs) sowie ein Limit von 65.535 (216) Einträgen in einem ZIP-Archiv. In Version 4.5 der Spezifikation (die nicht mit Version 4.5 eines bestimmten Tools identisch ist) führte PKWARE die „ZIP64“-Formaterweiterungen ein, um diese Beschränkungen zu umgehen, und erhöhte die Grenzen auf 16 EiB (264 Byte). Im Wesentlichen wird dabei ein „normaler“ zentraler Verzeichniseintrag für eine Datei verwendet, gefolgt von einem optionalen „zip64“-Verzeichniseintrag, der die größeren Felder enthält.
Das Format des lokalen Dateikopfes und des zentralen Verzeichniseintrags sind bei ZIP und ZIP64 gleich, aber für die Größen wird immer 0xffffffff gespeichert, und ein zusätzliches Feld ist immer vorhanden:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 2 | Header ID 0x0001 |
| 2 | 2 | Größe des zusätzlichen Feldchunks (16, 24 oder 28) |
| 4 | 8 | Originalgröße der unkomprimierten Datei |
| 12 | 8 | Größe der komprimierten Daten |
| 20 | 8 | Offset des lokalen Header-Records |
| 28 | 4 | Nummer des Datenträgers, auf dem diese Datei beginnt |
Auf der anderen Seite, Das Format der EOCD für ZIP64 unterscheidet sich geringfügig von der normalen ZIP-Version (siehe Anhang, Abschnitt 4.3.14).
| Offset | Bytes | Beschreibung |
|---|---|---|
| 0 | 4 | Ende der zentralen Verzeichnissignatur = 0x06064b50 |
| 4 | 8 | Größe des EOCD64 – 8 |
| 12 | 2 | Version erstellt von |
| 14 | 2 | Version, die zum Extrahieren benötigt wird (Minimum) |
| 16 | 4 | Nummer dieser Platte |
| 20 | 4 | Platte, auf der das zentrale Verzeichnis beginnt |
| 24 | 8 | Anzahl der Einträge des zentralen Verzeichnisses auf dieser Platte |
| 32 | 8 | Gesamtzahl der Einträge des zentralen Verzeichnisses |
| 40 | 8 | Größe des zentralen Verzeichnisses (Bytes) |
| 48 | 8 | Offset des Anfangs des zentralen Verzeichnisses, relativ zum Beginn des Archivs |
| 56 | n | Kommentar (bis zur Größe von EOCD64) |
Es ist auch nicht unbedingt der letzte Datensatz in der Datei, es kann ein optionaler End of Central Directory Locator folgen (zusätzliche 20 Bytes am Ende).
Der Datei-Explorer in Windows XP unterstützt ZIP64 nicht, aber der Explorer in Windows Vista und höher schon. Ebenso unterstützen einige Erweiterungsbibliotheken ZIP64, wie DotNetZip, QuaZIP und IO::Compress::Zip in Perl. Pythons eingebautes zipfile unterstützt es seit 2.5 und ist seit 3.4 standardmäßig aktiviert. OpenJDK’s eingebautes java.util.zip unterstützt ZIP64 ab Version Java 7. Android Java API unterstützt ZIP64 seit Android 6.0. Das Archivierungsdienstprogramm von Mac OS Sierra unterstützt ZIP64 nicht und kann beschädigte Archive erstellen, wenn ZIP64 erforderlich wäre. Der im Lieferumfang von Mac OS enthaltene Befehl ditto kann jedoch ZIP64-Dateien entpacken. Neuere Versionen von Mac OS werden mit info-zip’s zip und unzip Kommandozeilen-Tools ausgeliefert, die Zip64 unterstützen: um dies zu überprüfen, führen Sie zip -v aus und suchen Sie nach „ZIP64_SUPPORT“.
Kombination mit anderen DateiformatenBearbeiten
Das .ZIP-Dateiformat erlaubt es, dass ein Kommentar mit bis zu 65.535 (216-1) Bytes Daten am Ende der Datei nach dem zentralen Verzeichnis steht. Da das zentrale Verzeichnis den Offset jeder Datei im Archiv in Bezug auf den Start angibt, ist es auch möglich, dass der erste Dateieintrag an einem anderen Offset als Null beginnt, obwohl einige Werkzeuge, z. B. gzip, Archivdateien nicht verarbeiten, die nicht mit einem Dateieintrag am Offset Null beginnen.
Dadurch können beliebige Daten in der Datei sowohl vor als auch nach den ZIP-Archivdaten vorkommen, und das Archiv kann trotzdem 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, dass das andere Format beliebige Daten am Ende, am Anfang oder in der Mitte toleriert. Selbstextrahierende Archive (SFX), wie sie von WinZip unterstützt werden, machen sich dies zunutze, indem sie ausführbare (.exe) Dateien sind, die der PKZIP AppNote.txt-Spezifikation entsprechen und von konformen ZIP-Tools oder -Bibliotheken gelesen werden können.
Diese Eigenschaft des ZIP-Formats und des JAR-Formats, das eine Variante von ZIP ist, kann ausgenutzt werden, um bösartige Inhalte (z. B. schädliche Java-Klassen) in einer scheinbar harmlosen Datei zu verstecken, z. B. in einem ins Internet hochgeladenen GIF-Bild. Dieser so genannte GIFAR-Exploit hat sich als wirksamer Angriff auf Webanwendungen wie Facebook erwiesen.
LimitsEdit
Die Mindestgröße einer ZIP-Datei beträgt 22 Byte. Eine solche leere ZIP-Datei enthält nur einen End of Central Directory Record (EOCD):
Die maximale Größe sowohl für die Archivdatei als auch für die einzelnen Dateien darin beträgt 4.294.967.295 Byte (232-1 Byte oder 4 GiB minus 1 Byte) für Standard-ZIP. Für ZIP64 beträgt die maximale Größe 18.446.744.073.709.551.615 Bytes (264-1 Bytes oder 16 EiB minus 1 Byte).
Proprietäre ErweiterungenBearbeiten
ExtrafeldBearbeiten
.Das ZIP-Dateiformat enthält eine Extrafeldfunktion in den Dateiköpfen, mit der zusätzliche Daten gespeichert werden können, die in den bestehenden ZIP-Spezifikationen nicht definiert sind, und die es konformen Archivierungsprogrammen, die diese Felder nicht erkennen, ermöglichen, sie sicher zu überspringen. Die Header-IDs 0-31 sind für die Verwendung durch PKWARE reserviert. Die übrigen IDs können von Drittanbietern für proprietäre Zwecke verwendet werden.
Kontroverse über starke VerschlüsselungBearbeiten
Als WinZip 9.0 im Jahr 2003 als öffentliche Betaversion veröffentlicht wurde, führte WinZip seine eigene AES-256-Verschlüsselung ein, wobei ein anderes Dateiformat verwendet wurde, zusammen mit der Dokumentation für die neue Spezifikation. Die Verschlüsselungsstandards selbst waren nicht proprietär, aber PKWARE hatte APPNOTE.TXT seit 2001 nicht mehr aktualisiert, um die Strong Encryption Specification (SES) einzubeziehen, die von den PKZIP-Versionen 5.0 und 6.0 verwendet worden war. Der technische Berater von WinZip, Kevin Kearney, und der Produktmanager von StuffIt, Mathew Covington, warfen PKWARE vor, SES vorzuenthalten, doch der Chief Technology Officer von PKZIP, Jim Peterson, behauptete, die zertifikatsbasierte Verschlüsselung sei immer noch unvollständig.
In einem weiteren kontroversen Schritt meldete PKWARE am 16. Juli 2003 ein Patent an, in dem eine Methode zur Kombination von ZIP und starker Verschlüsselung zur Erstellung einer sicheren Datei beschrieben wurde.
Schließlich einigten sich PKWARE und WinZip darauf, die Produkte des jeweils anderen zu unterstützen. Am 21. Januar 2004 kündigte PKWARE die Unterstützung des WinZip-basierten AES-Komprimierungsformats an. In einer späteren Betaversion von WinZip konnten auch SES-basierte ZIP-Dateien unterstützt werden. PKWARE veröffentlichte schließlich die Version 5.2 der ZIP-Dateiformat-Spezifikation, in der SES dokumentiert ist. Das Freie Software-Projekt 7-Zip unterstützt ebenfalls AES, aber nicht SES in ZIP-Dateien (ebenso wie sein POSIX-Port p7zip).
Bei Verwendung der AES-Verschlüsselung unter WinZip ist die Komprimierungsmethode immer auf 99 eingestellt, wobei die tatsächliche Komprimierungsmethode in einem AES-Zusatzdatenfeld gespeichert wird. Im Gegensatz dazu speichert die Strong Encryption Specification die Komprimierungsmethode im grundlegenden Datei-Header-Segment von Local Header und Central Directory, es sei denn, Central Directory Encryption wird zum Maskieren/Verschlüsseln von Metadaten verwendet.