ZIP (format pliku) - ZIP (file format)

Format pliku ZIP
Rozszerzenie nazwy pliku .zip .zipx
Rodzaj mediów internetowych application/zip
Jednolity identyfikator typu (UTI) com.pkware.zip-archiwum
magiczny numer
Opracowany przez PKWARE, Inc.
Pierwsze wydanie 14 lutego 1989 ; 32 lata temu ( 14.02.1989 )
Najnowsze wydanie
6.3.9
(15 lipiec 2020 ; 14 miesięcy temu ) ( 15.07.2020 )
Rodzaj formatu Kompresja danych
Rozszerzony do
Standard APPNOTE z PKWARE
ISO/IEC 21320-1:2015 (podzbiór formatu ZIP 6.3.3)
Otwarty format ? tak

ZIP to format pliku archiwum, który obsługuje bezstratną kompresję danych . Plik ZIP może zawierać jeden lub więcej plików lub katalogów, które mogły zostać skompresowane. Format pliku ZIP pozwala na wiele algorytmów kompresji , chociaż DEFLATE jest najbardziej powszechny. Format ten został utworzony w 1989 roku i po raz pierwszy realizowany w PKWARE, Inc. „s PKZIP użyteczności, jako zamiennik dla poprzedniego ARC format kompresji przez Thom Henderson. Format ZIP był szybko obsługiwany przez wiele narzędzi programowych innych niż PKZIP. Firma Microsoft włączyła wbudowaną obsługę ZIP (pod nazwą „foldery skompresowane”) w wersjach systemu Microsoft Windows od 2000 r. (Windows Me). Firma Apple włączyła wbudowaną obsługę ZIP w systemie Mac OS X 10.3 (za pośrednictwem BOMArchiveHelper, teraz Archive Utility ) i nowszych. Większość darmowych systemów operacyjnych ma wbudowaną obsługę ZIP w podobny sposób jak Windows i Mac OS X.

Pliki ZIP zwykle mają rozszerzenia .zip lub .ZIP i typ nośnika MIMEapplication/zip . ZIP jest używany jako podstawowy format pliku przez wiele programów, zwykle pod inną nazwą. Podczas nawigacji w systemie plików za pomocą interfejsu użytkownika ikony graficzne reprezentujące pliki ZIP często pojawiają się jako dokument lub inny obiekt z widocznym zamkiem błyskawicznym .

Historia

ZIP Format pliku zaprojektowana przez Phil Katz z PKWARE i Gary Conway nieskończoności Projektują Pojęcia. Format powstał po tym, jak firma Systems Enhancement Associates (SEA) złożyła pozew przeciwko firmie PKWARE, twierdząc, że jej produkty do archiwizacji, nazwane PKARC, są pochodnymi systemu archiwizacji ARC firmy SEA . Nazwa „zip” (co oznacza „poruszaj się z dużą prędkością”) została zasugerowana przez przyjaciela Katza, Roberta Mahoneya. Chcieli zasugerować, że ich produkt będzie szybszy niż ARC i inne ówczesne formaty kompresji. Najwcześniejsza znana wersja specyfikacji formatu pliku .ZIP została po raz pierwszy opublikowana jako część pakietu PKZIP 0.9 w pliku APPNOTE.TXT w 1989 roku. Dzięki rozpowszechnianiu formatu pliku zip w ramach APPNOTE.TXT zgodność z formatem pliku zip rozpowszechniła się szeroko w społeczeństwie Internet w latach 90.

PKWARE i Infinity Design Concepts wydały wspólny komunikat prasowy 14 lutego 1989 r., udostępniając plik w formacie .ZIP do domeny publicznej .

Historia wersji

Specyfikacja formatu pliku .ZIP ma swój własny numer wersji, który niekoniecznie odpowiada numerom wersji narzędzia PKZIP, zwłaszcza PKZIP 6 lub nowszego. W różnych okresach PKWARE dodawał wstępne funkcje, które pozwalają produktom PKZIP na wyodrębnianie archiwów przy użyciu zaawansowanych funkcji, ale produkty PKZIP, które tworzą takie archiwa, są udostępniane dopiero w następnej głównej wersji. Inne firmy lub organizacje wspierają specyfikacje PKWARE we własnym tempie.

Specyfikacja formatu pliku .ZIP nosi formalną nazwę „APPNOTE - Specyfikacja formatu pliku .ZIP” i jest publikowana na stronie internetowej PKWARE.com od końca lat dziewięćdziesiątych. Kilka wersji specyfikacji nie zostało opublikowanych. Specyfikacje niektórych funkcji, takich jak kompresja BZIP2 , specyfikacja silnego szyfrowania i inne, zostały opublikowane przez PKWARE kilka lat po ich utworzeniu. Na stronie PKWARE kilkakrotnie zmieniano adres URL specyfikacji online.

