.A ZIP fájlok olyan archívumok, amelyek több fájlt tárolnak. A ZIP lehetővé teszi a tartalmazott fájlok tömörítését számos különböző módszerrel, valamint a fájl egyszerű tárolását tömörítés nélkül. Minden egyes fájl külön tárolódik, így az ugyanabban az archívumban lévő különböző fájlok különböző módszerekkel tömöríthetők. Mivel a ZIP-archívumban lévő fájlok külön-külön tömörítve vannak, lehetőség van a fájlok kivonására vagy újak hozzáadására anélkül, hogy a teljes archívumra tömörítést vagy dekompressziót kellene alkalmazni. Ez ellentétben áll a tömörített tar-fájlok formátumával, amelyek esetében az ilyen véletlenszerű hozzáférésű feldolgozás nem könnyen lehetséges.
A ZIP-fájl végén egy könyvtár található. Ez azonosítja, hogy milyen fájlok vannak a ZIP-ben, és azonosítja, hogy az adott fájl hol található a ZIP-ben. Ez lehetővé teszi a ZIP-olvasók számára a fájlok listájának betöltését a teljes ZIP-archívum beolvasása nélkül. A ZIP-archívumok olyan extra adatokat is tartalmazhatnak, amelyek nem kapcsolódnak a ZIP-archívumhoz. Ez lehetővé teszi, hogy egy ZIP-archívumot önkitömörítő archívummá (a benne lévő adatokat dekomprimáló alkalmazássá) alakítsanak, ha a programkódot a ZIP-archívum elé illesztik, és a fájlt futtathatónak jelölik. A katalógus végén történő tárolása lehetővé teszi a zippelt fájl elrejtését is egy ártalmatlan fájlhoz, például egy GIF képfájlhoz való csatolással.
A .ZIP formátum 32 bites CRC algoritmust használ, és az adatvesztés elleni nagyobb védelem érdekében az archívum könyvtárszerkezetének két példányát tartalmazza.
StructureEdit
A ZIP-fájlt helyesen azonosítja a központi könyvtár végi rekord jelenléte, amely az archívumszerkezet végén található, hogy az új fájlokat könnyen hozzá lehessen csatolni. Ha a központi könyvtár vége rekord nem üres archívumot jelez, akkor az archívumon belül minden egyes fájl vagy könyvtár nevét egy központi könyvtár bejegyzésben kell megadni, a bejegyzésre vonatkozó egyéb metaadatokkal és a ZIP-fájlban egy eltolással együtt, amely a tényleges belépési adatokra mutat. Ez lehetővé teszi az archívum fájllistázását viszonylag gyorsan, mivel a fájlok listájának megtekintéséhez nem kell az egész archívumot elolvasni. A ZIP-fájlon belüli bejegyzések is tartalmazzák ezt az információt, a redundancia érdekében, egy helyi fájlfejlécben. Mivel a ZIP-fájlokhoz lehet csatolni, csak a fájl végén lévő központi könyvtárban megadott fájlok érvényesek. Egy ZIP-fájl átvizsgálása a helyi fájlfejlécek után érvénytelen (kivéve a sérült archívumok esetében), mivel a központi könyvtár kijelentheti, hogy egyes fájlok törlésre, más fájlok pedig frissítésre kerültek.
Elkezhetünk például egy ZIP-fájlról, amely A, B és C fájlokat tartalmaz, majd B fájlt töröljük, C-t pedig frissítjük. Ezt úgy lehet elérni, hogy az eredeti ZIP-fájl végére egy új C fájlt csatolunk, és hozzáadunk egy új központi könyvtárat, amely csak az A fájlt és az új C fájlt tartalmazza. Amikor a ZIP-et először megtervezték, a fájlok átvitele floppylemezen volt elterjedt, a lemezekre való írás azonban nagyon időigényes volt. Ha egy nagy, esetleg több lemezre kiterjedő zip-fájlunk volt, és csak néhány fájlt kellett frissítenünk, az összes fájl beolvasása és újraírása helyett lényegesen gyorsabb lett volna csak beolvasni a régi központi könyvtárat, hozzáfűzni az új fájlokat, majd hozzáfűzni egy frissített központi könyvtárat.
A központi könyvtárban lévő fájlbejegyzések sorrendjének nem kell egyeznie az archívumban lévő fájlbejegyzések sorrendjével.
A ZIP-archívumban tárolt minden egyes bejegyzést egy helyi fájlfejléc vezet be, amely a fájlra vonatkozó információkat, például a megjegyzést, a fájlméretet és a fájlnevet tartalmazza, ezt követik az opcionális “extra” adatmezők, majd az esetleg tömörített, esetleg titkosított fájladatok. Az “extra” adatmezők jelentik a ZIP formátum bővíthetőségének kulcsát. Az “extra” mezőket a ZIP64 formátum, a WinZip-kompatibilis AES-titkosítás, a fájlattribútumok és a nagyobb felbontású NTFS vagy Unix fájl időbélyegek támogatására használják ki. Más kiterjesztések is lehetségesek az “Extra” mezőn keresztül. A ZIP-eszközöknek a specifikáció szerint figyelmen kívül kell hagyniuk az általuk nem ismert Extra mezőket.
A ZIP-formátum speciális 4 bájtos “aláírásokat” használ a fájl különböző struktúráinak jelölésére. Minden egyes fájlbejegyzést egy adott aláírás jelöl. A központi könyvtárrekord végét a sajátos aláírás jelzi, és a központi könyvtár minden egyes bejegyzése a 4 bájtos központi fájlfejléc aláírásával kezdődik.
A ZIP specifikációban nincs BOF vagy EOF jelölő. Hagyományosan a ZIP-fájlban az első dolog egy ZIP-bejegyzés, amely könnyen azonosítható a helyi fájlfejléc aláírása alapján. Ez azonban nem feltétlenül van így, mivel a ZIP specifikáció ezt nem követeli meg – leginkább az önkitömörítő archívum kezdődik egy futtatható fájl fejléccel.
A ZIP-archívumokat helyesen olvasó eszközöknek a központi könyvtárrekord végének aláírását kell keresniük, majd adott esetben a többi, jelzett központi könyvtárrekordot is. Nem szabad a ZIP-fájl tetején lévő bejegyzéseket keresniük, mivel (amint azt már korábban említettük ebben a szakaszban) csak a központi könyvtár adja meg, hogy hol kezdődik egy fájldarab, és hogy az nem lett törölve. A pásztázás hamis pozitív eredményekhez vezethet, mivel a formátum nem tiltja, hogy más adatok legyenek a chunkok között, és azt sem, hogy a fájl adatfolyamai ilyen aláírásokat tartalmazzanak. Azok az eszközök azonban, amelyek sérült ZIP-archívumokból próbálnak adatokat helyreállítani, nagy valószínűséggel a helyi fájlfejléc aláírásai után fogják vizsgálni az archívumot; ezt nehezíti, hogy a fájldarab tömörített mérete a fájldarab után tárolódhat, ami megnehezíti a szekvenciális feldolgozást.
A legtöbb aláírás a rövid egész számmal 0x4b50 végződik, amely little-endian sorrendben van tárolva. ASCII karakterláncként nézve ez “PK”, a feltaláló Phil Katz kezdőbetűi. Így amikor egy ZIP-fájlt egy szövegszerkesztővel nézünk meg, a fájl első két bájtja általában “PK”. (A DOS, OS/2 és Windows önkitömörítő ZIP-ek előtt EXE áll, tehát “MZ”-vel kezdődik; más operációs rendszerek önkitömörítő ZIP-jei előtt hasonlóan állhat az archívum tartalmának az adott platformon történő kicsomagolására szolgáló futtatható kód.)
A .ZIP specifikáció támogatja az archívumok több fájlrendszerfájlra történő szétterítését is. Eredetileg a nagy ZIP-fájlok több floppylemezen történő tárolására szánták, de ezt a funkciót ma már a ZIP-archívumok részekben történő elküldésére használják e-mailben, illetve más szállítóeszközökön vagy cserélhető adathordozókon.
A DOS FAT fájlrendszerének időbélyegfelbontása mindössze két másodperc; a ZIP-fájlrekordok ezt utánozzák. Ennek eredményeképpen a ZIP-archívumban lévő fájlok beépített időbélyegfelbontása csak két másodperc, bár a pontosabb időbélyegek tárolására további mezők is használhatók. A ZIP-formátum nem ismeri az időzóna fogalmát, így az időbélyegek csak akkor értelmezhetőek, ha ismert, hogy melyik időzónában készültek.
2007 szeptemberében a PKWARE kiadta a ZIP specifikáció felülvizsgálatát, amely lehetővé teszi a fájlnevek UTF-8 kódú tárolását, így a ZIP végre Unicode-kompatibilis lett.
FájlcímekSzerkesztés
A fejléc minden többbájtos értékét little-endian bájtsorrendben tárolja. Minden hosszmező a hosszúságot bájtban számolja.
Local file headerEdit
| Offset | Bytes | Description |
|---|---|---|
| 0 | 4 | Local file header signature = 0x04034b50 (olvasható little-endierként).endián szám) |
| 4 | 2 | A kivonatoláshoz szükséges verzió (minimum) |
| 6 | 2 | Általános célú bitjelző |
| 8 | 2 | Tömörítési módszer |
| 10 | 2 | A fájl utolsó módosításának ideje |
| 12 | 2 | A fájl utolsó módosításának dátuma |
| 14 | 4 | CRC-32 tömörítetlen adat |
| 18 | 4 | Tömörített méret (vagy 0xffffffffff ZIP64 esetén) |
| 22 | 4 | Tömörítetlen méret (vagy 0xffffffffff ZIP64 esetén) |
| 26 | 2 | Fájlnév hossza (n) |
| 28 | 2 | Extra mező hossza (m) |
| 30 | n | Fájlnév |
| 30+n | m | Extra mező |
Az extra mező különböző opcionális adatokat tartalmaz, mint például OS-specifikus attribútumok. Tömbökre van osztva, mindegyik 16 bites azonosító kóddal és 16 bites hosszal. A ZIP64 esetében mindig van legalább egy darab (0001-es azonosító kódú és 32 bájt méretű), lásd alább.
Ezt közvetlenül a tömörített adatok követik.
Data descriptorEdit
Ha az általános célú flags mező 3. eltolásánál (0x08) lévő bit be van állítva, akkor a CRC-32 és a fájlméretek nem ismertek a fejléc írásakor. A helyi fejléc mezői nullával töltődnek fel, a CRC-32 és a méret pedig egy 12 bájtos struktúrában (amelyet opcionálisan egy 4 bájtos aláírás előz meg) közvetlenül a tömörített adatok után kerül hozzáadásra:
| Offset | Byte | Megnevezés |
|---|---|---|
| 0 | 0/4 | Opcionális adatleíró aláírás = 0x08074b50 |
| 0/4 | 4 | CRC-32 tömörítetlen adat |
| 4/8 | 4 | Tömörített méret |
| 8/12 | 4 | Tömörítetlen size |
Központi könyvtárfájl fejlécEdit
A központi könyvtár bejegyzés a helyi fejléc kibővített formája:
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 4 | Central directory file header signature = 0x02014b50 | |
| 4 | 2 | Version made by | |
| 6 | 2 | Version needed to extract (minimum) | |
| 8 | 2 | Általános célú bit flag | |
| 10 | 2 | Tömörítési módszer | |
| 12 | 2 | A fájl utolsó módosításának ideje | |
| 14 | 2 | A fájl utolsó módosításának dátuma | |
| 16 | 4 | CRC-32 tömörítetlen adat | |
| 20 | 4 | Tömörített méret (vagy 0xffffffffff ZIP64 esetén) | |
| 24 | 4 | Tömörítetlen méret | |
| 4 | Nem tömörített méret (vagy 0xffffffffffff ZIP64 esetén) | ||
| 28 | 2 | Fájlnév hossza (n) | |
| 30 | 2 | Extra mező hossza (m) | |
| 32 | 2 | File comment length (k) | |
| 34 | 2 | Disk number where file starts | |
| 36 | 2 | 2 | Belső fájl attribútumok |
| 38 | 4 | Külső fájl attribútumok | |
| 42 | 4 | A helyi fájlfejléc relatív eltolása. Ez a bájtok száma az első lemez kezdete, amelyen a fájl szerepel, és a helyi fájlfejléc kezdete között. Ez lehetővé teszi a központi könyvtárat olvasó szoftverek számára, hogy megtalálják a fájl helyét a ZIP-fájlon belül. | |
| 46 | n | Fájlnév | |
| 46+n | m | Extramező | |
| 46+n+m | k | File comment |
Központi címtár rekord vége (EOCD)Edit
A központi címtár összes bejegyzése után következik a központi címtár rekord vége (EOCD), amely a ZIP-fájl végét jelzi:
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 4 | End of Központi könyvtár aláírása = 0x06054b50 | |
| 4 | 2 | A lemez száma | |
| 6 | 2 | Diszk, ahol a központi könyvtár található. kezdődik | |
| 8 | 2 | A központi könyvtár rekordjainak száma ezen a lemezen | |
| 10 | 2 | 2 | A központi könyvtár rekordjainak száma összesen. könyvtárrekordok száma |
| 12 | 4 | A központi könyvtár mérete (bájt) | |
| 16 | 4 | A központi könyvtár kezdetének eltolódása, az archívum elejéhez képest | |
| 20 | 2 | Comment hossza (n) | |
| 22 | n | Comment |
Ez a rendezés lehetővé teszi a ZIP fájl létrehozását egy menetben, de a központi könyvtár is a fájl végére kerül, hogy megkönnyítse a fájlok könnyű eltávolítását a több részből álló (e.
Tömörítési módszerekSzerkesztés
A .ZIP fájlformátum specifikáció a következő tömörítési módszereket dokumentálja: Store (nincs tömörítés), Shrink (LZW), Reduce (1-4. szint; LZ77 + valószínűségi), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, és az IBM z/OS CMPSC utasítás által biztosított LZ77 változat. A leggyakrabban használt tömörítési módszer a DEFLATE, amelyet az IETF RFC 1951 ír le.
A többi említett, de a specifikációban részletesen nem dokumentált módszer a következő: PKWARE DCL Implode (régi IBM TERSE), új IBM TERSE, IBM LZ77 z Architecture (PFS) és egy JPEG-változat. A “Tokenize” módszert egy harmadik fél számára tartották fenn, de a támogatást soha nem adták hozzá.
A PKWARE túlzásba viszi az Implode szót: a DCL/TERSE Implode különbözik a régi PKZIP Implode-tól, a Deflate elődjétől. A DCL Implode nem dokumentált, részben az IBM tulajdonjoga miatt, de Mark Adler ennek ellenére a zlib mellé egy “blast” nevű dekompresszort adott.
EncryptionEdit
AZIP támogat egy egyszerű jelszó alapú szimmetrikus titkosítási rendszert, amely általában ZipCrypto néven ismert. Ez dokumentálva van a ZIP specifikációban, és köztudottan súlyosan hibás. Különösen sebezhető az ismert nyílt szövegű támadásokkal szemben, amelyeket egyes esetekben a véletlenszám-generátorok rossz implementációja tovább ront.
A ZIP fájlformátum specifikációban az 5.2. verzió óta új funkciók, köztük új tömörítési és titkosítási (pl. AES) módszerek is dokumentálva vannak. A WinZip által kifejlesztett AES-alapú nyílt szabványt (“AE-x” az APPNOTE-ban) a 7-Zip és az Xceed is használja, de néhány gyártó más formátumokat használ. A PKWARE SecureZIP (SES, saját fejlesztésű) támogatja az RC2, RC4, DES, Triple DES titkosítási módszereket, a digitális tanúsítvány alapú titkosítást és hitelesítést (X.509), valamint az archívumfejlécek titkosítását is. Ez azonban szabadalmaztatott (lásd § Erős titkosítási vita).
A fájlnevek titkosítását a .ZIP File Format Specification 6.2 vezeti be, amely titkosítja az archívum központi könyvtárrészében tárolt metaadatokat, de a helyi fejlécrészek titkosítatlanok maradnak. Egy megfelelő archiváló meghamisíthatja a Local Header adatokat a Central Directory Encryption használata esetén. A specifikáció 6.2-es verziójától kezdve a Local Headerben a tömörítési módszer és a tömörített méret mezők még nem maszkoltak.
ZIP64Edit
Az eredeti .ZIP formátumban 4 GiB (232 bájt) volt a különböző dolgok (egy fájl tömörítetlen mérete, egy fájl tömörített mérete és az archívum teljes mérete), valamint egy ZIP-archívum 65 535 (216) bejegyzésének korlátja. A specifikáció 4.5-ös verziójában (ami nem azonos egy adott eszköz v4.5-ös verziójával) a PKWARE bevezette a “ZIP64” formátumbővítményeket, hogy megkerülje ezeket a korlátozásokat, és 16 EiB-ra (264 bájt) emelte a korlátokat. Lényegében egy “normál” központi könyvtárbejegyzést használ egy fájlhoz, amelyet egy opcionális “zip64” könyvtárbejegyzés követ, amely a nagyobb mezőkkel rendelkezik.
A helyi fájlfejléc és a központi könyvtárbejegyzés formátuma ugyanaz a ZIP és a ZIP64 esetében, de a méreteknél mindig 0xffffffffffff tárolt, és mindig van egy extra mező:
| Offset | Byte | Description |
|---|---|---|
| 0 | 2 | Header ID 0x0001 |
| 2 | 2 | Az extra meződarab mérete (16, 24 vagy 28) |
| 4 | 8 | Az eredeti tömörítetlen fájl mérete |
| 12 | 8 | A tömörített adat mérete |
| 20 | 8 | A helyi fejlécrekord eltolási értéke |
| 28 | 4 | A lemez száma, amelyen ez a fájl kezdődik |
A másik oldalon, a ZIP64 EOCD formátuma némileg eltér a normál ZIP verziótól (lásd a függelék 4. szakaszát.3.14).
| Offset | Byte | Description |
|---|---|---|
| 0 | 4 | End of central directory signature = 0x06064b50 |
| 4 | 8 | Size of the EOCD64 – 8 |
| 12 | 2 | Version made by |
| 14 | 2 | Version szükséges a kivonatoláshoz (minimum) |
| 16 | 4 | A lemez száma |
| 20 | 4 | A lemez, ahol a központi könyvtár kezdődik |
| 24 | 8 | A központi könyvtár rekordjainak száma ezen a lemezen |
| 32 | 8 | A központi könyvtár rekordjainak száma összesen |
| 40 | 8 | A központi könyvtár mérete (byte) |
| 48 | 8 | A központi könyvtár kezdetének eltolódása, az archívum elejéhez képest |
| 56 | n | Kommentár (az EOCD64 méretéig) |
Ez sem feltétlenül az utolsó rekord az állományban, egy opcionális End of Central Directory Locator következhet (további 20 bájt a végén).
A Windows XP-ben a Fájlkereső nem támogatja a ZIP64-et, a Windows Vista és újabb operációs rendszerek Fájlkeresője viszont igen. Hasonlóképpen, néhány kiterjesztő könyvtár támogatja a ZIP64-et, például a DotNetZip, a QuaZIP és az IO::Compress::Zip Perlben. A Python beépített zipfile-ja a 2.5 óta támogatja, a 3.4 óta pedig alapértelmezés szerint. Az OpenJDK beépített java.util.zip fájlja a Java 7-es verziójától támogatja a ZIP64-et. Az Android Java API az Android 6.0 óta támogatja a ZIP64-et. A Mac OS Sierra Archive Utility nevezetesen nem támogatja a ZIP64-et, és hibás archívumokat hozhat létre, amikor a ZIP64-re lenne szükség. A Mac OS-hez mellékelt ditto parancs azonban kicsomagolja a ZIP64 fájlokat. A Mac OS újabb verzióiban az info-zip zip és unzip parancssori eszközei támogatják a Zip64-et: az ellenőrzéshez futtassa a zip -v parancsot, és keresse a “ZIP64_SUPPORT”-t.
Kombináció más fájlformátumokkalSzerkesztés
A .ZIP fájlformátum lehetővé teszi, hogy a fájl végén a központi könyvtár után egy legfeljebb 65 535 (216-1) bájtnyi adatot tartalmazó megjegyzés szerepeljen. Továbbá, mivel a központi könyvtár megadja az archívum minden egyes fájljának a kezdethez viszonyított eltolását, lehetséges, hogy az első fájlbejegyzés a nullától eltérő eltolással kezdődjön, bár egyes eszközök, például a gzip, nem dolgozza fel azokat az archívumfájlokat, amelyek nem nullával kezdődnek.
Ez lehetővé teszi, hogy tetszőleges adatok szerepeljenek a fájlban a ZIP-archívum adatai előtt és után, és az archívumot egy ZIP-alkalmazás továbbra is be tudja olvasni. Ennek mellékhatása, hogy lehetséges olyan fájlt írni, amely egyszerre egy működő ZIP-archívum és egy másik formátum, feltéve, hogy a másik formátum tolerálja a tetszőleges adatokat a végén, elején vagy közepén. A WinZip által támogatott önkitömörítő archívumok (SFX) ezt kihasználják, mivel ezek futtatható (.exe) fájlok, amelyek megfelelnek a PKZIP AppNote.txt specifikációnak, és a megfelelő zip-eszközökkel vagy könyvtárakkal olvashatók.
A .ZIP formátumnak és a ZIP egyik változatának, a JAR formátumnak ezt a tulajdonságát ki lehet használni arra, hogy egy látszólag ártalmatlan fájlba, például egy webre feltöltött GIF-képbe rosszindulatú tartalmat (például káros Java-osztályokat) rejtsenek. Ez az úgynevezett GIFAR exploit hatékony támadásként mutatkozott be olyan webes alkalmazások ellen, mint például a Facebook.
LimitsEdit
A .ZIP fájl minimális mérete 22 bájt. Az ilyen üres zip-fájl csak egy EOCD (End of Central Directory Record) rekordot tartalmaz:
Az archívumfájl és a benne lévő egyes fájlok maximális mérete 4 294 967 295 bájt (232-1 bájt, azaz 4 GiB mínusz 1 bájt) a szabványos ZIP esetében. ZIP64 esetén a maximális méret 18,446,744,073,709,551,615 bájt (264-1 bájt, azaz 16 EiB mínusz 1 bájt).
Proprietary extensionsEdit
Extra fieldEdit
.A ZIP fájlformátum tartalmaz egy extra mező lehetőséget a fájlfejléceken belül, amely a meglévő ZIP specifikációk által nem definiált extra adatok tárolására használható, és amely lehetővé teszi a mezők biztonságos kihagyását a kompatibilis archiválók számára, amelyek nem ismerik a mezőket. A 0-31 fejlécazonosítók a PKWARE számára vannak fenntartva. A fennmaradó azonosítókat harmadik fél gyártók saját használatra használhatják.
Erős titkosítási vitaEdit
Amikor 2003-ban megjelent a WinZip 9.0 nyilvános béta verziója, a WinZip bevezette saját AES-256 titkosítását, amely egy másik fájlformátumot használt, az új specifikáció dokumentációjával együtt. Maguk a titkosítási szabványok nem voltak szabadalmaztatottak, de a PKWARE 2001 óta nem frissítette az APPNOTE.TXT-t, hogy tartalmazza az erős titkosítási specifikációt (SES), amelyet a PKZIP 5.0 és 6.0 verziója használt. Kevin Kearney, a WinZip technikai tanácsadója és Mathew Covington, a StuffIt termékmenedzsere azzal vádolta a PKWARE-t, hogy visszatartja a SES-t, de Jim Peterson, a PKZIP technológiai vezetője azt állította, hogy a tanúsítvány alapú titkosítás még mindig nem teljes.
Egy másik ellentmondásos lépésként a PKWare 2003. július 16-án szabadalmat jelentett be, amelyben leírta a ZIP és az erős titkosítás kombinációjának módszerét egy biztonságos fájl létrehozásához.
A PKWARE és a WinZip végül megegyezett, hogy támogatják egymás termékeit. 2004. január 21-én a PKWARE bejelentette a WinZip-alapú AES tömörítési formátum támogatását. A WinZip egy későbbi béta verziójában már képes volt támogatni a SES-alapú ZIP fájlokat. A PKWARE végül kiadta a nyilvánosság számára a .ZIP fájlformátum specifikáció 5.2-es verzióját, amely dokumentálta a SES-t. A szabad szoftveres 7-Zip projekt szintén támogatja az AES-t, de nem a SES-t a ZIP-fájlokban (ahogy a POSIX portja, a p7zip is).
A WinZip alatt az AES titkosítás használatakor a tömörítési módszer mindig 99-re van állítva, a tényleges tömörítési módszer pedig egy AES extra adatmezőben van tárolva. Ezzel szemben az Erős titkosítási specifikáció a tömörítési módszert a Helyi fejléc és a Központi könyvtár alapvető fájlfejléc szegmensében tárolja, kivéve, ha a Központi könyvtár titkosítása a metaadatok maszkolására/titkosítására szolgál.