.Fișierele ZIP sunt arhive care stochează mai multe fișiere. ZIP permite ca fișierele conținute să fie comprimate folosind mai multe metode diferite, precum și stocarea simplă a unui fișier fără a-l comprima. Fiecare fișier este stocat separat, ceea ce permite ca diferite fișiere din aceeași arhivă să fie comprimate folosind metode diferite. Deoarece fișierele dintr-o arhivă ZIP sunt comprimate individual, este posibil să le extrageți sau să adăugați altele noi, fără a aplica comprimarea sau decomprimarea întregii arhive. Acest lucru contrastează cu formatul fișierelor tar comprimate, pentru care o astfel de prelucrare cu acces aleatoriu nu este ușor de realizat.
Un director este plasat la sfârșitul unui fișier ZIP. Acesta identifică ce fișiere se află în ZIP și identifică unde în ZIP se află fișierul respectiv. Acest lucru permite cititorilor ZIP să încarce lista de fișiere fără a citi întreaga arhivă ZIP. Arhivele ZIP pot include, de asemenea, date suplimentare care nu au legătură cu arhiva ZIP. Acest lucru permite ca o arhivă ZIP să fie transformată într-o arhivă care se extrage singură (aplicație care își descompune datele conținute), prin adăugarea codului de program la o arhivă ZIP și marcarea fișierului ca fiind executabil. De asemenea, stocarea catalogului la sfârșit face posibilă ascunderea unui fișier ZIP prin adăugarea acestuia la un fișier inofensiv, cum ar fi un fișier de imagine GIF.
Formatul .ZIP utilizează un algoritm CRC pe 32 de biți și include două copii ale structurii de directoare a arhivei pentru a oferi o protecție mai mare împotriva pierderilor de date.
StructureEdit
Un fișier ZIP este identificat corect prin prezența unei înregistrări de sfârșit de director central, care se află la sfârșitul structurii arhivei pentru a permite adăugarea cu ușurință de noi fișiere. În cazul în care înregistrarea end of central directory indică o arhivă care nu este goală, numele fiecărui fișier sau director din cadrul arhivei ar trebui să fie specificat într-o intrare în directorul central, împreună cu alte metadate despre intrare și cu un offset în fișierul ZIP, care să indice datele de intrare efective. Acest lucru permite realizarea relativ rapidă a unei liste de fișiere din arhivă, deoarece nu este necesară citirea întregii arhive pentru a vedea lista de fișiere. Intrările din cadrul fișierului ZIP includ, de asemenea, aceste informații, pentru redundanță, într-un antet de fișier local. Deoarece fișierele ZIP pot fi anexate, numai fișierele specificate în directorul central de la sfârșitul fișierului sunt valabile. Scanarea unui fișier ZIP pentru anteturile locale ale fișierelor nu este valabilă (cu excepția arhivelor corupte), deoarece directorul central poate declara că unele fișiere au fost șterse și alte fișiere au fost actualizate.
De exemplu, putem începe cu un fișier ZIP care conține fișierele A, B și C. Fișierul B este apoi șters și C actualizat. Acest lucru poate fi realizat prin simpla adăugare a unui nou fișier C la sfârșitul fișierului ZIP original și prin adăugarea unui nou director central care listează doar fișierul A și noul fișier C. Când ZIP a fost conceput pentru prima dată, transferul de fișiere cu discheta era ceva obișnuit, însă scrierea pe dischete consuma foarte mult timp. Dacă aveați un fișier zip de mari dimensiuni, care se putea întinde pe mai multe discuri, și era nevoie să actualizați doar câteva fișiere, în loc să citiți și să rescrieți toate fișierele, ar fi fost mult mai rapid să citiți doar vechiul director central, să adăugați noile fișiere și apoi să adăugați un director central actualizat.
Ordinea intrărilor de fișiere din directorul central nu trebuie neapărat să coincidă cu ordinea intrărilor de fișiere din arhivă.
Care intrare stocată într-o arhivă ZIP este introdusă de un antet de fișier local cu informații despre fișier, cum ar fi comentariul, dimensiunea fișierului și numele fișierului, urmat de câmpuri de date „extra” opționale și apoi de datele fișierului, eventual comprimat, eventual criptat. Câmpurile de date „extra” reprezintă cheia extensibilității formatului ZIP. Câmpurile „extra” sunt exploatate pentru a suporta formatul ZIP64, criptarea AES compatibilă cu WinZip, atributele fișierelor și timestampurile de rezoluție mai mare ale fișierelor NTFS sau Unix. Alte extensii sunt posibile prin intermediul câmpului „Extra”. Instrumentele ZIP sunt obligate de specificație să ignore câmpurile Extra pe care nu le recunosc.
Formatul ZIP utilizează „semnături” specifice de 4 octeți pentru a desemna diferitele structuri din fișier. Fiecare intrare în fișier este marcată de o semnătură specifică. Sfârșitul înregistrării din directorul central este indicat cu semnătura sa specifică, iar fiecare intrare din directorul central începe cu semnătura de 4 octeți a antetului fișierului central.
Nu există niciun marker BOF sau EOF în specificația ZIP. În mod convențional, primul lucru dintr-un fișier ZIP este o intrare ZIP, care poate fi identificată cu ușurință prin semnătura antetului său de fișier local. Cu toate acestea, nu este neapărat cazul, deoarece acest lucru nu este cerut de specificația ZIP – în special, o arhivă autoextractantă va începe cu un antet de fișier executabil.
Uneltele care citesc corect arhivele ZIP trebuie să scaneze semnătura de sfârșit de înregistrare de director central și apoi, după caz, celelalte înregistrări de director central, indicate. Ele nu trebuie să scaneze pentru înregistrările din partea de sus a fișierului ZIP, deoarece (așa cum s-a menționat anterior în această secțiune) numai directorul central specifică unde începe o bucată de fișier și că aceasta nu a fost ștearsă. Scanarea ar putea duce la falsuri pozitive, deoarece formatul nu interzice ca alte date să se afle între chunks și nici ca fluxurile de date ale fișierelor să conțină astfel de semnături. Cu toate acestea, instrumentele care încearcă să recupereze date din arhive ZIP deteriorate vor scana, cel mai probabil, arhiva pentru semnături locale de antet de fișier; acest lucru este îngreunat de faptul că dimensiunea comprimată a unui fragment de fișier poate fi stocată după fragmentul de fișier, ceea ce îngreunează procesarea secvențială.
Majoritatea semnăturilor se termină cu numărul întreg scurt 0x4b50, care este stocat în ordine little-endian. Văzut ca un șir ASCII, acesta se citește „PK”, inițialele inventatorului Phil Katz. Astfel, atunci când un fișier ZIP este vizualizat într-un editor de text, primii doi octeți ai fișierului sunt, de obicei, „PK”. (ZIP-urile autoextractabile DOS, OS/2 și Windows au un EXE înaintea ZIP, deci încep cu „MZ”; ZIP-urile autoextractabile pentru alte sisteme de operare pot fi precedate în mod similar de un cod executabil pentru extragerea conținutului arhivei pe platforma respectivă.)
Specificația .ZIP suportă, de asemenea, răspândirea arhivelor pe mai multe fișiere din sistemul de fișiere. Inițial destinată stocării fișierelor ZIP de mari dimensiuni pe mai multe dischete, această caracteristică este acum utilizată pentru trimiterea arhivelor ZIP în părți prin e-mail, sau prin alte mijloace de transport sau suporturi detașabile.
Sistemul de fișiere FAT din DOS are o rezoluție a timestamp-ului de numai două secunde; înregistrările fișierelor ZIP imită acest lucru. Ca urmare, rezoluția încorporată a timestamp-ului fișierelor dintr-o arhivă ZIP este de numai două secunde, deși pot fi utilizate câmpuri suplimentare pentru a stoca timestamp-uri mai precise. Formatul ZIP nu are noțiunea de fus orar, astfel încât marcajele de timp sunt semnificative numai dacă se știe în ce fus orar au fost create.
În septembrie 2007, PKWARE a publicat o revizuire a specificației ZIP care prevede stocarea numelor de fișiere folosind UTF-8, adăugând în sfârșit compatibilitatea Unicode la ZIP.
Antetele fișierelorEdit
Toate valorile multibyte din antet sunt stocate în ordinea little-endian a octeților. Toate câmpurile de lungime numără lungimea în octeți.
În antet de fișier localEdit
| Offset | Biți | Descriere | |
|---|---|---|---|
| 0 | 4 | Semnătura antetului de fișier local = 0x04034b50 (se citește în ordine mică-endian number) | |
| 4 | 2 | Versiunea necesară pentru extragere (minimă) | |
| 6 | 2 | 2 | Semnalizator de bit de uz general |
| 8 | 2 | Metodă de compresie | |
| 10 | 2 | File last modification time | |
| 12 | 2 | File last modification date | |
| 14 | 4 | CRC-32 de date necomprimate | |
| 18 | 4 | Dimensiunea comprimată (sau 0xffffffff pentru ZIP64) | |
| 22 | 4 | Dimensiunea necomprimată (sau 0xffffffff pentru ZIP64) | |
| 26 | 2 | Lungimea numelui fișierului (n) | |
| 28 | 2 | Lungimea câmpului suplimentar (m) | |
| 30 | n | Numele fișierului | |
| 30+n | m | Câmp suplimentar |
Câmp suplimentar conține o varietate de date opționale cum ar fi OS-.atribute specifice sistemului de operare. Acesta este împărțit în bucăți, fiecare cu un cod ID de 16 biți și o lungime de 16 biți. Pentru ZIP64, există întotdeauna cel puțin un chunk (cu codul ID 0001 și dimensiunea de 32 de octeți), a se vedea mai jos.
Acesta este urmat imediat de datele comprimate.
Descriptor de dateEdit
Dacă bitul de la offset 3 (0x08) al câmpului general-purpose flags este setat, atunci CRC-32 și dimensiunile fișierelor nu sunt cunoscute atunci când se scrie antetul. Câmpurile din antetul local sunt completate cu zero, iar CRC-32 și dimensiunea sunt adăugate într-o structură de 12 octeți (precedată, opțional, de o semnătură de 4 octeți) imediat după datele comprimate:
| Offset | Bytes | Descriere |
|---|---|---|
| 0 | 0/4 | Semnătura descriptorului de date opțional = 0x08074b50 |
| 0/4 | 4 | CRC-32 de date necomprimate |
| 4/8 | 4 | Dimensiunea comprimată |
| 8/12 | 4 | Nu-comprimată size |
Antet fișier director centralEdit
Intrarea directorului central este o formă extinsă a antetului local:
| Offset | Bytes | Descriere |
|---|---|---|
| 0 | 4 | Centrală semnătura antetului fișierului director = 0x02014b50 |
| 4 | 2 | Versiunea realizată de |
| 6 | 2 | Versiunea necesară pentru extragere (minim) |
| 8 | 2 | Semnalizator de biți de uz general |
| 10 | 2 | Metoda de compresie |
| 12 | 2 | File last modification time |
| 14 | 2 | File last modification date |
| 16 | 4 | CRC-32 de date necomprimate |
| 20 | 4 | Dimensiunea comprimată (sau 0xffffffff pentru ZIP64) |
| 24 | 4 | Dimensiunea necomprimată (sau 0xffffffff pentru ZIP64) |
| 28 | 2 | Lungimea numelui fișierului (n) |
| 30 | 2 | Lungimea câmpului suplimentar (m) |
| 32 | 2 | Lungimea comentariului fișierului (k) |
| 34 | 2 | Numărul discului unde începe fișierul |
| 36 | 2 | Atribute interne ale fișierului |
| 38 | 4 | Atribute externe ale fișierului |
| 42 | 4 | Deslocarea relativă a antetului fișierului local. Acesta este numărul de octeți dintre începutul primului disc pe care apare fișierul și începutul antetului fișierului local. Aceasta permite software-ului care citește directorul central să localizeze poziția fișierului în cadrul fișierului ZIP. |
| 46 | n | Nume fișier |
| 46+n | m | Câmp suplimentar |
| 46+n+m | k | Comentariu fișier |
Sfârșitul înregistrării din directorul central (EOCD)Edit
După toate înregistrările din directorul central vine înregistrarea de sfârșit de director central (EOCD), care marchează sfârșitul fișierului ZIP:
| Offset | Bytes | Descriere |
|---|---|---|
| 0 | 4 | End of semnătura directorului central = 0x06054b50 |
| 4 | 2 | Numărul acestui disc |
| 6 | 2 | Disc în care se află directorul central începe |
| 8 | 2 | Numărul de înregistrări ale directorului central de pe acest disc |
| 10 | 2 | Numărul total de înregistrări ale directorului central înregistrări din directorul central |
| 12 | 4 | Dimensiunea directorului central (octeți) |
| 16 | 4 | Offset de început al directorului central, în raport cu începutul arhivei |
| 20 | 2 | Lungimea comentariului (n) |
| 22 | n | Comentariu |
Această ordonare permite crearea unui fișier ZIP într-o singură trecere, dar directorul central este, de asemenea, plasat la sfârșitul fișierului pentru a facilita eliminarea ușoară a fișierelor din mai multe părți (de ex.g. „multiple floppy-disk”), așa cum s-a discutat anterior.
Metode de compresieEdit
Specificația formatului de fișier .ZIP documentează următoarele metode de compresie: Store (fără compresie), Shrink (LZW), Reduce (nivelurile 1-4; LZ77 + probabilistic), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, și o variantă LZ77 furnizată de instrucțiunea IBM z/OS CMPSC. Cea mai frecvent utilizată metodă de compresie este DEFLATE, care este descrisă în IETF RFC 1951.
Alte metode menționate, dar care nu sunt documentate în detaliu în specificație includ: PKWARE DCL Implode (vechiul IBM TERSE), noul IBM TERSE, IBM LZ77 z Architecture (PFS), și o variantă JPEG. O metodă „Tokenize” a fost rezervată pentru o terță parte, dar suportul nu a fost niciodată adăugat.
Cuvântul Implode este folosit în exces de PKWARE: DCL/TERSE Implode este distinct de vechiul PKZIP Implode, un predecesor al Deflate. DCL Implode este nedocumentat parțial din cauza caracterului său proprietar deținut de IBM, dar Mark Adler a furnizat totuși un decompresor numit „blast” alături de zlib.
EncryptionEdit
ZIP suportă un sistem simplu de criptare simetrică bazat pe parolă, cunoscut în general sub numele de ZipCrypto. Acesta este documentat în specificația ZIP și se știe că este serios defectuos. În special, este vulnerabil la atacurile de tip „known-plaintext”, care, în unele cazuri, sunt înrăutățite de implementările slabe ale generatoarelor de numere aleatoare.
Noi caracteristici, inclusiv noi metode de compresie și criptare (de exemplu, AES) au fost documentate în specificația formatului de fișier ZIP începând cu versiunea 5.2. Un standard deschis bazat pe AES dezvoltat de WinZip („AE-x” în APPNOTE) este folosit, de asemenea, de 7-Zip și Xceed, dar unii vânzători folosesc alte formate. PKWARE SecureZIP (SES, proprietar) suportă, de asemenea, metodele de criptare RC2, RC4, DES, Triple DES, criptarea și autentificarea pe bază de certificat digital (X.509) și criptarea antetului arhivei. Cu toate acestea, este patentat (a se vedea § Controversă privind criptarea puternică).
Criptarea numelui fișierului este introdusă în .ZIP File Format Specification 6.2, care criptează metadatele stocate în porțiunea Central Directory a unei arhive, dar secțiunile Local Header rămân necriptate. Un arhivator compatibil poate falsifica datele din antetul local atunci când utilizează criptarea directoarei centrale. Începând cu versiunea 6.2 a specificației, câmpurile Compression Method (Metoda de compresie) și Compressed Size (Mărimea comprimată) din Local Header (Îndrumătorul local) nu sunt încă mascate.
ZIP64Edit
Formatul .ZIP original avea o limită de 4 GiB (232 octeți) pentru diverse lucruri (mărimea necomprimată a unui fișier, mărimea comprimată a unui fișier și mărimea totală a arhivei), precum și o limită de 65.535 (216) intrări într-o arhivă ZIP. În versiunea 4.5 a specificației (care nu este identică cu v4.5 a unui anumit instrument), PKWARE a introdus extensiile formatului „ZIP64” pentru a ocoli aceste limitări, mărind limitele la 16 EiB (264 octeți). În esență, se utilizează o intrare de director central „normală” pentru un fișier, urmată de o intrare de director „zip64” opțională, care are câmpurile mai mari.
Formul antetului fișierului local și al intrării în directorul central sunt aceleași în ZIP și ZIP64, dar pentru dimensiunile stocate întotdeauna 0xffffffff, iar un câmp suplimentar există întotdeauna:
.
.
Pe de altă parte, formatul EOCD pentru ZIP64 este ușor diferit de cel al versiunii ZIP normale (a se vedea secțiunea 4 din nota de aplicație.3.14).
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 4 | Finalul semnăturii directorului central = 0x06064b50 | |
| 4 | 8 | Dimensiunea EOCD64 – 8 | |
| 12 | 2 | Versiunea realizată de | |
| 14 | 2 | 2 | Versiunea necesară pentru extragere (minimă) |
| 16 | 4 | Numărul acestui disc | |
| 20 | 4 | Discul unde începe directorul central | |
| 24 | 8 | Numărul de înregistrări ale directorului central de pe acest disc | |
| 32 | 8 | Numărul total de înregistrări ale directorului central | |
| 40 | 8 | Dimensiunea directorului central (octeți) | |
| 48 | 8 | Offset de început al directorului central, în raport cu începutul arhivei | |
| 56 | n | Comentariu (până la dimensiunea EOCD64) |
De asemenea, nu este neapărat ultima înregistrare din arhivă, putând urma un localizator opțional de sfârșit de director central (20 de octeți suplimentari la sfârșit).
Exploratorul de fișiere din Windows XP nu acceptă ZIP64, dar cel din Windows Vista și versiunile ulterioare o fac. De asemenea, unele biblioteci de extensie acceptă ZIP64, cum ar fi DotNetZip, QuaZIP și IO::Compress::Zip în Perl. Fișierul zip încorporat în Python îl suportă începând cu versiunea 2.5 și îl utilizează în mod implicit începând cu versiunea 3.4. Java.util.zip încorporat în OpenJDK suportă ZIP64 începând cu versiunea Java 7. Android Java API suportă ZIP64 începând cu Android 6.0. Utilitarul de arhivă din Mac OS Sierra, în special, nu acceptă ZIP64 și poate crea arhive corupte atunci când ZIP64 ar fi necesar. Cu toate acestea, comanda ditto livrată cu Mac OS va descompune fișiere ZIP64. Versiunile mai recente ale Mac OS sunt livrate cu instrumentele de linie de comandă zip și unzip de la info-zip, care suportă Zip64: pentru a verifica, rulați zip -v și căutați „ZIP64_SUPPORT”.
Combinare cu alte formate de fișiereEdit
Formatul de fișier .ZIP permite ca la sfârșitul fișierului, după directorul central, să apară un comentariu care conține până la 65.535 (216-1) octeți de date. De asemenea, deoarece directorul central specifică decalajul fiecărui fișier din arhivă în raport cu începutul, este posibil ca prima intrare a fișierului să înceapă la un alt decalaj decât zero, deși unele instrumente, de exemplu gzip, nu vor procesa fișierele de arhivă care nu încep cu o intrare a fișierului la decalajul zero.
Acest lucru permite ca în fișier să apară date arbitrare atât înainte, cât și după datele arhivei ZIP, iar arhiva să fie în continuare citită de o aplicație ZIP. Un efect secundar al acestui lucru este că este posibil să se autorizeze un fișier care este atât o arhivă ZIP funcțională, cât și un alt format, cu condiția ca celălalt format să tolereze date arbitrare la sfârșitul, începutul sau mijlocul său. Arhivele autoextractabile (SFX), de tipul celor acceptate de WinZip, profită de acest lucru, în sensul că sunt fișiere executabile (.exe) care sunt conforme cu specificația PKZIP AppNote.txt și pot fi citite de instrumente sau biblioteci zip compatibile.
Această proprietate a formatului .ZIP și a formatului JAR, care este o variantă a ZIP, poate fi exploatată pentru a ascunde conținut necinstit (cum ar fi clase Java dăunătoare) în interiorul unui fișier aparent inofensiv, cum ar fi o imagine GIF încărcată pe web. Acest așa-numit exploit GIFAR a fost demonstrat ca fiind un atac eficient împotriva aplicațiilor web, cum ar fi Facebook.
LimitsEdit
Dimensiunea minimă a unui fișier .ZIP este de 22 de octeți. Un astfel de fișier zip gol conține doar o înregistrare End of Central Directory Record (EOCD):
Dimensiunea maximă atât a fișierului de arhivă, cât și a fișierelor individuale din interiorul acestuia este de 4.294.967.295 octeți (232-1 octeți, sau 4 GiB minus 1 octet) pentru ZIP standard. Pentru ZIP64, dimensiunea maximă este de 18.446.744.073.709.551.615 octeți (264-1 octeți, sau 16 EiB minus 1 octet).
Extensii proprietareEdit
Extra fieldEdit
.Formatul de fișier ZIP include o facilitate de câmp suplimentar în cadrul antetelor de fișier, care poate fi utilizată pentru a stoca date suplimentare care nu sunt definite de specificațiile ZIP existente și care permit arhivelor conforme care nu recunosc câmpurile să le ignore în siguranță. ID-urile de antet 0-31 sunt rezervate pentru a fi utilizate de PKWARE. ID-urile rămase pot fi folosite de către vânzătorii terți pentru utilizări proprietare.
Controversă privind criptarea puternicăEdit
Când WinZip 9.0 public beta a fost lansat în 2003, WinZip a introdus propria sa criptare AES-256, folosind un format de fișier diferit, împreună cu documentația pentru noua specificație. Standardele de criptare în sine nu erau brevetate, dar PKWARE nu mai actualizase APPNOTE.TXT pentru a include specificația Strong Encryption Specification (SES) din 2001, care fusese utilizată de versiunile PKZIP 5.0 și 6.0. Consultantul tehnic WinZip Kevin Kearney și managerul de produs StuffIt, Mathew Covington, au acuzat PKWARE că a reținut SES, dar directorul tehnologic al PKZIP, Jim Peterson, a susținut că criptarea bazată pe certificate era încă incompletă.
Într-o altă mișcare controversată, PKWare a depus o cerere de brevet la 16 iulie 2003, descriind o metodă de combinare a ZIP și a criptării puternice pentru a crea un fișier securizat.
În cele din urmă, PKWARE și WinZip au fost de acord să își susțină reciproc produsele. La 21 ianuarie 2004, PKWARE a anunțat suportul pentru formatul de compresie AES bazat pe WinZip. Într-o versiune ulterioară a versiunii beta a WinZip, acesta a fost capabil să suporte fișiere ZIP bazate pe SES. În cele din urmă, PKWARE a făcut publică versiunea 5.2 a specificației formatului de fișier .ZIP, care documenta SES. Proiectul de software liber 7-Zip suportă, de asemenea, AES, dar nu SES în fișierele ZIP (la fel ca și portul său POSIX p7zip).
Când se utilizează criptarea AES în WinZip, metoda de compresie este întotdeauna setată la 99, cu metoda de compresie reală stocată într-un câmp de date suplimentare AES. În schimb, Specificația de criptare puternică stochează metoda de compresie în segmentul de bază al antetului de fișier al antetului local și al directorului central, cu excepția cazului în care criptarea directorului central este utilizată pentru a masca/cripta metadatele.
.