Podsumowanie najważniejszych osiągnięć w różnych wersjach specyfikacji PKWARE:

  • 2.0: (1993) Wpisy plików można kompresować za pomocą DEFLATE i używać tradycyjnego szyfrowania PKWARE (ZipCrypto).
  • 2.1: (1996) Kompresja Deflate64
  • 4.5: (2001) Udokumentowany 64-bitowy format zip.
  • 4.6: (2001) kompresja BZIP2 (nieopublikowana online do czasu publikacji APPNOTE 5.2)
  • 5.0: (2002) SES: DES , Triple DES , RC2 , RC4 obsługiwane do szyfrowania (nieopublikowane online do czasu publikacji APPNOTE 5.2)
  • 5.2: (2003) obsługa szyfrowania AES dla SES (zdefiniowana w APPNOTE 5.1, która nie została opublikowana online) i AES z WinZip („AE-x”); poprawiona wersja RC2-64 obsługiwana do szyfrowania SES.
  • 6.1: (2004) Przechowywanie udokumentowanych certyfikatów.
  • 6.2.0: (2004) Udokumentowane szyfrowanie katalogu centralnego.
  • 6.3.0: (2006) Przechowywanie udokumentowanych nazw plików Unicode ( UTF-8 ). Rozszerzona lista obsługiwanych algorytmów kompresji ( LZMA , PPMd+ ), algorytmów szyfrowania ( Blowfish , Twofish ) oraz hashy.
  • 6.3.1: (2007) Poprawione standardowe wartości skrótu dla SHA-256/384/512.
  • 6.3.2: (2007) Udokumentowana metoda kompresji 97 ( WavPack ).
  • 6.3.3: (2012) Zmiany formatowania dokumentów w celu ułatwienia odwoływania się do Noty Aplikacyjnej PKWARE z innych standardów przy użyciu metod takich jak JTC 1 Referencing Explanatory Report (RER) zgodnie z zaleceniami JTC 1/SC 34 N 1621.
  • 6.3.4: (2014) Aktualizuje adres biura PKWARE, Inc.
  • 6.3.5: (2018) Udokumentowane metody kompresji 16, 96 i 99, epoka i precyzja sygnatury czasowej DOS, dodano dodatkowe pola na klucze i deszyfrowanie, a także literówki i wyjaśnienia.
  • 6.3.6: (2019) Poprawiony błąd typograficzny.
  • 6.3.7: (2020) Dodano metodę kompresji Zstandard ID 20.
  • 6.3.8: (2020) Przeniesiono identyfikator metody kompresji Zstandard z 20 do 93, wycofując pierwszy. Udokumentowane identyfikatory metod 94 i 95 (odpowiednio MP3 i XZ ).
  • 6.3.9: (2020) Poprawiono literówkę w opisie wyrównania strumienia danych.

WinZip , począwszy od wersji 12.1, używa rozszerzenia .zipx dla plików ZIP, które używają metod kompresji nowszych niż DEFLATE; w szczególności metody BZip, LZMA, PPMd, JPEG i Wavpack. Ostatnie 2 są stosowane do odpowiednich typów plików, gdy wybrana jest kompresja „Najlepsza metoda”.

Normalizacja

W kwietniu 2010 r. ISO/IEC JTC 1 zainicjowało głosowanie w celu ustalenia, czy należy rozpocząć projekt w celu stworzenia formatu normy międzynarodowej ISO/IEC zgodnej z ZIP. Proponowany projekt, zatytułowany Pakowanie dokumentów , przewidywał „minimalny format skompresowanego archiwum” zgodny z ZIP, nadający się do użytku z wieloma istniejącymi standardami, w tym OpenDocument , Office Open XML i EPUB .

W 2015 r. opublikowano normę ISO/IEC 21320-1 „Plik kontenera dokumentów — część 1: rdzeń”, w której stwierdzono, że „Pliki kontenera dokumentów są zgodne z plikami Zip”. Wymaga następujących głównych ograniczeń formatu pliku ZIP:

  • Pliki w archiwach ZIP mogą być przechowywane tylko w postaci nieskompresowanej lub przy użyciu kompresji „deflate” (tzn. metoda kompresji może zawierać wartość „0” – przechowywany lub „8” – deflated).
  • Funkcje szyfrowania są zabronione.
  • Funkcje podpisu cyfrowego (z SES) są zabronione.
  • Funkcje „poprawione dane” (z PKPatchMaker) są zabronione.
  • Archiwa nie mogą obejmować wielu woluminów ani być podzielone na segmenty.

Projekt

