.ZIP-filer är arkiv som lagrar flera filer. ZIP gör det möjligt att komprimera inneslutna filer med många olika metoder, samt att helt enkelt lagra en fil utan att komprimera den. Varje fil lagras separat, vilket gör att olika filer i samma arkiv kan komprimeras med olika metoder. Eftersom filerna i ett ZIP-arkiv komprimeras individuellt är det möjligt att extrahera dem eller lägga till nya filer utan att komprimera eller dekomprimera hela arkivet. Detta står i kontrast till formatet för komprimerade tar-filer, för vilka en sådan behandling med slumpmässig åtkomst inte är lätt möjlig.
En katalog placeras i slutet av en ZIP-fil. Detta identifierar vilka filer som finns i ZIP-filen och identifierar var i ZIP-filen filen finns. Detta gör det möjligt för ZIP-läsare att läsa in listan över filer utan att läsa hela ZIP-arkivet. ZIP-arkiv kan också innehålla extra data som inte har med ZIP-arkivet att göra. Detta gör det möjligt att göra ett ZIP-arkiv till ett självutdragande arkiv (program som dekomprimerar de ingående uppgifterna) genom att lägga till programkoden i ett ZIP-arkiv och markera filen som körbar. Genom att lagra katalogen i slutet är det också möjligt att dölja en komprimerad fil genom att bifoga den till en ofarlig fil, t.ex. en GIF-bildfil.
Det .ZIP-formatet använder en 32-bitars CRC-algoritm och innehåller två kopior av arkivets katalogstruktur för att ge ett bättre skydd mot dataförlust.
StructureEdit
En ZIP-fil identifieras korrekt genom närvaron av en end of central directory record som är placerad i slutet av arkivstrukturen för att möjliggöra att nya filer enkelt läggs till. Om ändan av den centrala katalogposten indikerar ett arkiv som inte är tomt bör namnet på varje fil eller katalog i arkivet anges i en central katalogpost, tillsammans med andra metadata om posten och en förskjutning i ZIP-filen, som pekar på de faktiska postuppgifterna. På så sätt kan en fillistning av arkivet utföras relativt snabbt, eftersom hela arkivet inte behöver läsas för att se listan över filer. Posterna i ZIP-filen innehåller också denna information, som en redundans, i en lokal filhuvudrubrik. Eftersom ZIP-filer kan kompletteras är endast de filer som anges i den centrala katalogen i slutet av filen giltiga. Att skanna en ZIP-fil efter lokala filhuvuden är ogiltigt (utom när det gäller skadade arkiv), eftersom den centrala katalogen kan deklarera att vissa filer har tagits bort och andra filer har uppdaterats.
Till exempel kan vi börja med en ZIP-fil som innehåller filerna A, B och C. Fil B tas sedan bort och C uppdateras. Detta kan åstadkommas genom att bara lägga till en ny fil C i slutet av den ursprungliga ZIP-filen och lägga till en ny central katalog som endast innehåller fil A och den nya filen C. När ZIP först utformades var det vanligt att överföra filer med diskett, men det var mycket tidskrävande att skriva till disketter. Om man hade en stor zip-fil, som kanske sträckte sig över flera disketter, och bara behövde uppdatera några få filer, skulle det i stället för att läsa och skriva om alla filer vara betydligt snabbare att bara läsa den gamla centrala katalogen, lägga till de nya filerna och sedan lägga till en uppdaterad central katalog.
Filposternas ordning i den centrala katalogen behöver inte sammanfalla med filposternas ordning i arkivet.
Varje post som lagras i ett ZIP-arkiv inleds av en lokal filhuvudrubrik med information om filen, t.ex. kommentar, filstorlek och filnamn, följt av valfria ”extra”-datafält, och därefter de eventuellt komprimerade, eventuellt krypterade filuppgifterna. De ”extra” datafälten är nyckeln till ZIP-formatets utvidgningsmöjligheter. De ”extra” fälten utnyttjas för att stödja ZIP64-formatet, WinZip-kompatibel AES-kryptering, filattribut och NTFS- eller Unix-filtidsstämplar med högre upplösning. Andra utvidgningar är möjliga via ”Extra”-fältet. ZIP-verktyg måste enligt specifikationen ignorera Extra-fält som de inte känner igen.
ZIP-formatet använder specifika 4-byte-”signaturer” för att beteckna de olika strukturerna i filen. Varje filpost är markerad med en specifik signatur. Slutet på en central katalogpost anges med en specifik signatur, och varje post i den centrala katalogen börjar med signaturen för den centrala filhuvudet på 4 byte.
Det finns ingen BOF- eller EOF-markör i ZIP-specifikationen. Konventionellt sett är det första i en ZIP-fil en ZIP-post, som lätt kan identifieras med hjälp av signaturen för den lokala filhuvudet. Detta är dock inte nödvändigtvis fallet, eftersom detta inte krävs av ZIP-specifikationen – framför allt kommer ett självutdragande arkiv att börja med ett exekverbart filhuvud.
Verktyg som korrekt läser ZIP-arkiv måste söka efter signaturen för slutet av den centrala katalogpostens signatur, och sedan, i förekommande fall, efter de andra, angivna, centrala katalogposterna. De får inte söka efter poster från toppen av ZIP-filen, eftersom (som tidigare nämnts i det här avsnittet) endast den centrala katalogen anger var en filchuk börjar och att den inte har raderats. Skanning skulle kunna leda till falska positiva resultat, eftersom formatet inte förbjuder att andra data finns mellan chunks, och inte heller att fildataströmmar innehåller sådana signaturer. Verktyg som försöker återskapa data från skadade ZIP-arkiv kommer dock med största sannolikhet att skanna arkivet efter lokala filhuvudsignaturer; detta försvåras av att den komprimerade storleken på en fil chunk kan lagras efter fil chunken, vilket försvårar sekventiell bearbetning.
De flesta av signaturerna slutar med det korta heltalet 0x4b50, som lagras i little-endian-ordning. Sett som en ASCII-sträng lyder detta ”PK”, som är uppfinnaren Phil Katz’ initialer. När en ZIP-fil visas i en textredigerare är de två första bytena i filen vanligtvis ”PK”. (DOS-, OS/2- och Windows- ZIP-filer med självutdragning har en EXE före ZIP-koden och börjar därför med ”MZ”; ZIP-filer med självutdragning för andra operativsystem kan på samma sätt föregås av en körbar kod för utdragning av arkivets innehåll på den plattformen.)
Specifikationen för .ZIP stöder också spridning av arkiv över flera filer i filsystemet. Denna funktion, som ursprungligen var avsedd för lagring av stora ZIP-filer på flera disketter, används nu för att skicka ZIP-arkiv i delar via e-post, eller via andra transporter eller flyttbara medier.
DOS FAT-filsystem har en tidsstämpelupplösning på endast två sekunder; ZIP-filposter efterliknar detta. Följaktligen är den inbyggda tidsstämpelupplösningen för filer i ett ZIP-arkiv endast två sekunder, även om extra fält kan användas för att lagra mer exakta tidsstämplar. ZIP-formatet har inget begrepp om tidszon, så tidsstämplar är bara meningsfulla om man vet i vilken tidszon de skapades.
I september 2007 släppte PKWARE en revidering av ZIP-specifikationen som ger möjlighet att lagra filnamn med hjälp av UTF-8, vilket äntligen ger ZIP Unicode-kompatibilitet.
FilrubrikerRedigera
Alla multibyte-värden i rubriken lagras i little-endian-byteordning. Alla längdfält räknar längden i byte.
Local file headerEdit
| Offset | Bytes | Beskrivning | |
|---|---|---|---|
| 0 | 4 | Signatur för lokal filheader = 0x04034b50 (läses som en little-endianskt tal) | |
| 4 | 2 | Version som behövs för att extrahera (minimum) | |
| 6 | 2 | General purpose bit flag | |
| 8 | 2 | Komprimeringsmetod | |
| 10 | 2 | Filens senaste modifieringstidpunkt | |
| 12 | 2 | Filens senaste modifieringsdatum | |
| 14 | 4 | CRC-32 okomprimerade data | |
| 18 | 4 | Komprimerad storlek (eller 0xffffffffffffff för ZIP64) | |
| 22 | 22 | 4 | Okomprimerad storlek (eller 0xffffffffffff för ZIP64) |
| 26 | 2 | Filnamnets längd (n) | |
| 28 | 2 | Extra fältlängd (m) | |
| 30 | n | Filnamn | |
| 30+n | m | Extra fält |
Det extra fältet innehåller en mängd olika frivilliga uppgifter, till exempel OS-specifika attribut. Det är indelat i delar, var och en med en 16-bitars ID-kod och en 16-bitars längd. För ZIP64 finns det alltid minst en chunk (med ID-kod 0001 och en storlek på 32 byte), se nedan.
Detta följs omedelbart av de komprimerade uppgifterna.
DatadeskriptorRedigera
Om biten vid offset 3 (0x08) i fältet för generella flaggor är inställd, är CRC-32- och filstorlekarna inte kända när huvudet skrivs. Fälten i den lokala rubriken fylls med noll, och CRC-32 och storleken läggs till i en struktur på 12 byte (som eventuellt föregås av en signatur på 4 byte) omedelbart efter de komprimerade uppgifterna:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 0/4 | Valfri datadeskriptorsignatur = 0x08074b50 |
| 0/4 | 4 | CRC-32 okomprimerade data |
| 4/8 | 4 | komprimerad storlek |
| 8/12 | 4 | Okomprimerad size |
Central directory file headerEdit
Den centrala katalogposten är en expanderad form av den lokala headern:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | Central signatur för katalogfilens header = 0x02014b50 |
| 4 | 2 | Version gjord av |
| 6 | 2 | Version som behövs för att extrahera (minimum) |
| 8 | 2 | Bitflagga för allmänt ändamål |
| 10 | 2 | Komprimeringsmetod |
| 12 | 2 | Filens sista ändringstidpunkt |
| 14 | 2 | Filens sista ändringsdatum |
| 16 | 4 | CRC-32 okomprimerade data |
| 20 | 4 | Komprimerad storlek (eller 0xffffffffffff för ZIP64) |
| 24 | 4 | Okomprimerad storlek (eller 0xffffffffffff för ZIP64) |
| 28 | 2 | Filnamnets längd (n) |
| 30 | 2 | Extrafältets längd (m) |
| 32 | 2 | Filkommentarlängd (k) |
| 34 | 2 | Disknummer där filen startar |
| 36 | 2 | Interna filattribut |
| 38 | 4 | Externa filattribut |
| 42 | 4 | Relativ förskjutning av den lokala filhuvudet. Detta är antalet bytes mellan början av den första disken på vilken filen finns och början av den lokala filhuvudet. Detta gör det möjligt för programvara som läser den centrala katalogen att lokalisera filens position i ZIP-filen. |
| 46 | n | Filnamn |
| 46+n | m | Extra fält |
| 46+n+m | k | Filkommentar |
Slutet av posten i centralkatalogen (EOCD)Redigera
Efter alla poster i centralkatalogen kommer posten i slutet av posten i centralkatalogen (EOCD), som markerar slutet på ZIP-filen:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | End of signatur för den centrala katalogen = 0x06054b50 |
| 4 | 2 | Nummer på denna disk |
| 6 | 2 | Disk där den centrala katalogen är placerad startar |
| 8 | 2 | Antal poster i den centrala katalogen på denna disk |
| 10 | 2 | Total antal poster i den centrala katalogen registerposter |
| 12 | 4 | Storlek på den centrala katalogen (bytes) |
| 16 | 4 | Offset för början av den centrala katalogen, i förhållande till arkivets start |
| 20 | 2 | Kommentarlängd (n) |
| 22 | n | Kommentar |
Denna ordningsföljd gör det möjligt att skapa en ZIP-fil i en gång, men den centrala katalogen placeras också i slutet av filen för att underlätta avlägsnande av filer från flera delar (t.ex.
KomprimeringsmetoderRedigera
Specifikationen för .ZIP-filformatet dokumenterar följande komprimeringsmetoder: Store (ingen komprimering), Shrink (LZW), Reduce (nivåer 1-4; LZ77 + probabilistisk), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd och en LZ77-variant som tillhandahålls av IBM z/OS CMPSC-instruktionen. Den mest använda komprimeringsmetoden är DEFLATE, som beskrivs i IETF RFC 1951.
Andra metoder som nämns, men som inte är dokumenterade i detalj i specifikationen är bland annat: PKWARE DCL Implode (gamla IBM TERSE), nya IBM TERSE, IBM LZ77 z Architecture (PFS) och en JPEG-variant. En ”Tokenize”-metod reserverades för en tredje part, men stöd lades aldrig till.
Ordet Implode överanvänds av PKWARE: DCL/TERSE Implode skiljer sig från den gamla PKZIP Implode, en föregångare till Deflate. DCL Implode är odokumenterad delvis på grund av att det är IBM:s äganderätt, men Mark Adler har ändå tillhandahållit en dekompressor kallad ”blast” tillsammans med zlib.
EncryptionEdit
ZIP har stöd för ett enkelt lösenordsbaserat symmetriskt krypteringssystem, allmänt känt som ZipCrypto. Det är dokumenterat i ZIP-specifikationen och är känt för att vara allvarligt bristfälligt. I synnerhet är det sårbart för ”known-plaintext”-attacker, som i vissa fall förvärras av dåliga implementeringar av slumptalsgeneratorer.
Nya funktioner, inklusive nya komprimerings- och krypteringsmetoder (t.ex. AES), har dokumenterats i ZIP File Format Specification sedan version 5.2. En av WinZip utvecklad AES-baserad öppen standard (”AE-x” i APPNOTE) används även av 7-Zip och Xceed, men vissa leverantörer använder andra format. PKWARE SecureZIP (SES, proprietärt) stöder också krypteringsmetoderna RC2, RC4, DES och Triple DES, kryptering och autentisering med digitala certifikat (X.509) samt kryptering av arkivhuvud. Det är dock patenterat (se § Kontrovers om stark kryptering).
Kryptering av filnamn införs i .ZIP File Format Specification 6.2, som krypterar metadata som lagras i Central Directory-delen av ett arkiv, men Local Header-sektionerna förblir okrypterade. En arkivarie som uppfyller kraven kan förfalska uppgifterna i Local Header när man använder Central Directory Encryption. Från och med version 6.2 av specifikationen är fälten Komprimeringsmetod och Komprimerad storlek i Local Header ännu inte maskerade.
ZIP64Edit
Det ursprungliga .ZIP-formatet hade en gräns på 4 GiB (232 bytes) för olika saker (okomprimerad storlek på en fil, komprimerad storlek på en fil och arkivets totala storlek), samt en gräns på 65 535 (216) poster i ett ZIP-arkiv. I version 4.5 av specifikationen (som inte är detsamma som v4.5 av något särskilt verktyg) införde PKWARE formattillägget ”ZIP64” för att kringgå dessa begränsningar, vilket ökar gränserna till 16 EiB (264 byte). I huvudsak används en ”normal” central katalogpost för en fil, följt av en valfri ”zip64”-katalogpost, som har de större fälten.
Formatet för Local file header och Central directory entry är detsamma i ZIP och ZIP64, men för storlekar lagras alltid 0xffffffffffff, och ett extra fält finns alltid:
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 2 | Header ID 0x0001 | |
| 2 | 2 | 2 | Storlek på det extra fältet (16, 24 eller 28) |
| 4 | 8 | Originell okomprimerad filstorlek | |
| 12 | 8 | Storlek på komprimerade data | |
| 20 | 8 | Offset för lokal header record | |
| 28 | 4 | Nummer på den disk på vilken den här filen startar |
Å andra sidan, EOCD-formatet för ZIP64 skiljer sig något från den normala ZIP-versionen (se avsnitt 4 i appnoten).3.14).
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | Slut av signatur för central katalog = 0x06064b50 |
| 4 | 8 | Storlek på EOCD64 – 8 |
| 12 | 2 | Version gjord av |
| 14 | 2 | Version som behövs för att extrahera (minimum) |
| 16 | 4 | Nummer på denna disk |
| 20 | 4 | Disk där den centrala katalogen startar |
| 24 | 8 | Antal poster i den centrala katalogen på denna disk |
| 32 | 8 | Totalt antal poster i den centrala katalogen |
| 40 | 8 | Storlek på den centrala katalogen (bytes) |
| 48 | 8 | Offset för början av den centrala katalogen, i förhållande till arkivets början |
| 56 | n | Kommentar (upp till storleken på EOCD64) |
Det är inte heller nödvändigtvis den sista posten i filen, en valfri End of Central Directory Locator kan följa (ytterligare 20 bytes i slutet).
Filutforskaren i Windows XP har inte stöd för ZIP64, men utforskaren i Windows Vista och senare har det. Likaså har vissa tilläggsbibliotek stöd för ZIP64, t.ex. DotNetZip, QuaZIP och IO::Compress::Zip i Perl. Pythons inbyggda zipfil har stöd för detta sedan 2.5 och är standard sedan 3.4. OpenJDK:s inbyggda java.util.zip stöder ZIP64 från och med version Java 7. Android Java API stöder ZIP64 sedan Android 6.0. Mac OS Sierras Archive Utility har framför allt inte stöd för ZIP64 och kan skapa korrupta arkiv när ZIP64 skulle behövas. Kommandot dito som levereras med Mac OS kan dock packa upp ZIP64-filer. Nyare versioner av Mac OS levereras med info-zip’s zip- och unzip-kommandoradsverktyg som har stöd för ZIP64: för att verifiera kör zip -v och leta efter ”ZIP64_SUPPORT”.
Kombination med andra filformatRedigera
Filformatet .ZIP gör det möjligt för en kommentar som innehåller upp till 65 535 (216-1) byte data att förekomma i slutet av filen efter den centrala katalogen. Eftersom den centrala katalogen anger offset för varje fil i arkivet i förhållande till starten är det också möjligt att den första filposten börjar vid en annan offset än noll, även om vissa verktyg, t.ex. gzip, inte behandlar arkivfiler som inte börjar med en filpost vid offset noll.
Detta gör det möjligt för godtyckliga data att förekomma i filen både före och efter ZIP-arkivets data, och för arkivet att fortfarande läsas av ett ZIP-program. En bieffekt av detta är att det är möjligt att skapa en fil som både är ett fungerande ZIP-arkiv och ett annat format, förutsatt att det andra formatet tolererar godtyckliga data i slutet, början eller mitten. Självextraherande arkiv (SFX), i den form som stöds av WinZip, drar nytta av detta genom att de är körbara (.exe) filer som överensstämmer med PKZIP AppNote.txt-specifikationen och kan läsas av kompatibla zip-verktyg eller -bibliotek.
Denna egenskap hos .ZIP-formatet och hos JAR-formatet, som är en variant av ZIP, kan utnyttjas för att gömma oseriöst innehåll (t.ex. skadliga Javaklasser) i en till synes ofarlig fil, t.ex. en GIF-bild som laddas upp till webben. Denna så kallade GIFAR-exploatering har visat sig vara ett effektivt angrepp mot webbapplikationer som Facebook.
LimitsEdit
Den minsta storleken på en .ZIP-fil är 22 bytes. En sådan tom zip-fil innehåller endast en End of Central Directory Record (EOCD):
Den maximala storleken för både arkivfilen och de enskilda filerna i den är 4 294 967 295 bytes (232-1 bytes, eller 4 GiB minus 1 byte) för standard ZIP. För ZIP64 är den maximala storleken 18 446 744 073 709 551 615 bytes (264-1 bytes, eller 16 EiB minus 1 byte).
Proprietära tilläggEdit
Extra fältEdit
.ZIP-filformatet innehåller en funktion för extra fält i filhuvudet, som kan användas för att lagra extra data som inte definieras i befintliga ZIP-specifikationer och som gör det möjligt för kompatibla arkiverare som inte känner igen fälten att säkert hoppa över dem. Header ID 0-31 är reserverade för användning av PKWARE. Resterande ID:n kan användas av tredjepartsleverantörer för egen användning.
Kontrovers om stark krypteringRedigera
När WinZip 9.0 public beta släpptes 2003 införde WinZip sin egen AES-256-kryptering, med ett annat filformat, tillsammans med dokumentationen för den nya specifikationen. Krypteringsstandarderna i sig själva var inte äganderättsligt skyddade, men PKWARE hade inte uppdaterat APPNOTE.TXT för att inkludera Strong Encryption Specification (SES) sedan 2001, som hade använts av PKZIP versionerna 5.0 och 6.0. WinZips tekniska konsult Kevin Kearney och StuffIt:s produktchef Mathew Covington anklagade PKWARE för att undanhålla SES, men PKZIP:s teknikchef Jim Peterson hävdade att den certifikatsbaserade krypteringen fortfarande var ofullständig.
I ett annat kontroversiellt drag ansökte PKWare den 16 juli 2003 om ett patent som beskrev en metod för att kombinera ZIP och stark kryptering för att skapa en säker fil.
I slutändan kom PKWARE och WinZip överens om att stödja varandras produkter. Den 21 januari 2004 meddelade PKWARE att det finns stöd för det WinZip-baserade AES-komprimeringsformatet. I en senare version av WinZip beta kunde man stödja SES-baserade ZIP-filer. PKWARE släppte så småningom version 5.2 av .ZIP File Format Specification till allmänheten, där SES dokumenterades. Free Software-projektet 7-Zip har också stöd för AES, men inte SES i ZIP-filer (liksom dess POSIX-anpassning p7zip).
När AES-kryptering används i WinZip är komprimeringsmetoden alltid inställd på 99, med den faktiska komprimeringsmetoden lagrad i ett AES-extra datafält. Strong Encryption Specification lagrar däremot komprimeringsmetoden i det grundläggande filhuvudsegmentet för Local Header och Central Directory, såvida inte Central Directory Encryption används för att maskera/kryptera metadata.