.Soubory ZIP jsou archivy, které uchovávají více souborů. ZIP umožňuje obsažené soubory komprimovat pomocí mnoha různých metod, stejně jako jednoduše uložit soubor bez komprese. Každý soubor je uložen samostatně, což umožňuje komprimovat různé soubory ve stejném archivu pomocí různých metod. Protože jsou soubory v archivu ZIP komprimovány jednotlivě, je možné je extrahovat nebo přidávat nové, aniž by bylo nutné použít kompresi nebo dekompresi celého archivu. To kontrastuje s formátem komprimovaných souborů tar, u nichž není takové zpracování s náhodným přístupem snadno možné.
Na konci souboru ZIP je umístěn adresář. Ten identifikuje, jaké soubory jsou v souboru ZIP, a určuje, kde v souboru ZIP se daný soubor nachází. To umožňuje čtečkám ZIP načíst seznam souborů, aniž by musely číst celý archiv ZIP. Archivy ZIP mohou také obsahovat další data, která nesouvisejí s archivem ZIP. To umožňuje vytvořit z archivu ZIP samorozbalovací archiv (aplikaci, která dekomprimuje obsažená data), a to tak, že se do archivu ZIP předem přidá kód programu a soubor se označí jako spustitelný. Uložení katalogu na konec také umožňuje skrýt zazipovaný soubor jeho připojením k neškodnému souboru, například obrázkovému souboru GIF.
Formát .ZIP používá 32bitový algoritmus CRC a obsahuje dvě kopie adresářové struktury archivu, aby byla zajištěna větší ochrana proti ztrátě dat.
StructureEdit
Soubor ZIP je správně identifikován podle přítomnosti záznamu o konci centrálního adresáře, který je umístěn na konci struktury archivu, aby bylo možné snadno připojovat nové soubory. Pokud záznam o konci centrálního adresáře označuje neprázdný archiv, měl by být název každého souboru nebo adresáře v archivu uveden v záznamu centrálního adresáře spolu s dalšími metadaty o záznamu a odsazením do souboru ZIP, které ukazuje na skutečné vstupní údaje. To umožňuje relativně rychle provést výpis souborů v archivu, protože pro zobrazení seznamu souborů není nutné číst celý archiv. Záznamy v souboru ZIP obsahují tyto informace pro nadbytečnost také v místním záhlaví souboru. Protože soubory ZIP mohou být doplněny, platí pouze soubory uvedené v centrálním adresáři na konci souboru. Skenování souboru ZIP na lokální hlavičky souborů je neplatné (s výjimkou poškozených archivů), protože centrální adresář může deklarovat, že některé soubory byly odstraněny a jiné soubory byly aktualizovány.
Například můžeme začít se souborem ZIP, který obsahuje soubory A, B a C. Soubor B je pak odstraněn a C aktualizován. Toho lze dosáhnout pouhým připojením nového souboru C na konec původního souboru ZIP a přidáním nového centrálního adresáře, který obsahuje pouze soubor A a nový soubor C. Když byl soubor ZIP poprvé navržen, byl přenos souborů pomocí disket běžný, avšak zápis na disky byl velmi časově náročný. Pokud jste měli velký soubor ZIP, který se případně rozkládal na více discích, a potřebovali jste aktualizovat pouze několik souborů, bylo by podstatně rychlejší než číst a znovu zapisovat všechny soubory pouze přečíst starý centrální adresář, připojit nové soubory a poté připojit aktualizovaný centrální adresář.
Pořadí položek souborů v centrálním adresáři se nemusí shodovat s pořadím položek souborů v archivu.
Každá položka uložená v archivu ZIP je uvozena lokální hlavičkou souboru s informacemi o souboru, jako je komentář, velikost a název souboru, následují volitelná „extra“ datová pole a pak případně komprimovaná, případně šifrovaná data souboru. Datová pole „navíc“ jsou klíčem k rozšiřitelnosti formátu ZIP. „Extra“ pole se využívají k podpoře formátu ZIP64, šifrování AES kompatibilního s WinZip, atributů souborů a časových značek souborů NTFS nebo Unix s vyšším rozlišením. Další rozšíření jsou možná prostřednictvím pole „Extra“. Specifikace vyžaduje, aby nástroje ZIP ignorovaly pole „Extra“, která nerozpoznávají.
Formát ZIP používá specifické čtyřbytové „podpisy“ pro označení různých struktur v souboru. Každá položka souboru je označena specifickou signaturou. Konec záznamu centrálního adresáře je označen jeho specifickou signaturou a každý záznam v centrálním adresáři začíná 4bajtovou signaturou centrální hlavičky souboru.
Ve specifikaci ZIP není žádná značka BOF nebo EOF. Obvykle je první věcí v souboru ZIP záznam ZIP, který lze snadno identifikovat podle signatury lokálního záhlaví souboru. To však není nezbytně nutné, protože to specifikace ZIP nevyžaduje – především samorozbalovací archiv začíná hlavičkou spustitelného souboru.
Nástroje, které správně čtou archivy ZIP, musí hledat signaturu konce záznamu centrálního adresáře a pak případně další označené záznamy centrálního adresáře. Nesmějí skenovat záznamy z horní části souboru ZIP, protože (jak již bylo uvedeno v této části) pouze centrální adresář určuje, kde začíná část souboru a že nebyla smazána. Skenování by mohlo vést k falešně pozitivním výsledkům, protože formát nezakazuje, aby se mezi chunky nacházela jiná data, ani aby datové proudy souborů obsahovaly takovéto signatury. Nicméně nástroje, které se pokoušejí obnovit data z poškozených archivů ZIP, budou s největší pravděpodobností skenovat archiv na lokální signatury hlaviček souborů; to je ztíženo tím, že komprimovaná velikost chunku souboru může být uložena až za chunkem souboru, což ztěžuje sekvenční zpracování.
Většina signatur končí krátkým celým číslem 0x4b50, které je uloženo v little-endian uspořádání. Při pohledu na tento řetězec ASCII se čte „PK“, což jsou iniciály vynálezce Phila Katze. Při zobrazení souboru ZIP v textovém editoru jsou tedy první dva bajty souboru obvykle „PK“. (Samorozbalovací ZIPy pro DOS, OS/2 a Windows mají před ZIPem EXE, takže začínají „MZ“; samorozbalovacím ZIPům pro jiné operační systémy může podobně předcházet spustitelný kód pro extrakci obsahu archivu na dané platformě.“
Specifikace .ZIP podporuje také rozprostření archivů do více souborů souborového systému. Původně byla tato funkce určena pro ukládání velkých souborů ZIP na více disketách, nyní se používá pro posílání archivů ZIP po částech e-mailem nebo přes jiné přenosy či vyměnitelná média.
Systém souborů FAT systému DOS má rozlišení časových značek pouze dvě sekundy; záznamy souborů ZIP to napodobují. V důsledku toho je vestavěné rozlišení časových značek souborů v archivu ZIP pouze dvě sekundy, ačkoli k uložení přesnějších časových značek lze použít další pole. Formát ZIP nemá pojem časového pásma, takže časové značky mají smysl pouze tehdy, je-li známo, v jakém časovém pásmu byly vytvořeny.
V září 2007 vydala společnost PKWARE revizi specifikace ZIP umožňující ukládání názvů souborů pomocí UTF-8, čímž byla do formátu ZIP konečně přidána kompatibilita s Unicode.
Záhlaví souborůUpravit
Všechny vícebajtové hodnoty v záhlaví jsou uloženy v little-endian pořadí bajtů. Všechna délková pole počítají délku v bajtech.
Místní hlavička souboruEdit
| Osazení | Bajty | Popis |
|---|---|---|
| 0 | 4 | Podpis místní hlavičky souboru = 0x04034b50 (čte se jako little-endi).endiánské číslo) |
| 4 | 2 | Verze potřebná k extrakci (minimální) |
| 6 | 2 | Příznak bitů pro obecné účely |
| 8 | 2 | Metoda komprese |
| 10 | 2 | Čas poslední modifikace souboru |
| 12 | 2 | Datum poslední modifikace souboru |
| 14 | 4 | CRC-32 nekomprimovaných dat |
| 18 | 4 | Komprimovaná velikost (nebo 0xffffffff pro ZIP64) |
| 22 | 4 | Nekomprimovaná velikost (nebo 0xffffffff pro ZIP64) |
| 26 | 2 | Délka názvu souboru (n) |
| 28 | 2 | Délka extra pole (m) |
| 30 | n | Název souboru |
| Název souboru | ||
| 30+n | m | Extra pole |
Extra pole obsahuje různé nepovinné údaje, jako je OS-specifické atributy. Je rozděleno na části, z nichž každá má 16bitový identifikační kód a 16bitovou délku. Pro ZIP64 existuje vždy alespoň jeden chunk (s ID kódem 0001 a velikostí 32 bajtů), viz níže.
Po něm bezprostředně následují komprimovaná data.
Datový deskriptorEdit
Je-li nastaven bit na offsetu 3 (0x08) pole příznaků pro všeobecné použití, pak při zápisu hlavičky nejsou známy CRC-32 a velikosti souborů. Pole v lokální hlavičce jsou vyplněna nulou a CRC-32 a velikost jsou připojeny ve 12bajtové struktuře (volitelně předřazené 4bajtové signatuře) hned za komprimovaná data:
| Offset | Bajty | Popis |
|---|---|---|
| 0 | 0/4 | Volitelný podpis deskriptoru dat = 0x08074b50 |
| 0/4 | 4 | CRC-32 nekomprimovaných dat |
| 4/8 | 4 | Komprimovaná velikost |
| 8/12 | 4 | nekomprimovaná size |
Záhlaví souboru centrálního adresářeEdit
Zápis v centrálním adresáři je rozšířenou formou lokálního záhlaví:
| Offset | Bajty | Popis |
|---|---|---|
| 0 | 4 | Centrální signatura hlavičky adresářového souboru = 0x02014b50 |
| 4 | 2 | Verze vytvořená |
| 6 | 2 | Verze potřebná k extrakci (minimum) |
| 8 | 2 | Bitový příznak pro obecné účely |
| 10 | 2 | Metoda komprese |
| 12 | 2 | Čas poslední změny souboru |
| 14 | 2 | Datum poslední změny souboru |
| 16 | 4 | CRC-32 nekomprimovaných dat |
| 20 | 4 | Komprimovaná velikost (nebo 0xffffffff pro ZIP64) |
| 24 | 4 | Nekomprimovaná velikost (nebo 0xffffffff pro ZIP64) |
| 28 | 2 | Délka názvu souboru (n) |
| 30 | 2 | Délka extra pole (m) |
| 32 | 2 | Délka komentáře k souboru (k) |
| 34 | 2 | Číslo disku, na kterém soubor začíná |
| 36 | 2 | Vnitřní atributy souboru |
| 38 | 4 | Vnější atributy souboru |
| 42 | 4 | Relativní offset lokální hlavičky souboru. Jedná se o počet bajtů mezi začátkem prvního disku, na kterém se soubor vyskytuje, a začátkem hlavičky lokálního souboru. To umožňuje softwaru, který čte centrální adresář, lokalizovat pozici souboru uvnitř souboru ZIP. |
| 46 | n | Název souboru |
| 46+n | m | Extra pole |
| 46+n+m | k | Komentář k souboru |
Konec záznamu centrálního adresáře (EOCD)Edit
Po všech záznamech centrálního adresáře následuje záznam konce centrálního adresáře (EOCD), který označuje konec souboru ZIP:
| Odstavec | Bajty | Popis |
|---|---|---|
| 0 | 4 | Konec signatura centrálního adresáře = 0x06054b50 |
| 4 | 2 | Číslo tohoto disku |
| 6 | 2 | Disk, kde je centrální adresář začíná |
| 8 | 2 | Počet záznamů centrálního adresáře na tomto disku |
| 10 | 2 | Celkový počet centrálního záznamů centrálního adresáře |
| 12 | 4 | Velikost centrálního adresáře (bajty) |
| 16 | 4 | Odsazení začátku centrálního adresáře, vzhledem k začátku archivu |
| 20 | 2 | Délka komentáře (n) |
| 22 | n | Komentář |
Toto uspořádání umožňuje vytvořit soubor ZIP v jednom průchodu, ale centrální adresář je také umístěn na konec souboru, aby se usnadnilo odstraňování souborů z vícedílných (např.“vícenásobné diskety“), jak již bylo řečeno.
Kompresní metodyUpravit
Specifikace formátu souborů .ZIP dokumentuje následující kompresní metody: (bez komprese), Shrink (LZW), Reduce (úrovně 1-4; LZ77 + pravděpodobnostní), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd a varianta LZ77 poskytovaná instrukcí IBM z/OS CMPSC. Nejčastěji používanou kompresní metodou je DEFLATE, která je popsána v IETF RFC 1951.
Mezi další metody, které jsou zmíněny, ale nejsou ve specifikaci podrobně zdokumentovány, patří např: PKWARE DCL Implode (starý IBM TERSE), nový IBM TERSE, IBM LZ77 z Architecture (PFS) a varianta JPEG. Metoda „Tokenize“ byla vyhrazena pro třetí stranu, ale její podpora nebyla nikdy přidána.
Slovo Implode je společností PKWARE nadužíváno: DCL/TERSE Implode se liší od starého PKZIP Implode, předchůdce Deflate. DCL Implode není dokumentován, částečně kvůli jeho proprietární povaze, kterou drží IBM, ale Mark Adler přesto vedle zlib poskytl dekompresor nazvaný „blast“.
EncryptionEdit
ZIP podporuje jednoduchý symetrický šifrovací systém založený na heslech, obecně známý jako ZipCrypto. Je zdokumentován ve specifikaci ZIP a je známo, že má vážné nedostatky. Zejména je zranitelný vůči útokům typu known-plaintext, které v některých případech zhoršuje špatná implementace generátorů náhodných čísel.
Nové funkce včetně nových metod komprese a šifrování (např. AES) jsou od verze 5.2 dokumentovány ve specifikaci formátu souborů ZIP. Otevřený standard založený na AES vyvinutý společností WinZip („AE-x“ v APPNOTE) používají také společnosti 7-Zip a Xceed, ale někteří dodavatelé používají jiné formáty. PKWARE SecureZIP (SES, proprietární) podporuje také metody šifrování RC2, RC4, DES, Triple DES, šifrování a ověřování na základě digitálního certifikátu (X.509) a šifrování hlaviček archivů. Je však patentován (viz § Spory o silné šifrování).
Šifrování názvů souborů je zavedeno ve specifikaci .ZIP File Format Specification 6.2, která šifruje metadata uložená v části Central Directory archivu, ale části Local Header zůstávají nezašifrované. Archivační program splňující požadavky může při použití šifrování Central Directory zfalšovat data Local Header. Od verze 6.2 specifikace ještě nejsou maskována pole Compression Method a Compressed Size v Local Header.
ZIP64Edit
Původní formát .ZIP měl limit 4 GiB (232 bajtů) na různé věci (nekomprimovaná velikost souboru, komprimovaná velikost souboru a celková velikost archivu) a také limit 65 535 (216) položek v archivu ZIP. Ve verzi 4.5 specifikace (která není totožná s verzí 4.5 konkrétního nástroje) zavedla společnost PKWARE rozšíření formátu „ZIP64“, aby tato omezení obešla, a zvýšila limity na 16 EiB (264 bajtů). V podstatě používá „normální“ centrální položku adresáře pro soubor, za níž následuje volitelná položka adresáře „zip64“, která má větší pole.
Formát hlavičky místního souboru a záznamu centrálního adresáře je u ZIP a ZIP64 stejný, ale pro velikosti uložené vždy 0xffffffff a vždy existuje pole navíc:
| Offset | Bajty | Popis |
|---|---|---|
| 0 | 2 | ID hlavičky 0x0001 |
| 2 | 2 | Velikost chunku extra pole (16, 24 nebo 28) |
| 4 | 8 | Původní velikost nekomprimovaného souboru |
| 12 | 8 | Velikost komprimovaných dat |
| 20 | 8 | Odsazení lokálního záznamu hlavičky |
| 28 | 4 | Číslo disku, na kterém tento soubor začíná |
Na druhé straně, je formát EOCD pro ZIP64 mírně odlišný od běžné verze ZIP (viz část 4 poznámky k aplikaci.3.14).
| Offset | Bajty | Popis |
|---|---|---|
| 0 | 4 | Konec signatury centrálního adresáře = 0x06064b50 |
| 4 | 8 | Velikost EOCD64 -. 8 |
| 12 | 2 | Verze provedená |
| 14 | 2 | Verze potřebná k extrakci (minimální) |
| 16 | 4 | Číslo tohoto disku |
| 20 | 4 | Disk, kde začíná centrální adresář |
| 24 | 8 | Počet záznamů centrálního adresáře na tomto disku |
| 32 | 8 | Celkový počet záznamů centrálního adresáře |
| 40 | 8 | Velikost centrálního adresáře (bajty) |
| 48 | 8 | Odsazení začátku centrálního adresáře, vzhledem k začátku archivu |
| 56 | n | Komentář (až do velikosti EOCD64) |
Není to také nutně poslední záznam v souboru, může následovat nepovinný lokátor konce centrálního adresáře (dalších 20 bajtů na konci).
Průzkumník souborů v systému Windows XP nepodporuje ZIP64, ale Průzkumník v systému Windows Vista a novějším ano. Stejně tak některé rozšiřující knihovny podporují ZIP64, například DotNetZip, QuaZIP a IO::Compress::Zip v Perlu. Vestavěný soubor ZIP v jazyce Python jej podporuje od verze 2.5 a od verze 3.4 je přednastaven jako výchozí. Vestavěný soubor java.util.zip v OpenJDK podporuje ZIP64 od verze Java 7. Android Java API podporuje ZIP64 od verze Android 6.0. Archivační nástroj v systému Mac OS Sierra zejména nepodporuje ZIP64 a může vytvářet poškozené archivy, když by byl ZIP64 vyžadován. Příkaz ditto dodávaný s operačním systémem Mac OS však soubory ZIP64 rozbalí. Novější verze systému Mac OS jsou dodávány s nástroji příkazového řádku info-zip zip a unzip, které Zip64 podporují: pro ověření spusťte příkaz zip -v a vyhledejte „ZIP64_SUPPORT“.
Kombinace s jinými formáty souborůEdit
Formát souboru .ZIP umožňuje, aby se na konci souboru za centrálním adresářem vyskytoval komentář obsahující až 65 535 (216-1) bajtů dat. Také proto, že centrální adresář určuje offset každého souboru v archivu vzhledem k začátku, je možné, aby první položka souboru začínala na jiném offsetu než na nule, ačkoli některé nástroje, například gzip, nezpracují archivní soubory, které nezačínají položkou souboru na offsetu nula.
To umožňuje, aby se v souboru vyskytovala libovolná data před i za daty archivu ZIP a aby byl archiv stále čitelný aplikací ZIP. Vedlejším efektem je, že je možné vytvořit soubor, který je zároveň funkčním archivem ZIP i jiným formátem, za předpokladu, že tento jiný formát toleruje libovolná data na svém konci, začátku nebo uprostřed. Samorozbalovací archivy (SFX) v podobě podporované programem WinZip toho využívají v tom smyslu, že se jedná o spustitelné soubory (.exe), které odpovídají specifikaci PKZIP AppNote.txt a mohou být čteny kompatibilními nástroji nebo knihovnami ZIP.
Tuto vlastnost formátu .ZIP a formátu JAR, který je variantou formátu ZIP, lze zneužít ke skrytí podvodného obsahu (například škodlivých tříd jazyka Java) uvnitř zdánlivě neškodného souboru, například obrázku GIF nahraného na web. Tento takzvaný GIFAR exploit byl demonstrován jako účinný útok proti webovým aplikacím, jako je například Facebook.
LimitsEdit
Minimální velikost souboru .ZIP je 22 bajtů. Takový prázdný soubor ZIP obsahuje pouze záznam EOCD (End of Central Directory Record):
Maximální velikost archivního souboru i jednotlivých souborů v něm je 4 294 967 295 bajtů (232-1 bajtů neboli 4 GiB minus 1 bajt) pro standardní ZIP. Pro ZIP64 je maximální velikost 18 446 744 073 709 551 615 bajtů (264-1 bajtů, neboli 16 EiB minus 1 bajt).
Vlastní rozšířeníEdit
Extra poleEdit
.Formát souborů ZIP obsahuje v záhlaví souborů možnost extra pole, které lze použít k uložení dodatečných dat, jež nejsou definována stávajícími specifikacemi ZIP, a které umožňují kompatibilním archivátorům, které tato pole nerozpoznávají, je bezpečně přeskočit. ID záhlaví 0-31 jsou vyhrazena pro použití PKWARE. Zbývající ID mohou používat dodavatelé třetích stran pro vlastní použití.
Spor o silné šifrováníEdit
Když byla v roce 2003 vydána veřejná beta verze WinZipu 9.0, představil WinZip spolu s dokumentací k nové specifikaci vlastní šifrování AES-256, které používá jiný formát souborů. Samotné šifrovací standardy nebyly proprietární, ale společnost PKWARE od roku 2001 neaktualizovala soubor APPNOTE.TXT tak, aby obsahoval specifikaci SES (Strong Encryption Specification), kterou používaly verze 5.0 a 6.0 programu PKZIP. Technický konzultant společnosti WinZip Kevin Kearney a produktový manažer StuffIt Mathew Covington obvinili společnost PKWARE ze zadržování SES, ale technologický ředitel společnosti PKZIP Jim Peterson tvrdil, že šifrování založené na certifikátech je stále neúplné.
V dalším kontroverzním kroku požádala společnost PKWARE 16. července 2003 o patent popisující metodu kombinace ZIP a silného šifrování pro vytvoření bezpečného souboru.
Nakonec se společnosti PKWARE a WinZip dohodly na vzájemné podpoře svých produktů. Dne 21. ledna 2004 společnost PKWARE oznámila podporu kompresního formátu AES založeného na systému WinZip. V pozdější beta verzi programu WinZip se podařilo podporovat soubory ZIP založené na formátu SES. Společnost PKWARE nakonec zveřejnila verzi 5.2 specifikace formátu souborů .ZIP, která dokumentovala formát SES. Projekt svobodného softwaru 7-Zip také podporuje AES, ale ne SES v souborech ZIP (stejně jako jeho POSIXový port p7zip).
Při použití šifrování AES pod WinZip je metoda komprese vždy nastavena na 99, přičemž skutečná metoda komprese je uložena v poli dodatečných dat AES. Naproti tomu Strong Encryption Specification ukládá metodu komprese do základního segmentu hlavičky souboru v Local Header a Central Directory, pokud není použito Central Directory Encryption k maskování/šifrování metadat.