Pliki .ZIP to archiwa przechowujące wiele plików. ZIP umożliwia kompresję zawartych plików przy użyciu wielu różnych metod, a także po prostu przechowywanie pliku bez kompresji. Każdy plik jest przechowywany oddzielnie, co pozwala na kompresję różnych plików w tym samym archiwum przy użyciu różnych metod. Ponieważ pliki w archiwum ZIP są skompresowane pojedynczo, możliwe jest ich rozpakowanie lub dodanie nowych bez stosowania kompresji lub dekompresji do całego archiwum. Kontrastuje to z formatem skompresowanych plików tar , dla których takie przetwarzanie z dostępem swobodnym nie jest łatwo możliwe.

Katalog jest umieszczany na końcu pliku ZIP. To identyfikuje, jakie pliki znajdują się w archiwum ZIP i określa, gdzie w pliku ZIP znajduje się ten plik. Dzięki temu czytniki ZIP mogą załadować 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 samorozpakowujące się archiwum (aplikację, która dekompresuje zawarte w nim dane), dodając kod programu do archiwum ZIP i oznaczając plik jako wykonywalny. Przechowywanie katalogu na końcu umożliwia również ukrycie spakowanego pliku poprzez dołączenie go do nieszkodliwego pliku, takiego jak plik obrazu GIF.

ZIP Format wykorzystuje 32-bitowy algorytm CRC i obejmuje dwie kopie struktury katalogów archiwum, aby zapewnić lepszą ochronę przed utratą danych.

Struktura

Układ wewnętrzny ZIP-64

Plik ZIP jest prawidłowo identyfikowany dzięki obecności końca rekordu katalogu centralnego, który znajduje się na końcu struktury archiwum, aby umożliwić łatwe dołączanie nowych plików. Jeśli koniec rekordu katalogu centralnego wskazuje, że archiwum nie jest puste, nazwę każdego pliku lub katalogu w archiwum należy określić we wpisie katalogu centralnego , wraz z innymi metadanymi dotyczącymi wpisu oraz przesunięciem do pliku ZIP, wskazując do rzeczywistych danych wejściowych. Pozwala to na stosunkowo szybkie wykonanie listy plików archiwum, ponieważ całe archiwum nie musi być odczytywane, aby zobaczyć listę plików. Wpisy w pliku ZIP zawierają również te informacje, w celu zapewnienia nadmiarowości, w lokalnym nagłówku pliku . Ponieważ pliki ZIP mogą być dołączane do pliku, ważne są tylko pliki określone w katalogu centralnym na końcu pliku. Skanowanie pliku ZIP w poszukiwaniu lokalnych nagłówków plików jest nieprawidłowe (z wyjątkiem uszkodzonych archiwów), ponieważ katalog centralny może deklarować, że niektóre pliki zostały usunięte, a inne zaktualizowane.

Na przykład możemy zacząć od pliku ZIP, który zawiera pliki A, B i C. Plik B jest następnie usuwany, a C aktualizowany. Można to osiągnąć przez dodanie nowego pliku C na końcu oryginalnego pliku ZIP i dodanie nowego katalogu centralnego, który zawiera tylko plik A i nowy plik C. Kiedy ZIP był po raz pierwszy projektowany, przesyłanie plików na dyskietce było powszechne, jednak zapisywanie na dyskach było bardzo czasochłonne. Jeśli masz duży plik zip, prawdopodobnie obejmujący wiele dysków i wystarczy zaktualizować kilka plików, zamiast odczytywać i ponownie zapisywać wszystkie pliki, znacznie szybciej byłoby po prostu przeczytać stary katalog centralny, dołączyć nowe pliki następnie dołącz zaktualizowany katalog centralny.

Kolejność wpisów plików w katalogu centralnym nie musi pokrywać się z kolejnością 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, po których następują opcjonalne "dodatkowe" pola danych, a następnie ewentualnie skompresowane, prawdopodobnie zaszyfrowane dane pliku. Pola danych „Extra” są kluczem do rozszerzalności formatu ZIP. Pola „Extra” 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ę, aby ignorować dodatkowe pola, których nie rozpoznają.

Format ZIP wykorzystuje określone 4-bajtowe „podpisy” do oznaczenia różnych struktur w pliku. Każdy wpis w pliku jest oznaczony konkretnym podpisem. Koniec rekordu w centralnym katalogu oznaczony jest jego specyficznym podpisem, a każdy wpis w centralnym katalogu rozpoczyna się 4-bajtowym podpisem nagłówka pliku centralnego .

