.ZIP-filer er arkiver, der gemmer flere filer. ZIP gør det muligt at komprimere indeholdte filer ved hjælp af mange forskellige metoder, ligesom det også er muligt blot at gemme en fil uden at komprimere den. Hver fil lagres separat, hvilket gør det muligt at komprimere forskellige filer i det samme arkiv ved hjælp af forskellige metoder. Fordi filerne i et ZIP-arkiv komprimeres individuelt, er det muligt at udtrække dem eller tilføje nye filer uden at anvende komprimering eller dekomprimering på hele arkivet. Dette står i modsætning til formatet for komprimerede tar-filer, for hvilke en sådan behandling med tilfældig adgang ikke er let mulig.
En mappe er placeret i slutningen af en ZIP-fil. Dette identificerer, hvilke filer der er i ZIP’en, og det identificerer, hvor i ZIP’en den pågældende fil er placeret. Dette gør det muligt for ZIP-læsere at indlæse listen over filer uden at læse hele ZIP-arkivet. ZIP-arkiver kan også indeholde ekstra data, der ikke er relateret til ZIP-arkivet. Dette gør det muligt at gøre et ZIP-arkiv til et selvudtrækkende arkiv (program, der dekomprimerer de indeholdte data) ved at tilføje programkoden til et ZIP-arkiv og markere filen som eksekverbar. Ved at gemme kataloget i slutningen er det også muligt at skjule en zippet fil ved at vedhæfte den til en uskadelig fil, f.eks. en GIF-billedfil.
Det .ZIP-format anvender en 32-bit CRC-algoritme og indeholder to kopier af arkivets mappestruktur for at give større beskyttelse mod tab af data.
StructureEdit
En ZIP-fil identificeres korrekt ved tilstedeværelsen af en end of central directory record, som er placeret i slutningen af arkivstrukturen for at gøre det nemt at tilføje nye filer. Hvis end of central directory record angiver et arkiv, der ikke er tomt, skal navnet på hver fil eller mappe i arkivet angives i en central directory entry sammen med andre metadata om entryet og en offset i ZIP-filen, der peger på de faktiske entrydata. Dette gør det muligt at udføre en filoplistning af arkivet relativt hurtigt, da hele arkivet ikke skal læses for at se listen over filer. Posterne i ZIP-filen indeholder også disse oplysninger af redundanshensyn i en lokal filoverskrift. Da ZIP-filer kan tilføjes, er det kun de filer, der er angivet i den centrale mappe i slutningen af filen, der er gyldige. Scanning af en ZIP-fil for lokale filoverskrifter er ugyldig (undtagen i tilfælde af beskadigede arkiver), da den centrale mappe kan erklære, at nogle filer er blevet slettet og andre filer er blevet opdateret.
For eksempel kan vi starte med en ZIP-fil, der indeholder filerne A, B og C. Fil B bliver derefter slettet og C opdateret. Dette kan opnås ved blot at føje en ny fil C til slutningen af den oprindelige ZIP-fil og tilføje en ny central mappe, der kun indeholder fil A og den nye fil C. Da ZIP først blev designet, var det almindeligt at overføre filer via diskette, men det var meget tidskrævende at skrive til disketter. Hvis man havde en stor zip-fil, der muligvis dækkede flere diske, og kun skulle opdatere nogle få filer, ville det være betydeligt hurtigere end at læse og skrive alle filerne igen, hvis man blot læste den gamle centrale mappe, tilføjede de nye filer og derefter tilføjede en opdateret central mappe.
Rækkefølgen af filposterne i den centrale mappe behøver ikke at være sammenfaldende med rækkefølgen af filposterne i arkivet.
Hver post gemt i et ZIP-arkiv indledes med en lokal filheader med oplysninger om filen såsom kommentar, filstørrelse og filnavn, efterfulgt af valgfrie “ekstra” datafelter, og derefter de eventuelt komprimerede, eventuelt krypterede fildata. De “ekstra” datafelter er nøglen til ZIP-formatets udvidelsesmuligheder. “Ekstra” felter udnyttes til at understøtte ZIP64-formatet, WinZip-kompatibel AES-kryptering, filattributter og NTFS- eller Unix-filtidsangivelser i højere opløsning. Andre udvidelser er mulige via “Extra”-feltet. ZIP-værktøjer skal ifølge specifikationen ignorere Extra-felter, som de ikke genkender.
ZIP-formatet anvender specifikke 4-byte “signaturer” til at betegne de forskellige strukturer i filen. Hver filpost er markeret med en specifik signatur. Slutningen af den centrale mappepost er angivet med sin specifikke signatur, og hver post i den centrale mappe starter med den centrale filhoved-signatur på 4 byte.
Der er ingen BOF- eller EOF-markør i ZIP-specifikationen. Konventionelt er den første ting i en ZIP-fil en ZIP-post, som let kan identificeres ved hjælp af dens lokale filhoved-signatur. Dette er imidlertid ikke nødvendigvis tilfældet, da dette ikke kræves af ZIP-specifikationen – især vil et selvudtrækkende arkiv begynde med en eksekverbar filheader.
Værktøjer, der korrekt læser ZIP-arkiver, skal scanne efter signaturen for slutningen af den centrale mapperegistrering og derefter, alt efter omstændighederne, de andre, angivne, centrale mapperegistreringer. De skal ikke scanne efter poster fra toppen af ZIP-filen, fordi (som tidligere nævnt i dette afsnit) kun den centrale mappe angiver, hvor en filklump starter, og at den ikke er blevet slettet. Scanning kan føre til falske positive resultater, da formatet ikke forbyder, at der er andre data mellem chunks, og heller ikke at fildatastrømme indeholder sådanne signaturer. Værktøjer, der forsøger at gendanne data fra beskadigede ZIP-arkiver, vil dog højst sandsynligt scanne arkivet for lokale filheader-signaturer; dette vanskeliggøres af, at den komprimerede størrelse af en fil chunk kan være gemt efter fil chunken, hvilket gør sekventiel behandling vanskelig.
De fleste af signaturerne slutter med det korte hele tal 0x4b50, som er gemt i little-endian-ordre. Set som en ASCII-streng lyder dette “PK”, initialerne for opfinderen Phil Katz. Når en ZIP-fil ses i en teksteditor, er de første to bytes i filen derfor normalt “PK”. (DOS-, OS/2- og Windows-selvudtrækkende ZIP-filer har en EXE foran ZIP-koden, så de starter med “MZ”; selvudtrækkende ZIP-filer til andre operativsystemer kan på samme måde blive indledt af eksekverbar kode til udtrækning af arkivets indhold på den pågældende platform.)
Den .ZIP-specifikation understøtter også spredning af arkiver over flere filsystemfiler. Denne funktion, der oprindeligt var beregnet til lagring af store ZIP-filer på flere disketter, bruges nu til at sende ZIP-arkiver i dele over e-mail eller over andre transportmidler eller flytbare medier.
DOS’ FAT-filsystem har en tidsstempelopløsning på kun to sekunder; ZIP-filoptegnelser efterligner dette. Som følge heraf er den indbyggede tidsstempelopløsning for filer i et ZIP-arkiv kun to sekunder, selv om der kan bruges ekstra felter til at gemme mere præcise tidsstempler. ZIP-formatet har ikke noget begreb om tidszone, så tidsstempler er kun meningsfulde, hvis det er kendt, hvilken tidszone de blev oprettet i.
I september 2007 udgav PKWARE en revision af ZIP-specifikationen, der giver mulighed for lagring af filnavne med UTF-8, hvilket endelig tilføjede Unicode-kompatibilitet til ZIP.
FiloverskrifterRediger
Alle multibyte-værdier i overskriften lagres i little-endian-byteorden. Alle længdefelter tæller længden i bytes.
Lokal filheaderRediger
| Offset | Bytes | Beskrivelse | |
|---|---|---|---|
| 0 | 4 | Lokal filheader signatur = 0x04034b50 (læses som en little-endian tal) | |
| 4 | 2 | Version nødvendig for at udtrække (minimum) | |
| 6 | 2 | General purpose bit flag | |
| 8 | 2 | 2 | Komprimeringsmetode |
| 10 | 2 | Sidste ændringstidspunkt for filen | |
| 12 | 2 | Sidste ændringsdato for filen | |
| 14 | 4 | CRC-32 ukomprimerede data | |
| 18 | 4 | Komprimeret størrelse (eller 0xffffffffffffff for ZIP64) | |
| 22 | 22 | 4 | Ukomprimeret størrelse (eller 0xffffffffffffff for ZIP64) |
| 26 | 2 | Filnavnets længde (n) | |
| 28 | 2 | Ekstra feltlængde (m) | |
| 30 | n | Filnavn | |
| 30+n | m | Ekstra felt |
Det ekstra felt indeholder en række valgfrie data, såsom OS-specifikke attributter. Det er opdelt i chunks, hver med en 16-bit ID-kode og en 16-bit længde. For ZIP64 findes der altid mindst én chunk (med ID-kode 0001 og en størrelse på 32 bytes), se nedenfor.
Dette efterfølges umiddelbart af de komprimerede data.
DatadeskriptorRediger
Hvis bit på offset 3 (0x08) i det generelle flagfelt er sat, er CRC-32 og filstørrelser ikke kendt, når header’en skrives. Felterne i den lokale header udfyldes med nul, og CRC-32 og størrelsen tilføjes i en 12-byte struktur (eventuelt med en 4-byte signatur foran) umiddelbart efter de komprimerede data:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 0/4 | Valgfri datadeskriptorsignatur = 0x08074b50 |
| 0/4 | 4 | CRC-32 ukomprimerede data |
| 4/8 | 4 | komprimeret størrelse |
| 8/12 | 4 | ukomprimeret size |
Central directory file headerEdit
Den centrale mappepost er en udvidet form af den lokale header:
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 4 | Central mappefilens header-signatur = 0x02014b50 | |
| 4 | 2 | Version lavet af | |
| 6 | 2 | 2 | Version nødvendig for at udtrække (minimum) |
| 8 | 2 | General purpose bit flag | |
| 10 | 2 | 2 | Komprimeringsmetode |
| 12 | 2 | Sidste ændringstidspunkt for filen | |
| 14 | 2 | Sidste ændringsdato for filen | |
| 16 | 4 | CRC-32 ukomprimerede data | |
| 20 | 4 | Komprimeret størrelse (eller 0xffffffffffffff for ZIP64) | |
| 24 | 4 | Ukomprimeret størrelse (eller 0xffffffffffffffff for ZIP64) | |
| 28 | 2 | Filnavnets længde (n) | |
| 30 | 2 | Ekstra feltlængde (m) | |
| 32 | 2 | Filkommentarlængde (k) | |
| 34 | 2 | Disknummer, hvor filen starter | |
| 36 | 2 | 2 | Interne filattributter |
| 38 | 4 | Eksterne filattributter | |
| 42 | 4 | Relativ offset af lokal filhoved. Dette er antallet af bytes mellem starten af den første disk, hvor filen findes, og starten af den lokale filhovedetekst. Dette gør det muligt for software, der læser den centrale mappe, at lokalisere filens position i ZIP-filen. | |
| 46 | n | Filnavn | |
| 46+n | m | Extra felt | |
| 46+n+m | k | Filkommentar |
End of central directory record (EOCD)Rediger
Efter alle central directory-poster kommer end of central directory (EOCD)-posten, som markerer slutningen af ZIP-filen:
| Offset | Bytes | Beskrivelse |
|---|---|---|
| 0 | 4 | End of centralmappens signatur = 0x06054b50 |
| 4 | 2 | Nummer på denne disk |
| 6 | 2 | Disk hvor centralmappen starter |
| 8 | 2 | Antal poster i centralmappen på denne disk |
| 10 | 2 | Total antal poster i centralmappen på denne disk |
| 10 | Total antal poster i centralmappen poster i centralmappen | |
| 12 | 4 | Størrelse på centralmappen (bytes) |
| 16 | 4 | Offset for starten på centralmappen, i forhold til starten af arkivet |
| 20 | 2 | Kommentarlængde (n) |
| 22 | n | Kommentar |
Denne rækkefølge gør det muligt at oprette en ZIP-fil i én arbejdsgang, men den centrale mappe er også placeret i slutningen af filen for at gøre det nemmere at fjerne filer fra flere dele (f.eks.f.eks. “multiple floppy-disk”) arkiver, som tidligere omtalt.
KomprimeringsmetoderRediger
Den .ZIP File Format Specification dokumenterer følgende komprimeringsmetoder: Store (ingen komprimering), Shrink (LZW), Reduce (niveau 1-4; LZ77 + probabilistisk), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd og en LZ77-variant, der leveres af IBM z/OS CMPSC-instruktionen. Den mest almindeligt anvendte komprimeringsmetode er DEFLATE, som er beskrevet i IETF RFC 1951.
Andre metoder, der nævnes, men som ikke er dokumenteret i detaljer i specifikationen, omfatter bl.a: PKWARE DCL Implode (gammel IBM TERSE), ny IBM TERSE, IBM LZ77 z Architecture (PFS) og en JPEG-variant. En “Tokenize”-metode blev reserveret til en tredjepart, men understøttelse blev aldrig tilføjet.
Ordet Implode overforbruges af PKWARE: DCL/TERSE Implode er forskellig fra den gamle PKZIP Implode, en forgænger til Deflate. DCL Implode er udokumenteret delvist på grund af dens ejendomsretlige karakter, som IBM har, men Mark Adler har ikke desto mindre leveret en dekompressor kaldet “blast” sammen med zlib.
KrypteringRediger
ZIP understøtter et simpelt password-baseret symmetrisk krypteringssystem, der generelt er kendt som ZipCrypto. Det er dokumenteret i ZIP-specifikationen og er kendt for at være alvorligt mangelfuldt. Det er især sårbart over for known-plaintext-angreb, som i nogle tilfælde forværres af dårlige implementeringer af tilfældigt talgeneratorer.
Nye funktioner, herunder nye komprimerings- og krypteringsmetoder (f.eks. AES), er blevet dokumenteret i ZIP File Format Specification siden version 5.2. En WinZip-udviklet AES-baseret åben standard (“AE-x” i APPNOTE) anvendes også af 7-Zip og Xceed, men nogle leverandører anvender andre formater. PKWARE SecureZIP (SES, proprietær) understøtter også RC2, RC4, DES, Triple DES-krypteringsmetoder, digital certifikatbaseret kryptering og autentificering (X.509) samt kryptering af arkivhovedet. Den er dog patenteret (se § Stærk kryptering kontrovers).
Filnavnskryptering er indført i .ZIP File Format Specification 6.2, som krypterer metadata gemt i Central Directory-delen af et arkiv, men Local Header-sektionerne forbliver ukrypterede. En arkiveringsenhed, der opfylder kravene, kan forfalske dataene i Local Header, når den anvender kryptering af Central Directory. Fra og med version 6.2 af specifikationen er felterne Komprimeringsmetode og Komprimeret størrelse i Local Header endnu ikke maskeret.
ZIP64Edit
Det oprindelige .ZIP-format havde en grænse på 4 GiB (232 bytes) for forskellige ting (ukomprimeret størrelse af en fil, komprimeret størrelse af en fil og arkivets samlede størrelse) samt en grænse på 65.535 (216) poster i et ZIP-arkiv. I version 4.5 af specifikationen (som ikke er det samme som v4.5 af et bestemt værktøj) indførte PKWARE udvidelserne til “ZIP64”-formatet for at omgå disse begrænsninger og hævede grænserne til 16 EiB (264 bytes). I det væsentlige anvendes der en “normal” central mappepost for en fil, efterfulgt af en valgfri “zip64”-mappepost, som har de større felter.
formatet for Local file header og Central directory entry er det samme i ZIP og ZIP64, men for størrelser altid 0xffffffffffffff gemt, og der findes altid et ekstra felt:
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 2 | Header ID 0x0001 | |
| 2 | 2 | 2 | Størrelse af det ekstra felt chunk (16, 24 eller 28) |
| 4 | 8 | Original ukomprimeret filstørrelse | |
| 12 | 8 | Størrelse af komprimerede data | |
| 20 | 8 | Offset for lokal header record | |
| 28 | 4 | Nummeret på den disk, som denne fil starter på |
På den anden side, er formatet af EOCD for ZIP64 en smule anderledes end den normale ZIP-version (se appnote afsnit 4.3.14).
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | Slutning af signatur for centralmappe = 0x06064b50 |
| 4 | 8 | Størrelse af EOCD64 – 8 |
| 12 | 2 | Version lavet af |
| 14 | 2 | Version nødvendig for at udtrække (minimum) |
| 16 | 4 | Nummer på denne disk |
| 20 | 4 | Disk, hvor den centrale mappe starter |
| 24 | 8 | Antal af poster i centralmappen på denne disk |
| 32 | 8 | Totalt antal poster i centralmappen |
| 40 | 8 | Størrelse af centralmappen (bytes) |
| 48 | 8 | Offset for starten af centralmappen, i forhold til arkivets start |
| 56 | n | Kommentar (op til størrelsen af EOCD64) |
Det er heller ikke nødvendigvis den sidste post i filen, en valgfri End of Central Directory Locator kan følge (yderligere 20 bytes i slutningen).
Filudforskeren i Windows XP understøtter ikke ZIP64, men det gør udforskeren i Windows Vista og nyere versioner. Ligeledes understøtter nogle udvidelsesbiblioteker ZIP64, f.eks. DotNetZip, QuaZIP og IO::Compress::Zip i Perl. Pythons indbyggede zipfile har understøttet det siden 2.5 og er standardindstillet til det siden 3.4. OpenJDK’s indbyggede java.util.zip understøtter ZIP64 fra version Java 7. Android Java API understøtter ZIP64 siden Android 6.0. Mac OS Sierra’s Archive Utility understøtter navnlig ikke ZIP64 og kan skabe korrupte arkiver, når ZIP64 ville være påkrævet. Ditto-kommandoen, der leveres med Mac OS, kan dog udpakke ZIP64-filer. Nyere versioner af Mac OS leveres med info-zip’s zip- og unzip-kommandolinjeværktøjer, som understøtter Zip64: for at verificere kan du køre zip -v og kigge efter “ZIP64_SUPPORT”.
Kombination med andre filformaterRediger
Den .ZIP-filformatet giver mulighed for en kommentar indeholdende op til 65.535 (216-1) bytes data til at forekomme i slutningen af filen efter den centrale mappe. Da den centrale mappe desuden angiver offset for hver fil i arkivet i forhold til starten, er det muligt for den første filpost at starte ved en anden offset end nul, selv om nogle værktøjer, f.eks. gzip, ikke vil behandle arkivfiler, der ikke starter med en filpost ved offset nul.
Dette giver mulighed for, at der kan forekomme vilkårlige data i filen både før og efter ZIP-arkivets data, og at arkivet stadig kan læses af et ZIP-program. En sideeffekt af dette er, at det er muligt at oprette en fil, der både er et fungerende ZIP-arkiv og et andet format, forudsat at det andet format tolererer arbitrære data i slutningen, begyndelsen eller midten. Selvudtrækkende arkiver (SFX) af den form, der understøttes af WinZip, udnytter dette, idet de er eksekverbare (.exe) filer, der er i overensstemmelse med PKZIP AppNote.txt-specifikationen og kan læses af ZIP-værktøjer eller -biblioteker, der opfylder kravene.
Denne egenskab ved .ZIP-formatet og ved JAR-formatet, som er en variant af ZIP, kan udnyttes til at skjule skadeligt indhold (f.eks. skadelige Java-klasser) i en tilsyneladende harmløs fil, f.eks. et GIF-billede, der uploades til internettet. Denne såkaldte GIFAR-udnyttelse er blevet demonstreret som et effektivt angreb mod webapplikationer som f.eks. Facebook.
LimitsEdit
Den mindste størrelse af en .ZIP-fil er 22 bytes. En sådan tom zip-fil indeholder kun en End of Central Directory Record (EOCD):
Den maksimale størrelse for både arkivfilen og de enkelte filer i den er 4 294 967 295 bytes (232-1 bytes, eller 4 GiB minus 1 byte) for standard ZIP. For ZIP64 er den maksimale størrelse 18.446.744.073.073.709.551.615 bytes (264-1 bytes, eller 16 EiB minus 1 byte).
Proprietære udvidelserRediger
Ekstra feltRediger
.ZIP-filformatet indeholder en facilitet for ekstra felter i filoverskrifter, som kan bruges til at lagre ekstra data, der ikke er defineret i de eksisterende ZIP-specifikationer, og som gør det muligt for kompatible arkiveringsenheder, der ikke genkender felterne, at springe dem sikkert over. Header ID’er 0-31 er reserveret til brug for PKWARE. De resterende ID’er kan anvendes af tredjepartsleverandører til proprietær brug.
Kontrovers om stærk krypteringRediger
Da WinZip 9.0 public beta blev frigivet i 2003, introducerede WinZip sin egen AES-256-kryptering, der anvender et andet filformat, sammen med dokumentationen for den nye specifikation. Krypteringsstandarderne i sig selv var ikke proprietære, men PKWARE havde ikke opdateret APPNOTE.TXT til at omfatte Strong Encryption Specification (SES) siden 2001, som havde været anvendt af PKZIP-versionerne 5.0 og 6.0. WinZip’s tekniske konsulent Kevin Kearney og StuffIt’s produktchef Mathew Covington beskyldte PKWARE for at tilbageholde SES, men PKZIP’s teknologichef Jim Peterson hævdede, at den certifikatbaserede kryptering stadig var ufuldstændig.
I et andet kontroversielt træk ansøgte PKWare den 16. juli 2003 om et patent, der beskrev en metode til at kombinere ZIP og stærk kryptering for at skabe en sikker fil.
I sidste ende blev PKWARE og WinZip enige om at støtte hinandens produkter. Den 21. januar 2004 meddelte PKWARE, at det WinZip-baserede AES-komprimeringsformat blev understøttet. I en senere version af WinZip beta var den i stand til at understøtte SES-baserede ZIP-filer. PKWARE frigav til sidst version 5.2 af .ZIP File Format Specification til offentligheden, som dokumenterede SES. Free Software-projektet 7-Zip understøtter også AES, men ikke SES i ZIP-filer (ligesom dets POSIX-port p7zip).
Ved brug af AES-kryptering under WinZip er komprimeringsmetoden altid indstillet til 99, og den faktiske komprimeringsmetode er gemt i et ekstra AES-datafelt. I modsætning hertil gemmer Strong Encryption Specification komprimeringsmetoden i det grundlæggende filheader-segment i Local Header og Central Directory, medmindre Central Directory Encryption anvendes til at maskere/kryptere metadata.