.ZIP-tiedostot ovat arkistoja, joihin tallennetaan useita tiedostoja. ZIP mahdollistaa sisältämiensä tiedostojen pakkaamisen monilla eri menetelmillä sekä pelkän tiedoston tallentamisen pakkaamatta sitä. Jokainen tiedosto tallennetaan erikseen, jolloin samassa arkistossa olevat eri tiedostot voidaan pakata eri menetelmillä. Koska ZIP-arkiston tiedostot pakataan yksitellen, niitä on mahdollista purkaa tai lisätä uusia tiedostoja ilman, että koko arkistoa tarvitsee pakata tai purkaa. Tämä eroaa pakattujen tar-tiedostojen muodosta, jolle tällainen satunnaiskäsittely ei ole helposti mahdollista.
ZIP-tiedoston loppuun sijoitetaan hakemisto. Tämä yksilöi, mitä tiedostoja ZIP:ssä on, ja yksilöi, missä ZIP:ssä kyseinen tiedosto sijaitsee. Näin ZIP-lukijat voivat ladata tiedostoluettelon lukematta koko ZIP-arkistoa. ZIP-arkistot voivat myös sisältää ylimääräisiä tietoja, jotka eivät liity ZIP-arkistoon. Näin ZIP-arkistosta voidaan tehdä itsepurkautuva arkisto (sovellus, joka purkaa sisältämänsä tiedot) lisäämällä ohjelmakoodi ZIP-arkistoon ja merkitsemällä tiedosto suoritettavaksi. Luettelon tallentaminen loppuun mahdollistaa myös zipatun tiedoston piilottamisen liittämällä se harmittomaan tiedostoon, kuten GIF-kuvatiedostoon.
ZIP-formaatti käyttää 32-bittistä CRC-algoritmia ja sisältää kaksi kopiota arkiston hakemistorakenteesta tarjotakseen paremman suojan tietojen katoamista vastaan.
StructureEdit
ZIP-tiedosto tunnistetaan oikein siitä, että siinä on keskushakemiston loppu -tietue, joka sijaitsee arkistorakenteen lopussa, jotta uusien tiedostojen liittäminen on helppoa. Jos keskushakemiston lopun tietue osoittaa, että arkisto ei ole tyhjä, jokaisen arkiston sisällä olevan tiedoston tai hakemiston nimi olisi määriteltävä keskushakemistomerkinnässä yhdessä merkintää koskevan muun metatiedon ja ZIP-tiedostossa olevan offsetin kanssa, joka osoittaa varsinaiseen merkintätietoon. Näin arkiston tiedostoluettelo voidaan laatia suhteellisen nopeasti, koska koko arkistoa ei tarvitse lukea tiedostoluettelon saamiseksi. ZIP-tiedoston sisältämät merkinnät sisältävät nämä tiedot redundanssin vuoksi myös paikallisessa tiedosto-otsakkeessa. Koska ZIP-tiedostoihin voidaan liittää lisäyksiä, vain tiedoston lopussa olevassa keskushakemistossa määritellyt tiedostot ovat kelvollisia. ZIP-tiedoston skannaaminen paikallisten tiedostootsikoiden varalta on virheellistä (paitsi vioittuneiden arkistojen tapauksessa), koska keskushakemisto voi ilmoittaa, että jotkin tiedostot on poistettu ja toiset tiedostot on päivitetty.
Aloitetaan esimerkiksi ZIP-tiedostosta, joka sisältää tiedostot A, B ja C. Tämän jälkeen tiedosto B on poistettu ja C päivitetty. Tämä voidaan toteuttaa liittämällä uusi tiedosto C alkuperäisen ZIP-tiedoston loppuun ja lisäämällä uusi keskushakemisto, jossa on vain tiedosto A ja uusi tiedosto C. Kun ZIP suunniteltiin, tiedostojen siirtäminen levykkeellä oli yleistä, mutta kirjoittaminen levykkeille oli hyvin aikaa vievää. Jos sinulla oli suuri zip-tiedosto, joka ulottui mahdollisesti useammalle levykkeelle, ja sinun piti päivittää vain muutama tiedosto sen sijaan, että lukisit ja kirjoittaisit kaikki tiedostot uudelleen, olisi huomattavasti nopeampaa vain lukea vanha keskushakemisto, liittää siihen uudet tiedostot ja liittää sitten päivitetty keskushakemisto.
Keskushakemiston tiedostomerkintöjen järjestyksen ei tarvitse olla sama kuin arkiston tiedostomerkintöjen järjestys.
Jokaista ZIP-arkistoon tallennettua merkintää johdattaa paikallinen tiedosto-otsikko, joka sisältää tietoa tiedostosta, kuten kommentin, tiedoston koon ja tiedostonimen, jota seuraavat valinnaiset ”ylimääräiset” tietokentät, ja sitten mahdollisesti pakattu, mahdollisesti salattu tiedosto. Lisätietokentät ovat avain ZIP-muodon laajennettavuuteen. ”Extra”-kenttiä hyödynnetään ZIP64-muodon, WinZip-yhteensopivan AES-salauksen, tiedostoattribuuttien ja korkeamman resoluution NTFS- tai Unix-tiedostojen aikaleimojen tukemiseen. Muut laajennukset ovat mahdollisia ”Extra”-kentän kautta. ZIP-työkaluja vaaditaan spesifikaation mukaan jättämään huomiotta Extra-kentät, joita ne eivät tunnista.
ZIP-formaatti käyttää erityisiä 4 tavun ”allekirjoituksia” tiedoston eri rakenteiden merkitsemiseen. Jokainen tiedostomerkintä on merkitty tietyllä allekirjoituksella. Keskushakemistotietueen loppu merkitään omalla erityisellä allekirjoituksellaan, ja jokainen keskushakemiston merkintä alkaa 4 tavun keskustiedoston otsikon allekirjoituksella.
ZIP-määrittelyssä ei ole BOF- tai EOF-merkkiä. Tavanomaisesti ZIP-tiedoston ensimmäinen asia on ZIP-merkintä, joka voidaan helposti tunnistaa sen paikallisen tiedostootsikon allekirjoituksesta. Näin ei kuitenkaan välttämättä ole, sillä ZIP-määrittely ei vaadi tätä – erityisesti itsepurkautuva arkisto alkaa suoritettavan tiedoston otsikolla.
Työkalujen, jotka lukevat ZIP-arkistoja oikein, on etsittävä keskushakemistotietueen lopun allekirjoitus ja sen jälkeen tarvittaessa muut ilmoitetut keskushakemistotiedot. Ne eivät saa skannata merkintöjä ZIP-tiedoston yläosasta, koska (kuten aiemmin tässä jaksossa mainittiin) vain keskushakemisto määrittää, mistä tiedostokappale alkaa ja että sitä ei ole poistettu. Skannaus voisi johtaa vääriin positiivisiin tuloksiin, koska tiedostomuoto ei kiellä muita tietoja kappaleitten välissä eikä tiedostojen tietovirtoja sisältämästä tällaisia merkintöjä. Työkalut, jotka yrittävät palauttaa tietoja vaurioituneista ZIP-arkistoista, kuitenkin todennäköisesti skannaavat arkiston paikallisten tiedosto-otsikkosignatuurien varalta; tätä vaikeuttaa se, että tiedostokappaleen pakattu koko saatetaan tallentaa tiedostokappaleen jälkeen, mikä vaikeuttaa peräkkäistä käsittelyä.
Useimmat signatuurit päättyvät lyhyeen kokonaislukuun 0x4b50, joka tallennetaan pikku-endian-järjestyksessä. ASCII-merkkijonona tämä on ”PK”, keksijä Phil Katzin nimikirjaimet. Kun ZIP-tiedostoa tarkastellaan tekstieditorilla, tiedoston kaksi ensimmäistä tavua ovat yleensä ”PK”. (DOS-, OS/2- ja Windows-käyttöjärjestelmien itsepurkautuvissa ZIP-tiedostoissa on EXE ennen ZIP-tiedostoa, joten ne alkavat kirjaimella ”MZ”; muiden käyttöjärjestelmien itsepurkautuvissa ZIP-tiedostoissa voi olla myös suoritettava koodi, jolla arkiston sisältö puretaan kyseisellä alustalla.)
ZIP-määrittely tukee myös arkistojen levittämistä useisiin tiedostojärjestelmän tiedostoihin. Tämä ominaisuus on alun perin tarkoitettu suurten ZIP-tiedostojen tallentamiseen useille levykkeille, mutta nykyään sitä käytetään ZIP-arkistojen lähettämiseen osissa sähköpostitse tai muiden kuljetusvälineiden tai siirrettävien tietovälineiden kautta.
DOS:n FAT-tiedostojärjestelmän aikaleiman resoluutio on vain kaksi sekuntia; ZIP-tiedostojen tietueet jäljittelevät tätä. Tämän seurauksena ZIP-arkiston tiedostojen sisäänrakennettu aikaleiman resoluutio on vain kaksi sekuntia, vaikka lisäkenttiä voidaan käyttää tarkempien aikaleimojen tallentamiseen. ZIP-formaatissa ei ole aikavyöhykkeen käsitettä, joten aikaleimoilla on merkitystä vain, jos tiedetään, missä aikavyöhykkeessä ne on luotu.
Syyskuussa 2007 PKWARE julkaisi ZIP-määrittelyn tarkistuksen, joka mahdollistaa tiedostonimien tallentamisen UTF-8-kieltä käyttäen, mikä vihdoin lisäsi ZIP:n Unicode-yhteensopivuuden.
Tiedostojen otsikotMuokkaa
Kaikkien usean tavun arvoja sisältävien tiedostojen otsikossa olevat arvot tallentuvat pikku-endianssin mukaiseen järjestykseen. Kaikki pituuskentät laskevat pituuden tavuina.
Local file headerEdit
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | Local file header signature = 0x04034b50 (luetaan pikku-alkuisena).endiaaniluku) |
| 4 | 2 | Versio, joka tarvitaan purkuun (minimi) |
| 6 | 2 | Yleiskäyttöinen bittilippu |
| 8 | 2 | Pakkausmenetelmä |
| 10 | 2 | Tiedoston viimeisen muokkauksen aika |
| 12 | 2 | Tiedoston viimeisen muokkauksen päivämäärä |
| 14 | 4 | CRC-32 pakkaamatonta dataa |
| 18 | 4 | Pakattu koko (tai 0xffffffffff ZIP64:lle) |
| 22 | 4 | Pakkaamaton koko (tai 0xffffffffff ZIP64:lle) |
| 26 | 2 | Tiedoston nimen pituus (n) |
| 28 | 2 | Ylimääräisen kentän pituus (m) |
| 30 | n | Tiedoston nimi |
| 30+n | m | Lisäkenttä |
Lisäkenttä sisältää erilaisia valinnaisia tietoja kuten OS-spesifiset attribuutit. Se on jaettu lohkoihin, joilla kullakin on 16-bittinen ID-koodi ja 16-bittinen pituus. Paikallisen otsikon kentät täytetään nollalla, ja CRC-32 ja koko liitetään 12 tavun rakenteeseen (jota mahdollisesti edeltää 4 tavun allekirjoitus) heti pakatun datan jälkeen:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 0/4 | Valinnainen datakuvaajan allekirjoitus = 0x08074b50 |
| 0/4 | 4 | CRC-32 pakkaamatonta dataa |
| 4/8 | 4 | Pakkaamaton koko |
| 8/12 | 4 | pakkaamaton size |
Keskushakemistotiedoston otsikkoEdit
Keskushakemistomerkintä on laajennettu muoto paikallisesta otsikosta:
| Offset | Bytes | Bytes | Description |
|---|---|---|---|
| 0 | 4 | Kesk. Hakemistotiedoston otsikon allekirjoitus = 0x02014b50 | |
| 4 | 2 | Version tehnyt | |
| 6 | 2 | Versio, jota tarvitaan purkamiseen. (minimi) | |
| 8 | 2 | Yleinen bittilippu | |
| 10 | 2 | Pakkausmenetelmä | |
| 12 | 2 | Tiedoston viimeinen muokkausaika | |
| 14 | 2 | Tiedoston viimeinen muokkauspäivämäärä | |
| 16 | 4 | CRC-32 pakkaamatonta dataa | |
| 20 | 4 | Pakattu koko (tai 0xffffffffff ZIP64:lle) | |
| 24 | 4 | Puristamaton koko. (tai 0xffffffffff ZIP64:lle) | |
| 28 | 2 | Tiedoston nimen pituus (n) | |
| 30 | 2 | Ylimääräisen kentän pituus (m) | |
| 32 | 2 | Tiedoston kommentin pituus (k) | |
| 34 | 2 | Kiekon numero, josta tiedosto alkaa | |
| 36 | 2 | 2 | Tiedoston sisäiset attribuutit |
| 38 | 4 | Tiedoston ulkoiset attribuutit | |
| 42 | 4 | Lähitiedoston paikallisen otsikon suhteellinen siirtymä. Tämä on tavujen määrä sen ensimmäisen levyn, jolla tiedosto sijaitsee, ja paikallisen tiedoston otsikon alun välillä. Tämän avulla keskushakemistoa lukevat ohjelmat voivat paikantaa tiedoston sijainnin ZIP-tiedoston sisällä. | |
| 46 | n | Tiedoston nimi | |
| 46+n | m | Ylimääräinen kenttä | |
| 46+n+m | k | Tiedoston kommentti |
Keskushakemistotietueen loppu (EOCD)Muokkaa
Keskushakemistomerkintöjen jälkeen tulee keskushakemistotietue (EOCD), joka merkitsee ZIP-tiedoston loppua:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | Loppuosa. Keskushakemiston allekirjoitus = 0x06054b50 |
| 4 | 2 | Tämän levyn numero |
| 6 | 2 | Levy, jolla keskushakemisto sijaitsee. alkaa |
| 8 | 2 | Keskushakemistotietueiden määrä tällä levyllä |
| 10 | 2 | Keskushakemistotietueiden kokonaislukumäärä hakemistotietueet |
| 12 | 4 | Keskushakemiston koko (tavua) |
| 16 | 4 | Keskushakemiston alkuosoite, suhteessa arkiston alkuun |
| 20 | 2 | Kommentin pituus (n) |
| 22 | n | Kommentti |
Tämä järjestys mahdollistaa ZIP-tiedoston luomisen yhdellä kerralla, mutta keskushakemisto sijoitetaan myös tiedoston loppuun, jotta tiedostojen poistaminen olisi helppoa moniosaisista (esim.esim. ”usean levykkeen”) arkistot, kuten aiemmin on käsitelty.
Pakkausmenetelmät Muokkaa
ZIP-tiedostomuodon spesifikaatio dokumentoi seuraavat pakkausmenetelmät: Store (ei pakkausta), Shrink (LZW), Reduce (tasot 1-4; LZ77 + probabilistinen), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd ja IBM z/OS:n CMPSC-ohjeen tarjoama LZ77-muunnos. Yleisimmin käytetty pakkausmenetelmä on DEFLATE, joka on kuvattu IETF:n RFC 1951:ssä.
Muita menetelmiä, jotka mainitaan, mutta joita ei ole dokumentoitu yksityiskohtaisesti spesifikaatiossa, ovat muun muassa: PKWARE DCL Implode (vanha IBM TERSE), uusi IBM TERSE, IBM LZ77 z Architecture (PFS) ja JPEG-muunnos. ”Tokenize”-menetelmä oli varattu kolmannelle osapuolelle, mutta tukea ei koskaan lisätty.
PKWARE käyttää sanaa Implode liikaa: DCL/TERSE Implode eroaa vanhasta PKZIP Implode -menetelmästä, joka oli Deflaten edeltäjä. DCL Implode ei ole dokumentoitu osittain IBM:n omistusoikeuden vuoksi, mutta Mark Adler on kuitenkin toimittanut zlibin rinnalle dekompressorin nimeltä ”blast”.
EncryptionEdit
ZIP tukee yksinkertaista salasanaan perustuvaa symmetristä salausjärjestelmää, joka tunnetaan yleisesti nimellä ZipCrypto. Se on dokumentoitu ZIP-määrittelyssä, ja sen tiedetään olevan vakavasti puutteellinen. Erityisesti se on haavoittuvainen know-plaintext-hyökkäyksille, joita joissakin tapauksissa pahentavat satunnaislukugeneraattoreiden huonot toteutukset.
Uudet ominaisuudet, mukaan lukien uudet pakkaus- ja salausmenetelmät (esim. AES), on dokumentoitu ZIP-tiedostomuotoilun spesifikaatiossa versiosta 5.2 lähtien. WinZipin kehittämää AES-pohjaista avointa standardia (”AE-x” APPNOTE:ssa) käyttävät myös 7-Zip ja Xceed, mutta jotkut toimittajat käyttävät muita formaatteja. PKWARE SecureZIP (SES, oma) tukee myös RC2-, RC4-, DES- ja Triple DES-salausmenetelmiä, digitaaliseen sertifikaattiin perustuvaa salausta ja todennusta (X.509) sekä arkistointiotsikon salausta. Se on kuitenkin patentoitu (ks. § Vahvan salauksen kiista).
Tiedostonimien salaus on otettu käyttöön .ZIP File Format Specification 6.2:ssa, joka salaa arkiston keskushakemisto-osaan tallennetut metatiedot, mutta Local Header -osiot pysyvät salaamattomina. Yhteensopiva arkistointilaite voi väärentää Local Header -tiedot, kun käytetään Central Directory Encryption -salausta. Spesifikaation versiosta 6.2 alkaen Local Headerin Compression Method- ja Compressed Size -kenttiä ei ole vielä peitetty.
ZIP64Edit
Alkuperäisessä .ZIP-formaatissa oli 4 GiB:n (232 tavua) rajoitus useille asioille (tiedostojen pakkaamattomalle koolle, tiedostojen pakatulle koolle ja arkiston kokonaiskoolle) sekä 65 535:n (216:n) merkinnän rajoitus ZIP-arkistoon. Määrittelyn versiossa 4.5 (joka ei ole sama kuin minkään tietyn työkalun versio 4.5) PKWARE otti käyttöön ”ZIP64”-formaatin laajennukset näiden rajoitusten kiertämiseksi ja nosti rajoitukset 16 EiB:hen (264 tavuun). Pohjimmiltaan se käyttää tiedostolle ”normaalia” keskimmäistä hakemistomerkintää, jota seuraa valinnainen ”zip64”-hakemistomerkintä, jossa on suuremmat kentät.
Lokaalitiedoston otsikon ja keskushakemistomerkinnän muoto on sama ZIP:ssä ja ZIP64:ssä, mutta koot tallennetaan aina 0xffffffffff, ja ylimääräinen kenttä on aina olemassa:
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 2 | Header ID 0x0001 | |
| 0 | 0 | 2 | Ylimääräisen kentän lohkon koko (16, 24 tai 28) |
| 4 | 8 | Alkuperäinen pakkaamaton tiedostokoko | |
| 12 | 8 | Pakatun datan koko | |
| 20 | 8 | Offset of local header record | |
| 28 | 4 | Levyn numero, jolta tämä tiedosto alkaa |
Toisaalta, ZIP64:n EOCD:n muoto poikkeaa hieman normaalista ZIP-versiosta (ks. liitetiedoston kohta 4.3.14).
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | Keskushakemiston allekirjoitus = 0x06064b50 |
| 4 | 8 | EOCD64:n koko – 8 |
| 12 | 2 | Versio, jonka on tehnyt |
| 14 | 2 | Versio, joka tarvitaan louhintaan (vähintään) |
| 16 | 4 | Tämän levyn numero |
| 20 | 4 | Levy, josta keskushakemisto alkaa |
| 24 | 8 | Keskushakemistotietueiden määrä tällä levyllä |
| 32 | 8 | Keskushakemistotietueiden määrä yhteensä |
| 40 | 8 | Keskushakemiston koko (tavua) |
| 48 | 8 | Keskushakemiston alkuosoite, suhteessa arkiston alkuun |
| 56 | n | Kommentti (EOCD64:n kokoon asti) |
Se ei myöskään välttämättä ole tiedoston viimeinen tietue, vaan sen jälkeen voi seurata valinnainen keskushakemiston lopun osoitin (End of Central Directory Locator) (ylimääräiset 20 tavua lopussa).
Windows XP:n File Explorer ei tue ZIP64:ää, mutta Windows Vistan ja uudempien versioiden Explorer tukee. Samoin jotkut laajennuskirjastot tukevat ZIP64:ää, kuten DotNetZip, QuaZIP ja IO::Compress::Zip Perlissä. Pythonin sisäänrakennettu zipfile tukee sitä 2.5:stä lähtien ja oletusarvoisesti 3.4:stä lähtien. OpenJDK:n sisäänrakennettu java.util.zip tukee ZIP64:ää Java 7 -versiosta lähtien. Androidin Java API tukee ZIP64:ää Android 6.0:sta lähtien. Mac OS Sierran Archive Utility ei erityisesti tue ZIP64:ää, ja se voi luoda korruptoituneita arkistoja silloin, kun ZIP64:ää tarvittaisiin. Mac OS:n mukana toimitettu ditto-komento purkaa kuitenkin ZIP64-tiedostot. Mac OS:n uudemmissa versioissa on info-zipin zip- ja unzip-komentorivityökalut, jotka tukevat Zip64:ää: tarkista se ajamalla zip -v ja etsimällä ”ZIP64_SUPPORT”.
Yhdistäminen muihin tiedostomuotoihinMuokkaa
ZIP-tiedostomuoto sallii tiedoston lopussa keskihakemiston jälkeen kommentin, joka sisältää enintään 65 535 (216-1) tavua tietoa. Koska keskushakemisto määrittää myös arkiston jokaisen tiedoston siirtymän aloitukseen nähden, on mahdollista, että ensimmäinen tiedostomerkintä alkaa muusta siirtymästä kuin nollasta, vaikka jotkin työkalut, esimerkiksi gzip, eivät käsittele arkistotiedostoja, jotka eivät aloita tiedostomerkinnällä siirtymästä nolla.
Tämä mahdollistaa sen, että tiedostossa voi esiintyä mielivaltaista dataa sekä ennen ZIP-arkiston datan alkua että sen jälkeen ja että ZIP-sovellus voi silti lukea arkistoa. Tämän sivuvaikutuksena on, että on mahdollista laatia tiedosto, joka on sekä toimiva ZIP-arkisto että jokin muu tiedostomuoto edellyttäen, että toinen tiedostomuoto sietää mielivaltaista dataa lopussa, alussa tai keskellä. WinZipin tukemassa muodossa olevat itsepurkautuvat arkistot (SFX) hyödyntävät tätä, sillä ne ovat suoritettavia (.exe) tiedostoja, jotka ovat PKZIP AppNote.txt -määrittelyn mukaisia ja joita voidaan lukea yhteensopivilla zip-työkaluilla tai -kirjastoilla.
Tätä .ZIP-muodon ja JAR-muodon, joka on ZIP-muodon muunnos, ominaisuutta voidaan käyttää hyväksi, jotta näennäisesti harmittoman tiedoston, kuten verkkoon ladatun GIF-kuvan, sisälle voidaan piilottaa haitallista sisältöä (kuten haitallisia Java-luokkia). Tämä niin sanottu GIFAR-hyökkäys on osoitettu tehokkaaksi hyökkäykseksi Facebookin kaltaisia verkkosovelluksia vastaan.
LimitsEdit
ZIP-tiedoston minimikoko on 22 tavua. Tällainen tyhjä zip-tiedosto sisältää vain EOCD-tietueen (End of Central Directory Record):
Arkistotiedoston ja sen sisällä olevien yksittäisten tiedostojen maksimikoko on 4 294 967 295 tavua (232-1 tavua eli 4 gigatavua miinus 1 tavu) tavalliselle ZIP-tiedostolle. ZIP64:ssä enimmäiskoko on 18 446 744 073 709 551 615 tavua (264-1 tavua eli 16 EiB miinus 1 tavu).
Proprietary extensionsEdit
Extra fieldEdit
.ZIP-tiedostomuoto sisältää tiedoston otsikoissa lisäkenttämahdollisuuden, jota voidaan käyttää sellaisten ylimääräisten tietojen tallentamiseen, joita ei ole määritelty olemassa olevissa ZIP-määrityksissä ja joiden avulla yhteensopivat arkistointilaitteet, jotka eivät tunnista kenttiä, voivat ohittaa ne turvallisesti. Otsikkotunnukset 0-31 on varattu PKWAREn käyttöön. Kolmannen osapuolen toimittajat voivat käyttää loput tunnukset omaan käyttöönsä.
Vahvaa salausta koskeva kiistaEdit
Kun WinZip 9.0:n julkinen beta-versio julkaistiin vuonna 2003, WinZip esitteli uuden spesifikaation dokumentaation ohella oman AES-256-salauksen, joka käytti eri tiedostomuotoa. Itse salausstandardit eivät olleet omia, mutta PKWARE ei ollut päivittänyt APPNOTE.TXT-tiedostoa sisältämään Strong Encryption Specification (SES) -standardia vuoden 2001 jälkeen, jota PKZIP-versiot 5.0 ja 6.0 olivat käyttäneet. WinZipin tekninen konsultti Kevin Kearney ja StuffIt-tuotepäällikkö Mathew Covington syyttivät PKWAREa SES:n pidättämisestä, mutta PKZIP:n teknologiajohtaja Jim Peterson väitti, että varmenteisiin perustuva salaus oli vielä keskeneräinen.
Toisessa kiistanalaisessa toimenpiteessä PKWare haki 16. heinäkuuta 2003 patenttia, jossa kuvattiin menetelmä, jolla ZIP ja vahva salaus yhdistetään turvallisen tiedoston luomiseksi.
Lopulta PKWAREn ja WinZipin edustajat sopivat, että ne tukevat toistensa tuotteita. Tammikuun 21. päivänä 2004 PKWARE ilmoitti tukevansa WinZip-pohjaista AES-pakkausformaattia. Myöhemmässä WinZipin beta-versiossa pystyttiin tukemaan SES-pohjaisia ZIP-tiedostoja. PKWARE julkaisi lopulta julkisesti .ZIP File Format Specificationin version 5.2, jossa SES dokumentoitiin. Vapaan ohjelmiston projekti 7-Zip tukee myös AES:ää, mutta ei SES:ää ZIP-tiedostoissa (kuten myös sen POSIX-portti p7zip).
Käytettäessä AES-salausta WinZip-ohjelmassa pakkausmenetelmäksi asetetaan aina 99, ja varsinainen pakkausmenetelmä tallennetaan AES:n lisätietokenttään. Sitä vastoin Strong Encryption Specification tallentaa pakkausmenetelmän paikallisen otsikon ja keskushakemiston perustiedoston otsikkosegmenttiin, ellei keskushakemiston salausta käytetä metatietojen peittämiseen/salaamiseen.