W specyfikacji ZIP nie ma znacznika BOF ani EOF. Zwykle pierwszą rzeczą w pliku ZIP jest wpis ZIP, który można łatwo zidentyfikować po lokalnym podpisie nagłówka pliku . Jednak niekoniecznie tak jest, ponieważ nie jest to wymagane przez specyfikację ZIP - przede wszystkim samorozpakowujące się archiwum zaczyna się od nagłówka pliku wykonywalnego.

Narzędzia, które poprawnie odczytują archiwa ZIP, muszą skanować w poszukiwaniu końca podpisu rekordu katalogu centralnego, a następnie, odpowiednio, innych wskazanych rekordów katalogu centralnego. Nie wolno im skanować w poszukiwaniu wpisów z początku pliku ZIP, ponieważ (jak wspomniano wcześniej w tej sekcji) tylko katalog centralny określa, gdzie zaczyna się porcja pliku i że nie został usunięty. Skanowanie może prowadzić do fałszywych alarmów, ponieważ format nie zabrania umieszczania innych danych między porcjami ani strumieni danych plików zawierających takie sygnatury. Jednak narzędzia, które próbują odzyskać dane z uszkodzonych archiwów ZIP, najprawdopodobniej przeskanują archiwum w poszukiwaniu lokalnych podpisów nagłówków plików; jest to tym trudniejsze, że skompresowany rozmiar porcji pliku może być przechowywany po porcji pliku, co utrudnia przetwarzanie sekwencyjne.

Większość podpisów kończy się krótką liczbą całkowitą 0x4b50, która jest przechowywana w kolejności little-endian . Widziany jako ciąg znaków ASCII, oznacza to „PK”, inicjały wynalazcy Phila Katza. Tak więc, gdy plik ZIP jest przeglądany w edytorze tekstu, pierwsze dwa bajty pliku to zwykle „PK”. (Samorozpakowujące się pliki ZIP w systemach DOS, OS/2 i Windows mają plik EXE przed plikiem ZIP, więc zaczynają się od „MZ”; samorozpakowujące się pliki ZIP dla innych systemów operacyjnych mogą podobnie być poprzedzone kodem wykonywalnym służącym do wyodrębnienia zawartości archiwum na tej platformie.)

Specyfikacja .ZIP obsługuje również rozłożenie archiwów na wiele plików systemu plików. Pierwotnie przeznaczona do przechowywania dużych plików ZIP na wielu dyskietkach , ta funkcja jest teraz używana do wysyłania archiwów ZIP w częściach za pośrednictwem poczty e-mail lub innych nośników lub nośników wymiennych.

System plików FAT DOS ma rozdzielczość znacznika czasu wynoszącą tylko dwie sekundy; Rekordy pliku ZIP naśladują to. W rezultacie rozdzielczość wbudowanego znacznika czasu plików w archiwum ZIP wynosi tylko dwie sekundy, chociaż można użyć dodatkowych pól do przechowywania bardziej precyzyjnych znaczników czasu. Format ZIP nie ma pojęcia o strefie czasowej , więc sygnatury czasowe mają znaczenie tylko wtedy, gdy wiadomo, w jakiej strefie czasowej zostały utworzone.

We wrześniu 2007 roku PKWARE wydało rewizję specyfikacji ZIP zapewniającą przechowywanie nazw plików przy użyciu UTF-8 , ostatecznie dodając kompatybilność z Unicode do ZIP.

Nagłówki plików

Wszystkie wartości wielobajtowe w nagłówku są przechowywane w kolejności bajtów little-endian . Wszystkie pola długości liczą długość w bajtach.

Lokalny nagłówek pliku

Lokalny nagłówek pliku
Zrównoważyć Bajty Opis
0 4 Podpis nagłówka pliku lokalnego = 0x04034b50 (PK♥♦ lub "PK\3\4")
4 2 Wersja potrzebna do wyodrębnienia (minimum)
6 2 Flaga bitowa ogólnego przeznaczenia
8 2 Metoda kompresji; np. brak = 0, DEFLATE = 8 (lub "\0x08\0x00")
10 2 Czas ostatniej modyfikacji pliku
12 2 Data ostatniej modyfikacji pliku
14 4 CRC-32 nieskompresowanych danych
18 4 Skompresowany rozmiar (lub 0xffffffff dla ZIP64)
22 4 Nieskompresowany rozmiar (lub 0xffffffff dla ZIP64)
26 2 Długość nazwy pliku ( n )
28 2 Dodatkowa długość pola ( m )
30 n Nazwa pliku
30+ n m Dodatkowe pole

