.Pliki ZIP są archiwami, które przechowują wiele plików. ZIP pozwala na kompresję zawartych plików przy użyciu wielu różnych metod, jak również na proste przechowywanie pliku bez jego kompresji. Każdy plik jest przechowywany oddzielnie, dzięki czemu różne pliki w tym samym archiwum mogą być kompresowane przy użyciu różnych metod. Ponieważ pliki w archiwum ZIP są kompresowane oddzielnie, możliwe jest ich wyodrębnienie lub dodanie nowych bez stosowania kompresji lub dekompresji całego archiwum. To kontrastuje z formatem skompresowanych plików tar, dla których takie losowe przetwarzanie nie jest łatwo możliwe.
Katalog jest umieszczany na końcu pliku ZIP. To identyfikuje, jakie pliki są w ZIP i identyfikuje, gdzie w ZIP, że plik jest położony. Dzięki temu czytniki ZIP mogą wczytać listę plików bez czytania całego archiwum ZIP. Archiwa ZIP mogą również zawierać dodatkowe dane, które nie są związane z archiwum ZIP. Pozwala to na przekształcenie archiwum ZIP w archiwum samorozpakowujące się (aplikacja, która sama rozpakowuje zawarte w nim dane), poprzez dodanie kodu programu do archiwum ZIP i oznaczenie pliku jako wykonywalnego. Przechowywanie katalogu na końcu umożliwia również ukrycie zzipowanego pliku przez dołączenie go do nieszkodliwego pliku, takiego jak plik graficzny GIF.
Format .ZIP wykorzystuje 32-bitowy algorytm CRC i zawiera dwie kopie struktury katalogów archiwum w celu zapewnienia większej ochrony przed utratą danych.
StructureEdit
Plik ZIP jest prawidłowo identyfikowany przez obecność rekordu końca katalogu centralnego, który znajduje się na końcu struktury archiwum w celu umożliwienia łatwego dołączania nowych plików. Jeśli koniec centralnego rekordu katalogu wskazuje na niepuste archiwum, nazwa każdego pliku lub katalogu w ramach archiwum powinny być określone w centralnym wpisie katalogu, wraz z innymi metadanymi o wpisie, a offset do pliku ZIP, wskazując na rzeczywiste dane wpisu. Pozwala to na stosunkowo szybkie wykonanie spisu plików w archiwum, ponieważ nie trzeba czytać całego archiwum, aby zobaczyć listę plików. Wpisy w pliku ZIP również zawierają te informacje, dla nadmiarowości, w lokalnym nagłówku pliku. Ponieważ pliki ZIP mogą być dołączane, ważne są tylko pliki określone w katalogu centralnym na końcu pliku. Skanowanie pliku ZIP dla lokalnych nagłówków plików jest nieważne (z wyjątkiem uszkodzonych archiwów), ponieważ katalog centralny może deklarować, że niektóre pliki zostały usunięte i inne pliki zostały zaktualizowane.
Na przykład, możemy zacząć od pliku ZIP, który zawiera pliki A, B i C. Plik B jest następnie usunięty i C zaktualizowane. Można to osiągnąć przez dołączenie nowego pliku C do końca oryginalnego pliku ZIP i dodanie nowego katalogu centralnego, który zawiera tylko plik A i nowy plik C. Kiedy ZIP został po raz pierwszy zaprojektowany, przenoszenie plików za pomocą dyskietek było powszechne, ale zapisywanie na dyskach było bardzo czasochłonne. Jeśli miałeś duży plik zip, być może obejmujący wiele dysków i potrzebowałeś zaktualizować tylko kilka plików, zamiast czytać i ponownie zapisywać wszystkie pliki, byłoby znacznie szybciej po prostu przeczytać stary katalog centralny, dołączyć nowe pliki, a następnie dołączyć zaktualizowany katalog centralny.
Porządek wpisów plików w katalogu centralnym nie musi pokrywać się z porządkiem wpisów plików w archiwum.
Każdy wpis przechowywany w archiwum ZIP jest wprowadzany przez lokalny nagłówek pliku z informacjami o pliku, takimi jak komentarz, rozmiar pliku i nazwa pliku, a następnie opcjonalne „dodatkowe” pola danych, a następnie ewentualnie skompresowane, ewentualnie zaszyfrowane dane pliku. Dodatkowe” pola danych są kluczem do rozszerzalności formatu ZIP. „Dodatkowe” pola są wykorzystywane do obsługi formatu ZIP64, szyfrowania AES zgodnego z WinZip, atrybutów plików i znaczników czasu plików NTFS lub Unix o wyższej rozdzielczości. Inne rozszerzenia są możliwe poprzez pole „Extra”. Narzędzia ZIP są wymagane przez specyfikację do ignorowania pól Extra, których nie rozpoznają.
Format ZIP używa specyficznych 4-bajtowych „sygnatur” do oznaczania różnych struktur w pliku. Każdy wpis pliku jest oznaczony przez specyficzną sygnaturę. Koniec rekordu katalogu centralnego jest oznaczony specyficzną sygnaturą, a każdy wpis w katalogu centralnym zaczyna się od 4-bajtowej sygnatury nagłówka pliku centralnego.
W specyfikacji ZIP nie ma znacznika BOF lub EOF. Konwencjonalnie pierwszą rzeczą w pliku ZIP jest wpis ZIP, który może być łatwo zidentyfikowany przez jego lokalną sygnaturę nagłówka pliku. Jednak nie zawsze tak jest, ponieważ nie jest to wymagane przez specyfikację ZIP – przede wszystkim, samorozpakowujące się archiwum będzie zaczynać się od nagłówka pliku wykonywalnego.
Narzędzia, które poprawnie odczytują archiwa ZIP muszą skanować dla sygnatury końca rekordu katalogu centralnego, a następnie, odpowiednio, innych, wskazanych rekordów katalogu centralnego. Nie mogą one skanować dla wpisów z góry pliku ZIP, ponieważ (jak wspomniano wcześniej w tej sekcji) tylko katalog centralny określa, gdzie zaczyna się chunk pliku i że nie został usunięty. Skanowanie może prowadzić do fałszywych pozytywów, ponieważ format nie zabrania umieszczania innych danych pomiędzy kawałkami, ani też strumieni danych pliku zawierających takie sygnatury. Jednakże, narzędzia próbujące odzyskać dane z uszkodzonych archiwów ZIP najprawdopodobniej przeskanują archiwum w poszukiwaniu lokalnych sygnatur nagłówków plików; jest to utrudnione przez fakt, że skompresowany rozmiar kawałka pliku może być przechowywany po kawałku pliku, co utrudnia przetwarzanie sekwencyjne.
Większość sygnatur kończy się krótką liczbą całkowitą 0x4b50, która jest przechowywana w porządku little-endian. Jako ciąg znaków ASCII jest to „PK”, inicjały wynalazcy Phila Katza. Tak więc, gdy plik ZIP jest oglądany w edytorze tekstu, pierwsze dwa bajty pliku to zwykle „PK”. (DOS, OS/2 i Windows samorozpakowujące się ZIP-y mają EXE przed ZIP-em, więc zaczynają się od „MZ”; samorozpakowujące się ZIP-y dla innych systemów operacyjnych mogą być podobnie poprzedzone kodem wykonywalnym do rozpakowania zawartości archiwum na tej platformie.)
Specyfikacja .ZIP obsługuje także rozprzestrzenianie archiwów na wiele plików systemu plików. Pierwotnie przeznaczona do przechowywania dużych plików ZIP na wielu dyskietkach, ta cecha jest obecnie używana do wysyłania archiwów ZIP w częściach przez e-mail, lub przez inne środki transportu lub nośniki wymienne.
System plików FAT systemu DOS ma rozdzielczość znacznika czasu tylko dwie sekundy; rekordy plików ZIP naśladują to. W rezultacie, wbudowana rozdzielczość znacznika czasu plików w archiwum ZIP wynosi tylko dwie sekundy, chociaż dodatkowe pola mogą być używane do przechowywania bardziej precyzyjnych znaczników czasu. Format ZIP nie ma pojęcia strefy czasowej, więc znaczniki czasu mają znaczenie tylko wtedy, gdy wiadomo, w jakiej strefie czasowej zostały utworzone.
We wrześniu 2007 roku PKWARE wydało rewizję specyfikacji ZIP umożliwiającą przechowywanie nazw plików przy użyciu UTF-8, ostatecznie dodając zgodność z Unicode do ZIP.
Nagłówki plikówEdit
Wszystkie wielobajtowe wartości w nagłówku są przechowywane w kolejności bajtów little-endian. Wszystkie pola długości liczą długość w bajtach.
Nagłówek pliku lokalnegoEdit
| Offset | Bajty | Opis | |
|---|---|---|---|
| 0 | 4 | Opis nagłówka pliku lokalnego = 0x04034b50 (odczytane jako liczba little-endian number) | |
| 4 | 2 | Wersja potrzebna do wyodrębnienia (minimum) | |
| 6 | 2 | Flaga bitowa ogólnego przeznaczenia | |
| 8 | 2 | 2 | Metoda kompresji |
| 10 | 2 | Czas ostatniej modyfikacji pliku | |
| 12 | 2 | Data ostatniej modyfikacji pliku | |
| 14 | 4 | CRC-32 nieskompresowanych danych | |
| 18 | 4 | Rozmiar skompresowany (lub 0xffffffff dla ZIP64) | |
| 22 | 4 | Rozmiar nieskompresowany (lub 0xffffff dla ZIP64) | |
| 26 | 2 | Długość nazwy pliku (n) | |
| 28 | 2 | Długość dodatkowego pola (m) | |
| 30 | n | Nazwa pliku | |
| 30+n | m | Dodatkowe pole |
Dodatkowe pole zawiera różne opcjonalne dane, takie jak atrybuty specyficzne dla systemu operacyjnego.atrybuty specyficzne dla systemu operacyjnego. Jest podzielone na fragmenty, z których każdy ma 16-bitowy kod identyfikacyjny i 16-bitową długość. W przypadku ZIP64 zawsze istnieje przynajmniej jeden chunk (o kodzie ID 0001 i rozmiarze 32 bajtów), patrz poniżej.
Po nim bezpośrednio następują skompresowane dane.
Deskryptor danychEdit
Jeśli bit w offsecie 3 (0x08) pola flag ogólnego przeznaczenia jest ustawiony, to CRC-32 i rozmiary plików nie są znane podczas zapisywania nagłówka. Pola w nagłówku lokalnym są wypełniane zerem, a CRC-32 i rozmiar są dołączane w 12-bajtowej strukturze (opcjonalnie poprzedzonej 4-bajtową sygnaturą) bezpośrednio po skompresowanych danych:
| Offset | Bajty | Opis | |
|---|---|---|---|
| 0 | 0/4 | Opcjonalna sygnatura deskryptora danych = 0x08074b50 | |
| 0/4 | 4 | CRC-.32 nieskompresowanych danych | |
| 4/8 | 4 | 4 | rozmiar skompresowany |
| 8/12 | 4 | rozmiar nieskompresowany size |
Nagłówek pliku katalogu centralnegoEdit
Wpis do katalogu centralnego jest rozszerzoną formą nagłówka lokalnego:
| Offset | Bajty | Opis | |
|---|---|---|---|
| 0 | 4 | Centralny Podpis nagłówka pliku katalogu = 0x02014b50 | |
| 4 | 2 | 2 | |
| 6 | 2 | 2 | Wersja potrzebna do wyodrębnienia (minimalna) |
| 8 | 2 | flaga bitowa ogólnego przeznaczenia | |
| 10 | 2 | metoda kompresji | |
| 12 | 2 | Czas ostatniej modyfikacji pliku | |
| 14 | 2 | Data ostatniej modyfikacji pliku | |
| 16 | 4 | CRC-32 nieskompresowanych danych | |
| 20 | 4 | Rozmiar skompresowany (lub 0xffffff dla ZIP64) | |
| 24 | 4 | Rozmiar nieskompresowany (lub 0xffffff dla ZIP64) | |
| 28 | 2 | długość nazwy pliku (n) | |
| 30 | 2 | długość pola dodatkowego (m) | |
| 32 | 2 | Długość komentarza do pliku (k) | |
| 34 | 2 | Numer dysku, na którym zaczyna się plik | |
| 36 | 2 | 2 | Wewnętrzne atrybuty pliku |
| 38 | 4 | Zewnętrzne atrybuty pliku | |
| 42 | 4 | Względne przesunięcie nagłówka pliku lokalnego. Jest to liczba bajtów pomiędzy początkiem pierwszego dysku, na którym występuje plik, a początkiem nagłówka pliku lokalnego. Pozwala to oprogramowaniu odczytującemu katalog centralny zlokalizować pozycję pliku wewnątrz pliku ZIP. | |
| 46 | n | Nazwa pliku | |
| 46+n | m | Dodatkowe pole | |
| 46+n+m | k | k | Komentarz pliku |
Koniec centralnego rekordu katalogu (EOCD)Edycja
Po wszystkich wpisach centralnego katalogu przychodzi rekord końca centralnego katalogu (EOCD), który oznacza koniec pliku ZIP:
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | End of sygnatura katalogu centralnego = 0x06054b50 |
| 4 | 2 | 2 |
| 6 | 2 | Dysk, na którym zaczyna się katalog centralny zaczyna się |
| 8 | 2 | Liczba rekordów katalogu centralnego na tym dysku |
| 10 | 2 | Całkowita liczba rekordów katalogu centralnego |
| 10 | 2 | Całkowita liczba rekordów katalogu centralnego katalogów |
| 12 | 4 | Rozmiar katalogu centralnego (bajty) |
| 16 | 4 | Offset początku katalogu centralnego, względem początku archiwum |
| 20 | 2 | Długość komentarza (n) |
| 22 | n | Komentarz |
To uporządkowanie pozwala na utworzenie pliku ZIP w jednym przebiegu, ale katalog centralny jest również umieszczony na końcu pliku w celu ułatwienia łatwego usuwania plików z wielu części (np.np. „wielu dyskietek”) archiwów, jak wcześniej omówiono.
Metody kompresjiEdit
Specyfikacja formatu pliku .ZIP dokumentuje następujące metody kompresji: Store (brak kompresji), Shrink (LZW), Reduce (poziomy 1-4; LZ77 + probabilistyczna), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd oraz wariant LZ77 dostarczany przez instrukcję IBM z/OS CMPSC. Najczęściej używaną metodą kompresji jest DEFLATE, która jest opisana w IETF RFC 1951.
Inne metody wspomniane, ale nie udokumentowane szczegółowo w specyfikacji obejmują: PKWARE DCL Implode (stary IBM TERSE), nowy IBM TERSE, IBM LZ77 z Architecture (PFS), oraz wariant JPEG. Metoda „Tokenize” była zarezerwowana dla strony trzeciej, ale wsparcie nigdy nie zostało dodane.
Słowo Implode jest nadużywane przez PKWARE: DCL/TERSE Implode jest różne od starego PKZIP Implode, poprzednika Deflate. Implode DCL jest nieudokumentowany częściowo z powodu jego własności przez IBM, ale Mark Adler mimo to dostarczył dekompresor o nazwie „blast” obok zlib.
EncryptionEdit
ZIP obsługuje prosty, oparty na haśle system szyfrowania symetrycznego, ogólnie znany jako ZipCrypto. Jest on udokumentowany w specyfikacji ZIP, i wiadomo, że jest poważnie wadliwy. W szczególności, jest on podatny na ataki typu know-plaintext, które w niektórych przypadkach są pogarszane przez słabe implementacje generatorów liczb losowych.
Nowe funkcje, w tym nowe metody kompresji i szyfrowania (np. AES) zostały udokumentowane w specyfikacji formatu pliku ZIP od wersji 5.2. Opracowany przez WinZip otwarty standard oparty na AES („AE-x” w APPNOTE) jest używany także przez 7-Zip i Xceed, ale niektórzy dostawcy używają innych formatów. PKWARE SecureZIP (SES, własnościowy) obsługuje również metody szyfrowania RC2, RC4, DES, Triple DES, szyfrowanie i uwierzytelnianie oparte na certyfikatach cyfrowych (X.509) oraz szyfrowanie nagłówków archiwów. Jest jednak opatentowany (zobacz § Kontrowersje wokół silnego szyfrowania).
Szyfrowanie nazw plików zostało wprowadzone w specyfikacji formatu plików .ZIP 6.2, która szyfruje metadane przechowywane w części Central Directory archiwum, ale sekcje Local Header pozostają niezaszyfrowane. Archiwizator spełniający wymagania może sfałszować dane nagłówka lokalnego podczas korzystania z szyfrowania katalogu centralnego. Od wersji 6.2 specyfikacji, pola Compression Method i Compressed Size w Local Header nie są jeszcze maskowane.
ZIP64Edit
Oryginalny format .ZIP miał limit 4 GiB (232 bajtów) na różne rzeczy (nieskompresowany rozmiar pliku, skompresowany rozmiar pliku i całkowity rozmiar archiwum), jak również limit 65 535 (216) wpisów w archiwum ZIP. W wersji 4.5 specyfikacji (która nie jest taka sama jak v4.5 jakiegokolwiek konkretnego narzędzia), PKWARE wprowadziło rozszerzenia formatu „ZIP64”, aby obejść te ograniczenia, zwiększając limity do 16 EiB (264 bajtów). W zasadzie, używa on „normalnego” wpisu do katalogu centralnego dla pliku, po którym następuje opcjonalny wpis do katalogu „zip64”, który ma większe pola.
Format nagłówka pliku lokalnego i wpisu do katalogu centralnego są takie same w ZIP i ZIP64, ale dla rozmiarów zawsze przechowywanych 0xffffff, a dodatkowe pole zawsze istnieje:
| Offset | Bajty | Opis |
|---|---|---|
| 0 | 2 | Header ID 0x0001 |
| 2 | 2 | Rozmiar kawałka dodatkowego pola (16, 24 lub 28) |
| 4 | 8 | Oryginalny rozmiar nieskompresowanego pliku |
| 12 | 8 | Rozmiar skompresowanych danych |
| 20 | 8 | Offset lokalnego rekordu nagłówka |
| 28 | 4 | Numer dysku, na którym zaczyna się ten plik |
Z drugiej strony, format EOCD dla ZIP64 jest nieco inny niż dla normalnej wersji ZIP (patrz sekcja 4.3.14).
| Offset | Bajty | Opis |
|---|---|---|
| 0 | 4 | End of central directory signature = 0x06064b50 |
| 4 | 8 | Rozmiar EOCD64 -. 8 |
| 12 | 2 | Wersja wykonana przez |
| 14 | 2 | Wersja potrzebna do wyodrębnienia (minimalna) |
| 16 | 4 | Numer tego dysku |
| 20 | 4 | Dysk, na którym zaczyna się centralny katalog |
| 24 | 8 | Liczba wpisów katalogu centralnego na tym dysku |
| 32 | 8 | Całkowita liczba wpisów katalogu centralnego |
| 40 | 8 | Rozmiar katalogu centralnego (bajty) |
| 48 | 8 | Offset początku katalogu centralnego, względem początku archiwum |
| 56 | n | Komentarz (do rozmiaru EOCD64) |
Niekoniecznie jest to również ostatni rekord w pliku, opcjonalny lokalizator końca katalogu centralnego (End of Central Directory Locator) może nastąpić po nim (dodatkowe 20 bajtów na końcu).
Eksplorator plików w Windows XP nie obsługuje ZIP64, ale Eksplorator w Windows Vista i nowszych już tak. Podobnie, niektóre biblioteki rozszerzeń obsługują ZIP64, takie jak DotNetZip, QuaZIP i IO::Compress::Zip w Perlu. Wbudowany w Pythona plik zipfile obsługuje go od wersji 2.5, a od 3.4 domyślnie. Wbudowany java.util.zip w OpenJDK obsługuje ZIP64 od wersji Java 7. Android Java API obsługuje ZIP64 od wersji Android 6.0. Narzędzie do archiwizacji Mac OS Sierra nie obsługuje ZIP64 i może tworzyć uszkodzone archiwa, gdy ZIP64 byłby wymagany. Jednak polecenie ditto dostarczane z systemem Mac OS rozpakowuje pliki ZIP64. Nowsze wersje Mac OS są dostarczane z narzędziami info-zip’s zip i unzip wiersza poleceń, które obsługują Zip64: aby sprawdzić, uruchom zip -v i poszukaj „ZIP64_SUPPORT”.
Połączenie z innymi formatami plikówEdit
Format pliku .ZIP pozwala na komentarz zawierający do 65 535 (216-1) bajtów danych, aby wystąpić na końcu pliku po katalogu centralnym. Ponadto, ponieważ katalog centralny określa offset każdego pliku w archiwum w odniesieniu do początku, możliwe jest, aby pierwszy wpis pliku rozpocząć w offsecie innym niż zero, chociaż niektóre narzędzia, na przykład gzip, nie będzie przetwarzać pliki archiwalne, które nie zaczynają się z wpisem pliku w offsecie zero.
To pozwala arbitralne dane do wystąpienia w pliku zarówno przed i po danych archiwum ZIP, a dla archiwum nadal być odczytywane przez aplikację ZIP. Efektem ubocznym tego rozwiązania jest możliwość stworzenia pliku, który jest zarówno działającym archiwum ZIP, jak i plikiem w innym formacie, pod warunkiem, że ten drugi format toleruje dowolne dane na końcu, początku lub w środku. Archiwa samorozpakowujące się (SFX), w formie obsługiwanej przez WinZip, korzystają z tego, ponieważ są plikami wykonywalnymi (.exe), które są zgodne ze specyfikacją PKZIP AppNote.txt i mogą być odczytywane przez zgodne narzędzia lub biblioteki zip.
Ta właściwość formatu .ZIP oraz formatu JAR, który jest odmianą ZIP, może zostać wykorzystana do ukrycia nieuczciwej zawartości (takiej jak szkodliwe klasy Java) wewnątrz pozornie nieszkodliwego pliku, takiego jak obrazek GIF umieszczony w sieci. Ten tak zwany exploit GIFAR został zademonstrowany jako skuteczny atak na aplikacje internetowe, takie jak Facebook.
LimitsEdit
Minimalny rozmiar pliku .ZIP wynosi 22 bajty. Taki pusty plik .zip zawiera tylko rekord EOCD (End of Central Directory Record):
Maksymalny rozmiar zarówno pliku archiwum, jak i poszczególnych plików w nim zawartych wynosi 4 294 967 295 bajtów (232-1 bajtów, czyli 4 GiB minus 1 bajt) dla standardowego ZIP. Dla ZIP64, maksymalny rozmiar wynosi 18 446 744 073 709 551 615 bajtów (264-1 bajtów, lub 16 EiB minus 1 bajt).
Rozszerzenia zastrzeżoneEdit
Dodatkowe poleEdit
.Format pliku ZIP zawiera funkcję pól dodatkowych w nagłówkach plików, które mogą być używane do przechowywania dodatkowych danych niezdefiniowanych przez istniejące specyfikacje ZIP i które pozwalają zgodnym archiwizatorom, które nie rozpoznają tych pól, bezpiecznie je pominąć. Identyfikatory nagłówka 0-31 są zarezerwowane dla PKWARE. Pozostałe ID mogą być używane przez innych producentów do własnych zastosowań.
Kontrowersje wokół silnego szyfrowaniaEdit
Kiedy WinZip 9.0 public beta został wydany w 2003 roku, WinZip wprowadził własne szyfrowanie AES-256, używając innego formatu pliku, wraz z dokumentacją dla nowej specyfikacji. Same standardy szyfrowania nie były zastrzeżone, ale PKWARE nie uaktualniło APPNOTE.TXT, aby uwzględnić Strong Encryption Specification (SES) od 2001 roku, która była używana przez PKZIP w wersjach 5.0 i 6.0. Konsultant techniczny WinZip Kevin Kearney i menedżer produktu StuffIt Mathew Covington oskarżyli PKWARE o wstrzymanie SES, ale szef technologii PKZIP Jim Peterson twierdził, że szyfrowanie oparte na certyfikatach było wciąż niekompletne.
W kolejnym kontrowersyjnym posunięciu PKWare złożyło 16 lipca 2003 roku wniosek o patent opisujący metodę połączenia ZIP i silnego szyfrowania w celu stworzenia bezpiecznego pliku.
W końcu PKWARE i WinZip zgodziły się wspierać nawzajem swoje produkty. 21 stycznia 2004 roku PKWARE ogłosiło wsparcie dla opartego na WinZipie formatu kompresji AES. W późniejszej wersji beta WinZip był w stanie obsługiwać pliki ZIP oparte na SES. PKWARE w końcu udostępniło publicznie wersję 5.2 specyfikacji formatu pliku .ZIP, która dokumentowała SES. Projekt wolnego oprogramowania 7-Zip również obsługuje AES, ale nie SES w plikach ZIP (podobnie jak jego port POSIX p7zip).
Podczas używania szyfrowania AES w WinZip, metoda kompresji jest zawsze ustawiona na 99, z rzeczywistą metodą kompresji przechowywaną w dodatkowym polu danych AES. Natomiast Strong Encryption Specification przechowuje metodę kompresji w podstawowym segmencie nagłówka pliku w Local Header i Central Directory, chyba że Central Directory Encryption jest używane do maskowania/szyfrowania metadanych.
.