ZIP (formát souboru) - ZIP (file format)
| Přípona názvu souboru |
.zip .zipx
|
|---|---|
| Typ internetového média | application/zip |
| Jednotný identifikátor typu (UTI) | com.pkware.zip-archiv |
| Kouzelné číslo | |
| Vyvinuto | Společnost PKWARE, Inc. |
| První vydání | 14. února 1989 |
| Poslední vydání | 6.3.9 (15. července 2020 ) |
| Typ formátu | Komprese dat |
| Rozšířeno na | |
| Standard |
APPNOTE od PKWARE ISO/IEC 21320-1: 2015 (podmnožina formátu ZIP souboru 6.3.3) |
| Otevřený formát ? | Ano |
ZIP je formát archivního souboru, který podporuje bezeztrátovou kompresi dat . Soubor ZIP může obsahovat jeden nebo více souborů nebo adresářů, které mohly být komprimovány. Formát souboru ZIP umožňuje řadu kompresních algoritmů , ačkoli DEFLATE je nejběžnější. Tento formát byl původně vytvořen v roce 1989 a byla poprvé realizována v PKWARE, Inc. je PKZIP nástroj, jako náhrada za předchozí ARC kompresní formát Thom Henderson. Formát ZIP pak rychle podporovalo mnoho softwarových nástrojů kromě PKZIP. Společnost Microsoft zahrnula vestavěnou podporu ZIP (pod názvem „komprimované složky“) do verzí systému Microsoft Windows od roku 2000 (Windows Me). Společnost Apple zahrnula vestavěnou podporu ZIP v systému Mac OS X 10.3 (prostřednictvím BOMArchiveHelper, nyní Archive Utility ) a novějších. Většina bezplatných operačních systémů má vestavěnou podporu pro ZIP podobným způsobem jako Windows a Mac OS X.
Soubory ZIP obecně používají přípony souborů .zip nebo .ZIP a typ média MIMEapplication/zip . ZIP používá jako základní formát souboru mnoho programů, obvykle pod jiným názvem. Při procházení systému souborů prostřednictvím uživatelského rozhraní se grafické ikony představující soubory ZIP často zobrazují jako dokument nebo jiný objekt s výrazným zipem .
Dějiny
Formát souboru .ZIP navrhli Phil Katz z PKWARE a Gary Conway z Infinity Design Concepts. Formát byl vytvořen poté, co Systems Enhancement Associates (SEA) podala žalobu proti společnosti PKWARE s tvrzením, že její archivační produkty, pojmenované PKARC, byly deriváty archivního systému SEA ARC . Název „zip“ (což znamená „pohyb vysokou rychlostí“) navrhl Katzův přítel Robert Mahoney. Chtěli naznačit, že jejich produkt bude rychlejší než ARC a jiné tehdejší kompresní formáty. Nejdříve známá verze .ZIP Specifikace formátu souboru byla poprvé publikována jako součást balíčku PKZIP 0.9 pod souborem APPNOTE.TXT v roce 1989. Distribucí formátu souboru zip v rámci APPNOTE.TXT se kompatibilita s formátem souboru zip rozšířila na veřejnosti. Internet v 90. letech 20. století.
Společnosti PKWARE a Infinity Design Concepts vydaly 14. února 1989 společnou tiskovou zprávu a zveřejnily formát souboru .ZIP ve veřejné doméně .
Historie verzí
Specifikace formátu souboru .ZIP má své vlastní číslo verze, které nemusí nutně odpovídat číslům verzí nástroje PKZIP, zejména u PKZIP 6 nebo novějších. V různých časech PKWARE přidal předběžné funkce, které umožňují produktům PKZIP extrahovat archivy pomocí pokročilých funkcí, ale produkty PKZIP, které vytvářejí takové archivy, budou k dispozici až v příštím větším vydání. Jiné společnosti nebo organizace podporují specifikace PKWARE svým vlastním tempem.
Specifikace formátu souboru .ZIP má formální název "APPNOTE - .ZIP Specifikace formátu souboru" a je publikována na webových stránkách PKWARE.com od konce 90. let. Několik verzí specifikace nebylo zveřejněno. Specifikace některých funkcí, jako je komprese BZIP2 , silná specifikace šifrování a další, zveřejnila společnost PKWARE několik let po jejich vytvoření. Adresa URL online specifikace byla na webu PKWARE několikrát změněna.
Souhrn klíčových pokroků v různých verzích specifikace PKWARE:
- 2.0: (1993) Položky souborů lze komprimovat pomocí DEFLATE a používat tradiční šifrování PKWARE (ZipCrypto).
- 2.1: (1996) Deflate64 komprese
- 4.5: (2001) Zdokumentovaný 64bitový formát zip.
- 4.6: (2001) komprese BZIP2 (do vydání APPNOTE 5.2 nebyl publikován online)
- 5.0: (2002) SES: DES , Triple DES , RC2 , RC4 podporováno pro šifrování (do vydání APPNOTE 5.2 nebylo publikováno online)
- 5.2: (2003) Podpora šifrování AES pro SES (definováno v APPNOTE 5.1, které nebylo publikováno online) a AES od WinZip („AE-x“); opravená verze RC2-64 podporovaná pro šifrování SES.
- 6.1: (2004) Dokumentované úložiště certifikátů.
- 6.2.0: (2004) Zdokumentované šifrování centrálního adresáře.
- 6.3.0: (2006) Dokumentované úložiště názvů souborů Unicode ( UTF-8 ). Rozšířený seznam podporovaných kompresních algoritmů ( LZMA , PPMd+ ), šifrovacích algoritmů ( Blowfish , Twofish ) a hash.
- 6.3.1: (2007) Opravené standardní hodnoty hash pro SHA-256/384/512.
- 6.3.2: (2007) Dokumentovaná metoda komprese 97 ( WavPack ).
- 6.3.3: (2012) Změny formátování dokumentu, které usnadňují odkazování na aplikační poznámku PKWARE z jiných standardů pomocí metod, jako je JTC 1 Referencing Explanatory Report (RER) podle pokynů JTC 1/SC 34 N 1621.
- 6.3.4: (2014) Aktualizuje adresu kanceláře PKWARE, Inc.
- 6.3.5: (2018) Zdokumentované metody komprese 16, 96 a 99, epocha a přesnost časového razítka DOS, přidaná další pole pro klíče a dešifrování, stejně jako překlepy a upřesnění.
- 6.3.6: (2019) Opravená typografická chyba.
- 6.3.7: (2020) Přidána metoda komprese Zstandard ID 20.
- 6.3.8: (2020) Přesunuto ID metody komprese Zstandard z 20 na 93, přičemž první z nich je zastaralé. Prokázané ID metoda 94 a 95 ( MP3 a XZ v tomto pořadí).
- 6.3.9: (2020) Opravený překlep v popisu zarovnání datového proudu.
WinZip , počínaje verzí 12.1, používá příponu .zipx pro soubory ZIP, které používají kompresní metody novější než DEFLATE; konkrétně metody BZip, LZMA, PPMd, Jpeg a Wavpack. Poslední 2 se použijí na příslušné typy souborů, když je vybrána komprese „Nejlepší metoda“.
Standardizace
V dubnu 2010 zahájil ISO/IEC JTC 1 hlasovací lístek, který měl určit, zda by měl být zahájen projekt pro vytvoření formátu mezinárodního standardu ISO/IEC kompatibilního se ZIP. Navrhovaný projekt s názvem Document Packaging předpokládal „minimální komprimovaný formát archivu“ kompatibilní se ZIP, vhodný pro použití s řadou stávajících standardů včetně OpenDocument , Office Open XML a EPUB .
V roce 2015 byla vydána ISO/IEC 21320-1 „Soubor kontejneru dokumentu-část 1: Jádro“, která uvádí, že „soubory kontejneru dokumentů odpovídají souborům Zip“. Vyžaduje následující hlavní omezení formátu souboru ZIP:
- Soubory v archivech ZIP lze ukládat pouze nekomprimované nebo pomocí komprese „deflate“ (tj. Metoda komprese může obsahovat hodnotu „0“ - uloženo nebo „8“ - deflováno).
- Šifrovací funkce jsou zakázány.
- Funkce digitálního podpisu (od SES) jsou zakázány.
- Funkce „opravených dat“ (od PKPatchMaker) jsou zakázány.
- Archivy nesmí zahrnovat více svazků ani být segmentovány.
Design
Soubory .ZIP jsou archivy, které ukládají více souborů. ZIP umožňuje komprimaci obsažených souborů pomocí mnoha různých metod a také jednoduché uložení souboru bez komprese. Každý soubor je uložen samostatně, což umožňuje komprimaci různých souborů ve stejném archivu pomocí různých metod. Protože jsou soubory v ZIP archivu komprimovány jednotlivě, je možné je extrahovat nebo přidat nové bez použití komprese nebo dekomprese na celý archiv. To je v kontrastu s formátem komprimovaných tarových souborů, u nichž není takové zpracování náhodného přístupu snadno možné.
Adresář je umístěn na konci souboru ZIP. Toto určuje, jaké soubory jsou ve formátu ZIP, a určuje, kde ve formátu ZIP se tento soubor nachází. To umožňuje čtečkám ZIP načítat seznam souborů bez čtení celého ZIP archivu. ZIP archivy mohou také obsahovat další data, která nesouvisejí s ZIP archivem. To umožňuje, aby se archiv ZIP stal samorozbalovacím archivem (aplikace, která dekomprimuje obsažená data), a to tak, že kód programu vložíte do archivu ZIP a soubor označíte jako spustitelný. Uložení katalogu na konci také umožňuje skrýt zip soubor jeho připojením k neškodnému souboru, jako je soubor obrázku GIF.
Formát .ZIP používá 32bitový algoritmus CRC a obsahuje dvě kopie adresářové struktury archivu, aby poskytl větší ochranu před ztrátou dat.
Struktura
Soubor ZIP je správně identifikován přítomností konce záznamu centrálního adresáře, který je umístěn na konci struktury archivu, aby bylo možné snadno přidávat nové soubory. Pokud konec záznamu centrálního adresáře indikuje neprázdný archiv, název každého souboru nebo adresáře v archivu by měl být uveden v položce centrálního adresáře spolu s dalšími metadaty o záznamu a odsazením do souboru ZIP, směřujícím na skutečné vstupní údaje. To umožňuje provádět relativně rychle výpis souborů z archivu, protože pro zobrazení seznamu souborů není nutné číst celý archiv. Položky v souboru ZIP také obsahují tyto informace pro nadbytečnost v místní hlavičce souboru . Protože k souborům ZIP lze připojit, jsou platné pouze soubory uvedené v centrálním adresáři na konci souboru. Skenování souboru ZIP pro místní záhlaví souborů je neplatné (s výjimkou případu poškozených archivů), protože centrální adresář může prohlásit, že některé soubory byly odstraněny a jiné soubory byly aktualizovány.
Můžeme například začít souborem ZIP, který obsahuje soubory A, B a C. Soubor B se poté odstraní a C aktualizuje. 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ý uvádí pouze soubor A a nový soubor C. Když byl ZIP poprvé navržen, přenos souborů pomocí diskety byl běžný, přesto bylo psaní na disky velmi časově náročné. Pokud byste měli velký soubor zip, který by mohl zahrnovat více disků, a potřebovali byste pouze aktualizovat několik souborů, místo čtení a přepisování všech souborů by bylo podstatně rychlejší přečíst starý centrální adresář a připojit nové soubory. poté připojte aktualizovaný centrální adresář.
Pořadí záznamů souborů v centrálním adresáři se nemusí shodovat s pořadím záznamů souborů v archivu.
Každý záznam uložený v ZIP archivu je představen místním záhlavím souboru s informacemi o souboru, jako je komentář, velikost souboru a název souboru, následují volitelná „extra“ datová pole a poté případně komprimovaná, případně šifrovaná data souboru. Datová pole „Extra“ jsou klíčem k rozšiřitelnosti formátu ZIP. Pole „Extra“ jsou využívána k podpoře formátu ZIP64, šifrování AES kompatibilního s WinZip, atributů souborů a časových razítek souborů NTFS nebo Unix s vyšším rozlišením. Další rozšíření jsou možná prostřednictvím pole „Extra“. K ignorování dalších polí, která nerozpoznávají, jsou podle specifikace vyžadovány nástroje ZIP.
Formát ZIP používá k označení různých struktur v souboru konkrétní 4bajtové „podpisy“. Každá položka souboru je označena konkrétním podpisem. Konec záznamu centrálního adresáře je označen jeho konkrétním podpisem a každý záznam v centrálním adresáři začíná podpisem 4bajtového centrálního záhlaví souboru .
Ve specifikaci ZIP není žádná značka BOF nebo EOF. Obvykle je první věcí v souboru ZIP položka ZIP, kterou lze snadno identifikovat podle místního podpisu záhlaví souboru . To však nemusí být pravda, protože to nevyžaduje specifikace ZIP - zejména samorozbalovací archiv začíná záhlavím spustitelného souboru.
Nástroje, které správně čtou archivy ZIP, musejí vyhledat konec podpisu záznamu v centrálním adresáři a poté podle potřeby další uvedené záznamy centrálního adresáře. Nesmí vyhledávat položky z horní části souboru ZIP, protože (jak již bylo zmíněno v této části) pouze centrální adresář určuje, kde začíná část souboru a která nebyla odstraněna. Skenování by mohlo vést k falešně pozitivním výsledkům, protože formát nezakazuje, aby mezi daty byly další data, ani datové streamy souborů neobsahovaly takové podpisy. Nástroje, které se pokoušejí obnovit data z poškozených archivů ZIP, však s největší pravděpodobností prohledají archiv pro podpisy místního záhlaví souboru; toto je ztíženo skutečností, že komprimovaná velikost bloku souboru může být uložena po bloku souboru, což ztěžuje sekvenční zpracování.
Většina podpisů skončit s krátkým integer 0x4b50, který je uložen v malém-endian uspořádání. Při pohledu na řetězec ASCII se čte „PK“, iniciály vynálezce Phila Katze. Při prohlížení souboru ZIP v textovém editoru jsou tedy první dva bajty souboru obvykle „PK“. (Samorozbalovací ZIP DOS, OS/2 a Windows mají před ZIP EXE, takže začněte s „MZ“; samorozbalovacím ZIP pro jiné operační systémy může obdobně předcházet spustitelný kód pro extrahování obsahu archivu na této platformě.)
Specifikace .ZIP také podporuje šíření archivů mezi více souborů systému souborů. Původně byla tato funkce určena k ukládání velkých souborů ZIP na více disket , nyní se používá k odesílání archivů ZIP po částech e -mailem nebo přes jiné přenosy nebo vyměnitelná média.
Souborový systém FAT DOS má rozlišení timestamp pouhých dvou sekund; Záznamy ZIP souborů to napodobují. Výsledkem je, že vestavěné rozlišení časových razítek souborů v archivu ZIP je pouze dvě sekundy, ačkoli pro uložení přesnějších časových razítek lze použít další pole. Formát ZIP nemá pojem o časovém pásmu , takže časová razítka mají smysl pouze tehdy, když je známo, v jakém časovém pásmu byly vytvořeny.
V září 2007 vydal PKWARE revizi specifikace ZIP zajišťující ukládání názvů souborů pomocí UTF-8 a nakonec do ZIP přidal kompatibilitu Unicode.
Záhlaví souborů
Všechny vícebajtové hodnoty v záhlaví jsou uloženy v pořadí bajtů malých endianů . Všechna pole délky počítají délku v bajtech.
Místní hlavička souboru
| Ofset | Bajty | Popis |
|---|---|---|
| 0 | 4 | Místní podpis záhlaví souboru = 0x04034b50 (PK ♥ ♦ nebo "PK \ 3 \ 4") |
| 4 | 2 | Verze potřebná k extrahování (minimum) |
| 6 | 2 | Bitová vlajka obecného účelu |
| 8 | 2 | Kompresní metoda; např. none = 0, DEFLATE = 8 (nebo "\ 0x08 \ 0x00") |
| 10 | 2 | Čas poslední úpravy souboru |
| 12 | 2 | Datum poslední úpravy 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 | Extra délka pole ( m ) |
| 30 | n | Název souboru |
| 30+ n | m | Pole navíc |
Pole navíc obsahuje řadu volitelných údajů, jako jsou atributy specifické pro OS. Je rozdělen na záznamy, každý s minimálně 16bitovým podpisem a 16bitovou délkou. Záznam extra pole místního souboru ZIP64 má například podpis 0x0001 a délku 16 bajtů (nebo více), takže mohou následovat dvě 64bitové hodnoty (komprimované a nekomprimované velikosti). Další běžnou místní příponou souboru je 0x5455 (nebo „UT“), která obsahuje 32bitová časová razítka UTC UNIX.
Za tím bezprostředně následují komprimovaná data.
Popisovač dat
Pokud je nastaven bit na posunu 3 (0x08) pole obecných příznaků, pak při zápisu záhlaví nejsou známy velikosti CRC-32 a velikosti souboru. Pole v místním záhlaví jsou vyplněna nulou a CRC-32 a velikost jsou připojeny ve 12bajtové struktuře (volitelně předchází 4bajtový podpis) bezprostředně za komprimovanými daty:
| Ofset | Bajty | Popis |
|---|---|---|
| 0 | 0/4 | Volitelný podpis popisovače dat = 0x08074b50 |
| 0/4 | 4 | CRC-32 nekomprimovaných dat |
| 4/8 | 4 | Komprimovaná velikost |
| 8/12 | 4 | Nekomprimovaná velikost |
Centrální hlavička adresáře
Záznam centrálního adresáře je rozšířená forma místního záhlaví:
| Ofset | Bajty | Popis |
|---|---|---|
| 0 | 4 | Podpis záhlaví souboru centrálního adresáře = 0x02014b50 |
| 4 | 2 | Verze od |
| 6 | 2 | Verze potřebná k extrahování (minimum) |
| 8 | 2 | Bitová vlajka obecného účelu |
| 10 | 2 | Kompresní metoda |
| 12 | 2 | Čas poslední úpravy souboru |
| 14 | 2 | Datum poslední úpravy 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 | Extra délka pole ( m ) |
| 32 | 2 | Délka komentáře k souboru ( k ) |
| 34 | 2 | Číslo disku, kde soubor začíná |
| 36 | 2 | Interní atributy souboru |
| 38 | 4 | Externí atributy souboru |
| 42 | 4 | Relativní posun místního záhlaví souboru. Toto je počet bajtů mezi začátkem prvního disku, na kterém se soubor vyskytuje, a začátkem místní hlavičky souboru. To umožňuje softwaru číst centrální adresář a vyhledat polohu souboru uvnitř souboru ZIP. |
| 46 | n | Název souboru |
| 46+ n | m | Pole navíc |
| 46+ n + m | k | Komentář souboru |
Konec záznamu centrálního adresáře (EOCD)
Po všech záznamech centrálního adresáře přichází konec záznamu centrálního adresáře (EOCD), který označuje konec souboru ZIP:
| Ofset | Bajty | Popis |
|---|---|---|
| 0 | 4 | Konec podpisu centrálního adresáře = 0x06054b50 |
| 4 | 2 | Číslo tohoto disku (nebo 0xffff pro ZIP64) |
| 6 | 2 | Disk, kde začíná centrální adresář (nebo 0xffff pro ZIP64) |
| 8 | 2 | Počet záznamů centrálního adresáře na tomto disku (nebo 0xffff pro ZIP64) |
| 10 | 2 | Celkový počet záznamů centrálního adresáře (nebo 0xffff pro ZIP64) |
| 12 | 4 | Velikost centrálního adresáře (bajty) (nebo 0xffffffff pro ZIP64) |
| 16 | 4 | Offset začátku centrálního adresáře vzhledem k začátku archivu (nebo 0xffffffff pro ZIP64) |
| 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 umístěn také na konci souboru, aby bylo usnadněno snadné odstraňování souborů z archivů s více částmi (např. „Více disket“) , jako dříve diskutováno.
Kompresní metody
Specifikace formátu souboru .ZIP dokumentuje následující metody komprese: Store (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ší zmíněné metody, které nejsou ve specifikaci podrobně zdokumentovány, patří: 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 podpora nebyla nikdy přidána.
PKWARE nadužívá slovo Implode: DCL/TERSE Implode se liší od starého PKZIP Implode, předchůdce Deflate. DCL Implode je částečně nezdokumentovaný kvůli své vlastnické povaze, kterou má IBM, ale Mark Adler přesto poskytl vedle zlib dekompresor s názvem „blast“.
Šifrování
ZIP podporuje jednoduchý symetrický šifrovací systém založený na heslech , obecně známý jako ZipCrypto. Je to zdokumentováno ve specifikaci ZIP a je známo, že má vážné chyby. Je zvláště zranitelný vůči útokům známého prostého textu , které jsou v některých případech zhoršeny špatnou implementací generátorů náhodných čísel .
Nové funkce včetně nových metod komprese a šifrování (např. AES ) jsou dokumentovány ve Specifikaci formátu ZIP souboru od verze 5.2. WinZip -developed AES-založený otevřený standard ( "AE-x" ve appnote) se používá také 7-Zip a Xceed , ale někteří dodavatelé používat i jiné formáty. PKWARE SecureZIP (SES, proprietární) také podporuje šifrování RC2, RC4, DES, Triple DES, šifrování a ověřování založené na digitálním certifikátu ( X.509 ) a šifrování záhlaví archivu. Je však patentovaný (viz § Silná diskuse o šifrování ).
Šifrování názvů souborů je zavedeno ve formátu .ZIP Specifikace formátu 6.2, který šifruje metadata uložená v části archivu Central Directory, ale sekce Local Header zůstávají nezašifrované. Vyhovující archivátor může při použití šifrování Central Directory falšovat data místního záhlaví. Od verze 6.2 specifikace pole Metoda komprese a Komprimovaná velikost v místním záhlaví ještě nejsou maskována.
ZIP64
Původní formát .ZIP měl limit 4 GB (2 32 bajtů) na různé věci (nekomprimovaná velikost souboru, komprimovaná velikost souboru a celková velikost archivu) a také limit 65 535 (2 16 ) záznamy v ZIP archivu. Ve verzi 4.5 specifikace (která není stejná jako v4.5 žádného konkrétního nástroje) PKWARE zavedl rozšíření formátu „ZIP64“, aby tato omezení obešel a zvýšil limity na 16 EB (2 64 bajtů). V zásadě používá pro soubor „normální“ položku centrálního adresáře, následovanou volitelným záznamem adresáře „zip64“, který má větší pole.
Formát hlavičky lokálního souboru (LOC) a položky centrálního adresáře (CEN) je v ZIP i ZIP64 stejný. ZIP64 však určuje další pole, které může být přidáno k těmto záznamům podle uvážení kompresoru, jehož účelem je uložit hodnoty, které se nehodí do klasických záznamů LOC nebo CEN. Aby signalizovaly, že skutečné hodnoty jsou uloženy v dalších polích ZIP64, jsou v odpovídajícím záznamu LOC nebo CEN nastaveny na 0xFFFF nebo 0xFFFFFFFF.
| Ofset | Bajty | Popis |
|---|---|---|
| 0 | 2 | ID záhlaví 0x0001 |
| 2 | 2 | Velikost pole navíc (8, 16, 24 nebo 28) |
| 4 | 8 | Původní velikost nekomprimovaného souboru |
| 12 | 8 | Velikost komprimovaných dat |
| 20 | 8 | Offset záznamu lokální hlavičky |
| 28 | 4 | Číslo disku, na kterém tento soubor začíná |
Na druhou stranu se formát EOCD pro ZIP64 mírně liší od normální verze ZIP.
| Ofset | Bajty | Popis |
|---|---|---|
| 0 | 4 | Konec podpisu centrálního adresáře = 0x06064b50 |
| 4 | 8 | Velikost EOCD64 - 12 |
| 12 | 2 | Verze od |
| 14 | 2 | Verze potřebná k extrahování (minimum) |
| 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 | Offset začátku centrálního adresáře vzhledem k začátku archivu |
| 56 | n | Komentovat (až do velikosti EOCD64) |
Není to také nutně poslední záznam v souboru. Následuje konec centrálního vyhledávače adresářů (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ší ano. Podobně některé knihovny rozšíření podporují ZIP64, například DotNetZip, QuaZIP a IO :: Compress :: Zip v Perlu. Python ‚s vestavěnou .zip archivu podpěrách to již od 2,5 a výchozí hodnota je to od 3.4. Integrovaný java.util.zip OpenJDK podporuje ZIP64 od verze Java 7 . Android Java API podporuje ZIP64 od Androidu 6.0. Mac OS Sierra's Archive Utility zejména nepodporuje ZIP64 a může vytvářet poškozené archivy, když bude vyžadován ZIP64. Příkaz ditto dodávaný se systémem Mac OS však rozbalí soubory ZIP64. Novější verze systému Mac OS se dodávají s nástroji příkazového řádku info -zip zip a unzip, které podporují Zip64: k ověření spuštění zip -v a vyhledání „ZIP64_SUPPORT“.
Kombinace s jinými formáty souborů
Formát souboru .ZIP umožňuje, aby se na konci souboru za centrálním adresářem vyskytl komentář obsahující až 65 535 (2 16 −1) bajtů dat. Protože také centrální adresář určuje posun každého souboru v archivu s ohledem na začátek, je možné, aby první položka souboru začala s jiným posunem než je nula, ačkoli některé nástroje, například gzip , nebudou zpracovávat archiv soubory, které nezačínají záznamem souboru na offsetové nule.
To umožňuje, aby se v souboru vyskytovala libovolná data před i za archivními daty ZIP a aby byl archiv stále čitelný aplikací ZIP. Vedlejším efektem je, že je možné vytvořit soubor, který je funkčním archivem ZIP i jiným formátem, za předpokladu, že druhý formát toleruje libovolná data na jeho konci, začátku nebo uprostřed. Samorozbalovací archivy (SFX), ve formě podporované WinZip, toho využívají, protože jsou spustitelné soubory ( .exe ), které odpovídají specifikaci PKZIP AppNote.txt, a lze je číst pomocí kompatibilních zip nástrojů nebo knihoven .
Tuto vlastnost formátu .ZIP a formátu JAR, který je variantou ZIP, lze využít ke skrytí nepoctivého obsahu (například škodlivých tříd Java) do zdánlivě neškodného souboru, jako je obrázek GIF nahraný na web. Tento takzvaný GIFAR exploit byl prokázán jako účinný útok proti webovým aplikacím, jako je Facebook.
Limity
Minimální velikost souboru .ZIP je 22 bajtů. Takový prázdný zip soubor obsahuje pouze Konec záznamu centrálního adresáře (EOCD):
[0x50,0x4B,0x05,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
Maximální velikost archivního souboru i jednotlivých souborů v něm je 4 294 967 295 bajtů (2 32 -1 bajtů nebo 4 GB minus 1 bajt) pro standardní ZIP. Pro ZIP64 je maximální velikost 18 446 744 073 709 551 615 bajtů (2 64 -1 bajtů nebo 16 EB mínus 1 bajt).
Proprietární rozšíření
Pole navíc
Formát souboru .ZIP obsahuje v hlavičkách souborů další pole, které lze použít k ukládání dodatečných dat, která nejsou definována stávajícími specifikacemi ZIP, a která umožňují bezpečně přeskočit kompatibilní archivy, které nerozpoznávají pole. ID záhlaví 0–31 jsou vyhrazena pro použití společností PKWARE. Zbývající ID mohou použít dodavatelé třetích stran k vlastnickému použití.
Silná kontroverze ohledně šifrování
Když byla v roce 2003 vydána veřejná beta verze WinZip 9.0, představila WinZip vlastní šifrování AES-256 pomocí jiného formátu souboru spolu s dokumentací k nové specifikaci. Samotné šifrovací standardy nebyly proprietární , ale PKWARE neaktualizoval APPNOTE.TXT tak, aby od roku 2001 obsahoval Strong Encryption Specification (SES), kterou používaly verze PKZIP 5.0 a 6.0. Technický konzultant WinZip Kevin Kearney a produktový manažer StuffIt Mathew Covington obvinili PKWARE ze zadržování SES, ale hlavní technologický ředitel PKZIP Jim Peterson tvrdil, že šifrování založené na certifikátech je stále neúplné.
V dalším kontroverzním kroku společnost PKWare 16. července 2003 požádala o patent, který popisuje způsob kombinace ZIP a silného šifrování za účelem vytvoření zabezpečeného souboru.
Nakonec se PKWARE a WinZip dohodly na vzájemné podpoře svých produktů. 21. ledna 2004 oznámila PKWARE podporu kompresního formátu AES založeného na WinZip. V novější verzi WinZip beta dokázal podporovat soubory ZIP založené na SES. PKWARE nakonec uvolnil pro veřejnost verzi 5.2 specifikace formátu .ZIP, která dokumentovala SES. Free Software Projekt 7-Zip také podporuje AES, ale ne SES v ZIP soubory (stejně jako jeho POSIX portu 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 datovém poli AES navíc. Naproti tomu Specifikace silného šifrování ukládá metodu komprese do základního segmentu záhlaví souborů Local Header a Central Directory, pokud není k maskování/šifrování metadat použito šifrování Central Directory.
Implementace
K dispozici je mnoho nástrojů .ZIP a řada knihoven .ZIP pro různá programovací prostředí; použité licence zahrnují proprietární a bezplatný software . WinZip , WinRAR , Info-ZIP , 7-Zip , PeaZip a B1 Free Archiver jsou známé nástroje .ZIP, dostupné na různých platformách. Některé z těchto nástrojů mají knihovna nebo programová rozhraní.
Některé vývojové knihovny licencované na základě smlouvy o otevřeném zdroji jsou libzip , libarchive a Info-ZIP . Pro Java: Java Platform Standard Edition obsahuje balíček „java.util.zip“ pro zpracování standardních souborů .ZIP; knihovna Zip64File konkrétně podporuje velké soubory (větší než 4 GB) a zpracovává soubory .ZIP pomocí náhodného přístupu; a nástroj Apache Ant obsahuje úplnější implementaci vydanou pod licencí Apache Software License .
Implementace Info-ZIP ve formátu .ZIP přidává podporu pro funkce souborového systému Unix, jako jsou ID uživatelů a skupin, oprávnění k souborům a podpora symbolických odkazů. Implementace Apache Ant si toho je vědoma do té míry, že dokáže vytvářet soubory s předdefinovanými unixovými oprávněními. Implementace Info-ZIP také vědí, jak používat možnosti opravy chyb integrované ve formátu komprimace .ZIP. Některé programy ne, a selže na souboru, který obsahuje chyby.
Nástroje Info-ZIP pro Windows také podporují oprávnění k souborovému systému NTFS a pokusí se přeložit z oprávnění NTFS na oprávnění Unix nebo naopak při extrahování souborů. To může mít za následek potenciálně nezamýšlené kombinace, např. Vytváření souborů .exe na svazcích NTFS se zamítnutým spustitelným oprávněním.
Verze systému Microsoft Windows obsahují podporu pro kompresi .ZIP v Průzkumníku od verze Microsoft Plus! pack byl vydán pro Windows 98. Microsoft tuto funkci nazývá „Compressed Folders“. Ne všechny funkce .ZIP jsou podporovány funkcí Windows Compressed Folders. Šifrování například není podporováno v edici Windows 10 Home, i když je lze dešifrovat. Kódování vstupu Unicode není podporováno do Windows 7 , zatímco rozdělené a rozložené archivy nejsou čitelné ani zapisovatelné pomocí funkce komprimovaných složek ani není podporováno šifrování AES.
Microsoft Office začal používat formát zip archivu v roce 2006 pro své soubory Office Open XML .docx, .xlsx, .pptx atd., Které se staly výchozím formátem souborů pro Microsoft Office 2007 .
Dědictví
Existuje řada dalších standardů a formátů, které jako součást svého názvu používají „zip“. Například zip je odlišný od gzip a ten je definován v IETF RFC 1952 . Zip i gzip primárně používají pro kompresi algoritmus DEFLATE . Podobně formát ZLIB (IETF RFC 1950 ) také používá kompresní algoritmus DEFLATE, ale určuje různé záhlaví pro kontrolu chyb a konzistence. Mezi další běžné, podobně pojmenované formáty a programy s různými nativními formáty patří 7-Zip , bzip2 a rzip .
Obavy
Teoretický maximální kompresní faktor pro surový proud DEFLATE je asi 1032 ku jedné, ale neúmyslným využíváním formátu ZIP lze vytvořit archivy ZIP s kompresními poměry miliard k jednomu. Tyto zipové bomby se rozbalí na extrémně velké velikosti a ohromí kapacitu počítače, na kterém jsou dekomprimovány.
Viz také
Reference
externí odkazy
- Poznámka k aplikaci .ZIP - vstupní stránka pro aktuální a historický soubor .ZIP společnosti PKWARE
- ISO/IEC 21320-1: 2015-Soubor kontejneru dokumentu-Část 1: Jádro
- Soubory Zip: Historie, vysvětlení a implementace
- Shrink, Reduce, and Implode: The Legacy Zip Compression Methods
- Zrcadlo APPNOTE.TXT
Specifikace formátu:
- Struktura souboru PKZip —grafické tabulky