Dodatkowe pole zawiera szereg opcjonalnych danych, takich jak atrybuty specyficzne dla systemu operacyjnego. Jest podzielony na rekordy, każdy z co najmniej 16-bitową sygnaturą i 16-bitową długością. Na przykład rekord dodatkowego pola pliku lokalnego ZIP64 ma sygnaturę 0x0001 i długość 16 bajtów (lub więcej), dzięki czemu mogą następować dwie wartości 64-bitowe (rozmiary skompresowane i nieskompresowane). Innym powszechnym lokalnym rozszerzeniem pliku jest 0x5455 (lub „UT”), które zawiera 32-bitowe znaczniki czasu UTC UNIX.

Po tym następuje natychmiast skompresowane dane.

Deskryptor danych

Jeśli bit pod offsetem 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 lokalnym nagłówku są wypełnione zerami, a CRC-32 i rozmiar dołączane są w 12-bajtowej strukturze (opcjonalnie poprzedzonej 4-bajtową sygnaturą) bezpośrednio po skompresowanych danych:

Deskryptor danych
Zrównoważyć Bajty Opis
0 0/4 Opcjonalny podpis deskryptora danych = 0x08074b50
0/4 4 CRC-32 nieskompresowanych danych
4/8 4 Skompresowany rozmiar
8/12 4 Nieskompresowany rozmiar

Nagłówek pliku katalogu centralnego

Wpis centralnego katalogu jest rozwiniętą formą lokalnego nagłówka:

Nagłówek pliku katalogu centralnego
Zrównoważyć Bajty Opis
0 4 Podpis nagłówka pliku katalogu centralnego = 0x02014b50
4 2 Wersja wykonana przez
6 2 Wersja potrzebna do wyodrębnienia (minimum)
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 Skompresowany rozmiar (lub 0xffffffff dla ZIP64)
24 4 Nieskompresowany rozmiar (lub 0xffffffff dla ZIP64)
28 2 Długość nazwy pliku ( n )
30 2 Dodatkowa długość pola ( m )
32 2 Długość komentarza do pliku ( k )
34 2 Numer dysku, na którym zaczyna się plik
36 2 Wewnętrzne atrybuty pliku
38 4 Atrybuty plików zewnętrznych
42 4 Względne przesunięcie nagłówka pliku lokalnego. Jest to liczba bajtów między początkiem pierwszego dysku, na którym występuje plik, a początkiem nagłówka pliku lokalnego. Dzięki temu oprogramowanie odczytujące centralny katalog może zlokalizować pozycję pliku w pliku ZIP.
46 n Nazwa pliku
46+ n m Dodatkowe pole
46+ n + m k Komentarz do pliku

Koniec wpisu do centralnego katalogu (EOCD)

Po wszystkich wpisach katalogu centralnego następuje koniec rekordu katalogu centralnego (EOCD), co oznacza koniec pliku ZIP:

Koniec wpisu do centralnego katalogu (EOCD)
Zrównoważyć Bajty Opis
0 4 Koniec podpisu centralnego katalogu = 0x06054b50
4 2 Numer tego dysku (lub 0xffff dla ZIP64)
6 2 Dysk, na którym zaczyna się katalog centralny (lub 0xffff dla ZIP64)
8 2 Liczba rekordów katalogu centralnego na tym dysku (lub 0xffff dla ZIP64)
10 2 Całkowita liczba rekordów w centralnym katalogu (lub 0xffff dla ZIP64)
12 4 Rozmiar katalogu centralnego (w bajtach) (lub 0xffffffff dla ZIP64)
16 4 Przesunięcie początku katalogu centralnego względem początku archiwum (lub 0xffffffff dla ZIP64)
20 2 Długość komentarza ( n )
22 n Komentarz

Ta kolejność pozwala na utworzenie pliku ZIP w jednym przebiegu, ale centralny katalog jest również umieszczany na końcu pliku, aby ułatwić łatwe usuwanie plików z archiwów wieloczęściowych (np. „wiele dyskietek”) , ponieważ omówione wcześniej.

Metody kompresji

Specyfikacja formatu pliku .ZIP dokumentuje następujące metody kompresji: Store (bez kompresji), Shrink (LZW), Reduce (poziomy 1–4; LZ77 + probabilistyczny), Implode, Deflate, Deflate64, bzip2 , LZMA , WavPack , PPMd i wariant LZ77 dostarczony przez instrukcję IBM z/OS CMPSC. Najczęściej stosowaną metodą kompresji jest DEFLATE , opisana w IETF RFC  1951 .

Inne wymienione metody, ale nieudokumentowane szczegółowo w specyfikacji to: 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 nigdy nie dodano obsługi.

Słowo Implode jest nadużywane przez PKWARE: DCL/TERSE Implode różni się od starego PKZIP Implode, poprzednika Deflate. DCL Implode jest częściowo nieudokumentowany ze względu na jego własność należącą do IBM, ale Mark Adler dostarczył wraz z zlib dekompresor o nazwie „blast”.

Szyfrowanie

ZIP obsługuje prosty system szyfrowania symetrycznego oparty na hasłach , ogólnie znany jako ZipCrypto. Jest to udokumentowane w specyfikacji ZIP i wiadomo, że ma poważne błędy. W szczególności jest podatny na ataki ze znanym tekstem jawnym , 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 również używany przez 7-Zip i Xceed , ale niektórzy dostawcy używają innych formatów. PKWARE SecureZIP (SES, zastrzeżone) obsługuje również metody szyfrowania RC2, RC4, DES, Triple DES, szyfrowanie i uwierzytelnianie oparte na certyfikacie cyfrowym ( X.509 ) oraz szyfrowanie nagłówków archiwum. Jest jednak opatentowany (patrz § Silne kontrowersje dotyczące szyfrowania ).

Szyfrowanie nazw plików zostało wprowadzone w specyfikacji formatu pliku .ZIP 6.2, która szyfruje metadane przechowywane w części archiwum Central Directory, ale sekcje lokalnego nagłówka pozostają niezaszyfrowane. Zgodny archiwizator może fałszować dane lokalnego nagłówka podczas korzystania z szyfrowania centralnego katalogu. Od wersji 6.2 specyfikacji pola Metoda kompresji i Rozmiar skompresowany w nagłówku lokalnym nie są jeszcze maskowane.

ZIP64

Oryginalny format .ZIP miał limit 4 GB (2 32 bajty) na różne rzeczy (rozmiar pliku nieskompresowanego, rozmiar pliku skompresowanego i całkowity rozmiar archiwum), a także limit 65 535 (2 16 ) wpisy w archiwum ZIP. W wersji 4.5 specyfikacji (która nie jest taka sama jak v4.5 żadnego konkretnego narzędzia), PKWARE wprowadziło rozszerzenia formatu "ZIP64", aby ominąć te ograniczenia, zwiększając limity do 16  EB (2 64 bajty). Zasadniczo używa „normalnego” wpisu katalogu centralnego dla pliku, po którym następuje opcjonalny wpis katalogu „zip64”, który ma większe pola.

Format nagłówka pliku lokalnego (LOC) i wpisu katalogu centralnego (CEN) jest taki sam w ZIP i ZIP64. Jednak ZIP64 określa dodatkowe pole, które może zostać dodane do tych rekordów według uznania kompresora, którego celem jest przechowywanie wartości, które nie mieszczą się w klasycznych rekordach LOC lub CEN. Aby zasygnalizować, że rzeczywiste wartości są przechowywane w dodatkowych polach ZIP64, są one ustawiane na 0xFFFF lub 0xFFFFFFFF w odpowiednim rekordzie LOC lub CEN.

Dodatkowe pole informacji rozszerzonych Zip64
Zrównoważyć Bajty Opis
0 2 Identyfikator nagłówka 0x0001
2 2 Rozmiar dodatkowego kawałka pola (8, 16, 24 lub 28)
4 8 Oryginalny rozmiar nieskompresowanego pliku
12 8 Rozmiar skompresowanych danych
20 8 Przesunięcie lokalnego rekordu nagłówka
28 4 Numer dysku, na którym uruchamia się ten plik

Z drugiej strony format EOCD dla ZIP64 różni się nieco od normalnej wersji ZIP.

Zip64 Koniec rekordu katalogu centralnego (EOCD64)
Zrównoważyć Bajty Opis
0 4 Koniec podpisu w centralnym katalogu = 0x06064b50
4 8 Rozmiar EOCD64 - 12
12 2 Wersja wykonana przez
14 2 Wersja potrzebna do wyodrębnienia (minimum)
16 4 Numer tego dysku
20 4 Dysk, na którym zaczyna się katalog centralny
24 8 Liczba rekordów katalogu centralnego na tym dysku
32 8 Całkowita liczba rekordów w centralnym katalogu
40 8 Rozmiar katalogu centralnego (w bajtach)
48 8 Przesunięcie początku katalogu centralnego względem początku archiwum
56 n Komentarz (do rozmiaru EOCD64)

Niekoniecznie jest to również ostatni zapis w pliku. Następuje lokalizator końca centralnego katalogu (dodatkowe 20 bajtów na końcu).

Eksplorator plików w systemie Windows XP nie obsługuje ZIP64, ale Eksplorator w systemie Windows Vista i nowszych tak. Podobnie niektóre biblioteki rozszerzeń obsługują ZIP64, takie jak DotNetZip, QuaZIP i IO::Compress::Zip w Perlu. Python jest wbudowany w zipfile podpór to od 2,5 i domyślnie jej od 3.4. Wbudowany w OpenJDK java.util.zip obsługuje ZIP64 od wersji Java 7 . Android Java API obsługuje ZIP64 od Androida 6.0. Narzędzie Archive Utility systemu Mac OS Sierra w szczególności nie obsługuje ZIP64 i może tworzyć uszkodzone archiwa, gdy wymagany jest ZIP64. Jednak polecenie ditto dostarczane z systemem Mac OS rozpakuje pliki ZIP64. Nowsze wersje Mac OS są dostarczane z narzędziami wiersza poleceń info-zip zip i unzip, które obsługują Zip64: aby zweryfikować, uruchom zip -v i poszukaj „ZIP64_SUPPORT”.

Połączenie z innymi formatami plików

ZIP Format pliku pozwala na komentarzem zawierającym do 65535 (2 16 -1) bajtów danych, które występują na końcu pliku po katalogu centralnego. Ponadto, ponieważ katalog centralny określa przesunięcie każdego pliku w archiwum w odniesieniu do początku, możliwe jest, że pierwszy wpis pliku rozpocznie się z przesunięciem innym niż zero, chociaż niektóre narzędzia, na przykład gzip , nie przetwarzają archiwum pliki, które nie rozpoczynają się wpisem pliku o zerowym przesunięciu.

Dzięki temu w pliku mogą występować dowolne dane zarówno przed, jak i po danych archiwalnych ZIP, a archiwum może być nadal odczytywane przez aplikację ZIP. Efektem ubocznym jest to, że możliwe jest napisanie pliku, który jest zarówno działającym archiwum ZIP, jak i innym formatem, pod warunkiem, że ten format toleruje dowolne dane na końcu, początku lub środku. Archiwa samorozpakowujące (SFX) w formie obsługiwanej przez program WinZip korzystają z tego, ponieważ są to pliki wykonywalne ( .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 i formatu JAR, który jest wariantem ZIP, może zostać wykorzystana do ukrycia nieuczciwych treści (takich jak szkodliwe klasy Java) w pozornie nieszkodliwym pliku, takim jak obraz GIF przesłany do sieci. Ten tak zwany exploit GIFAR został zademonstrowany jako skuteczny atak na aplikacje internetowe, takie jak Facebook.

Limity

Minimalny rozmiar pliku ZIP to 22 bajty. Taki pusty plik zip zawiera tylko zapis końca centralnego katalogu (EOCD):
[0x50,0x4B,0x05,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]

Wielkość maksymalna zarówno archiwum i poszczególnych plików wewnątrz jest 4294967295 bajtów (2 32 -1 bajtów lub 4 PL minus jeden bajt) dla standardowego ZIP. W przypadku ZIP64 maksymalny rozmiar wynosi 18 446 744 073 709 551 615 bajtów (2 64 -1 bajtów lub 16 EB minus 1 bajt).

Zastrzeżone rozszerzenia

Dodatkowe pole

Format pliku .ZIP zawiera dodatkowe pole w nagłówkach plików, które można wykorzystać do przechowywania dodatkowych danych niezdefiniowanych przez istniejące specyfikacje ZIP i które umożliwiają zgodnym archiwizatorom, którzy nie rozpoznają pól, ich bezpieczne pominięcie. Identyfikatory nagłówka 0–31 są zarezerwowane do użytku przez PKWARE. Pozostałe identyfikatory mogą być używane przez dostawców zewnętrznych do użytku zastrzeżonego.

Silne kontrowersje dotyczące szyfrowania

Kiedy w 2003 roku wypuszczono publiczną wersję beta programu WinZip 9.0, WinZip wprowadził własne szyfrowanie AES-256 , wykorzystujące inny format plików, wraz z dokumentacją nowej specyfikacji. Same standardy szyfrowania nie były zastrzeżone , ale PKWARE nie aktualizowało APPNOTE.TXT o specyfikację silnego szyfrowania (SES) od 2001 r., 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 dyrektor ds. technologii PKZIP Jim Peterson twierdził, że szyfrowanie oparte na certyfikatach jest nadal niekompletne.

W kolejnym kontrowersyjnym posunięciu PKWare złożył wniosek patentowy w dniu 16 lipca 2003 r. opisujący metodę łączenia ZIP i silnego szyfrowania w celu utworzenia bezpiecznego pliku.

Ostatecznie PKWARE i WinZip zgodziły się wspierać swoje produkty. 21 stycznia 2004 r. PKWARE ogłosiło obsługę formatu kompresji AES opartego na WinZip. W nowszej wersji WinZip beta był w stanie obsługiwać pliki ZIP oparte na SES. PKWARE ostatecznie udostępniło publicznie wersję 5.2 specyfikacji formatu pliku .ZIP, która udokumentowała SES. Free Software projektu 7-Zip obsługuje AES, ale nie SES w plikach ZIP (podobnie jak jego POSIX portu p7zip ).

Podczas korzystania z szyfrowania AES w programie WinZip metoda kompresji jest zawsze ustawiona na 99, a rzeczywista metoda kompresji jest przechowywana w dodatkowym polu danych AES. Natomiast specyfikacja silnego szyfrowania przechowuje metodę kompresji w podstawowym segmencie nagłówka pliku lokalnego nagłówka i katalogu centralnego, chyba że do maskowania/szyfrowania metadanych jest używane szyfrowanie katalogu centralnego.

Realizacja

Dostępnych jest wiele narzędzi .ZIP i liczne biblioteki .ZIP dla różnych środowisk programistycznych; używane licencje obejmują oprogramowanie własnościowe i wolne . WinZip , WinRAR , Info-ZIP , 7-Zip , PeaZip i B1 Free Archiver to dobrze znane narzędzia .ZIP, dostępne na różnych platformach. Niektóre z tych narzędzi mają interfejsy biblioteczne lub programistyczne.

Niektóre biblioteki programistyczne licencjonowane w ramach umowy o otwartym kodzie źródłowym to libzip , libarchive i Info-ZIP . W przypadku Java: Java Platform, Standard Edition zawiera pakiet „java.util.zip” do obsługi standardowych plików .ZIP; biblioteka Zip64File obsługuje w szczególności duże pliki (większe niż 4 GB) i traktuje pliki .ZIP przy użyciu dostępu losowego; a narzędzie Apache Ant zawiera pełniejszą implementację wydaną na licencji Apache Software License .

Do Info-ZIP implementacje formacie ZIP dodaje wsparcie dla systemu plików Unix funkcji, takich jak identyfikatory użytkowników i grup, uprawnienia do plików, wsparcie dla linków symbolicznych. Apache Ant realizacja jest świadomy ich do tego stopnia, że może tworzyć pliki z predefiniowanymi uprawnieniami Unix. Implementacje Info-ZIP wiedzą również, jak korzystać z możliwości korekcji błędów wbudowanych w format kompresji .ZIP. Niektóre programy tego nie robią i zakończą się niepowodzeniem w przypadku pliku, który zawiera błędy.

Narzędzia Info-ZIP Windows obsługują również uprawnienia systemu plików NTFS i podczas wyodrębniania plików będą podejmować próbę tłumaczenia z uprawnień NTFS na uprawnienia Unix lub odwrotnie. Może to skutkować potencjalnie niezamierzonymi kombinacjami, np. tworzeniem plików .exe na woluminach NTFS z odmową uprawnień do wykonywania.

Wersje Microsoft Windows zawierają obsługę kompresji .ZIP w Eksploratorze od czasu Microsoft Plus! Pakiet został wydany dla systemu Windows 98. Microsoft nazywa tę funkcję „Folderami skompresowanymi”. Nie wszystkie funkcje .ZIP są obsługiwane przez funkcję Foldery skompresowane systemu Windows. Na przykład szyfrowanie nie jest obsługiwane w wersji Windows 10 Home, chociaż można je odszyfrować. Kodowanie wpisów Unicode nie jest obsługiwane aż do systemu Windows 7 , natomiast archiwa dzielone i łączone nie są odczytywane ani zapisywane przez funkcję Foldery skompresowane, a szyfrowanie AES nie jest obsługiwane.

Microsoft Office zaczął używać formatu archiwum zip w 2006 roku dla plików Office Open XML .docx, .xlsx, .pptx itp., który stał się domyślnym formatem plików w pakiecie Microsoft Office 2007 .

Spuścizna

Istnieje wiele innych standardów i formatów używających słowa „zip” jako części nazwy. Na przykład zip różni się od gzip , a ten ostatni jest zdefiniowany w IETF RFC  1952 . Zarówno zip, jak i gzip używają głównie algorytmu DEFLATE do kompresji. Podobnie format ZLIB (IETF RFC  1950 ) również używa algorytmu kompresji DEFLATE, ale określa różne nagłówki do sprawdzania błędów i spójności. Inne popularne, podobnie nazwane formaty i programy z różnymi formatami natywnymi to 7-Zip , bzip2 i rzip .

Obawy

Teoretyczny maksymalny współczynnik kompresji dla nieprzetworzonego strumienia DEFLATE wynosi około 1032 do jednego, ale wykorzystując format ZIP w niezamierzony sposób, można tworzyć archiwa ZIP o współczynnikach kompresji miliardów do jednego. Te bomby zip rozpinają się do bardzo dużych rozmiarów, przytłaczając pojemność komputera, na którym są dekompresowane.

Zobacz też

Bibliografia

Zewnętrzne linki

Specyfikacje formatu: