KÜLÖNBSÉGEK A TAR, ZIP ÉS GZ KÖZÖTT
Ha sietsz vagy csak szeretnél valami könnyen megjegyezhetőt, akkor itt vannak a különbségek a zip, tar és gz között
.tar == tömörítetlen archívum fájl
.zip == (általában) tömörített archívum fájl
.gz == gzip használatával tömörített fájl (archívum vagy sem)
TAR vs ZIP vs GZ
Különbség és teljesítmény összehasonlítás
Különbség és teljesítmény összehasonlítás
EGY KICSIT AZ ARCHÍVUM FÁJLOK TÖRTÉNELMÉRŐL
Mint a legtöbb Unixszal és Unix-szerű operációs rendszerrel kapcsolatos dolog, a történet réges régen kezdődött, egy nem túl távoli hetvenes éveknek hívott galaxisban. 1979-ben egy hideg januári reggelen a tar segédprogram feltűnt az újonnan megjelent Unix V7 részeként.
A tar segédprogramot sok fájl hatékony szalagra írásának egy módjaként tervezték. Még ha napjainkban a szalagmeghajtók ismeretlenek is az egyéni Linux felhasználók hatalmas többségének, a tarballok - a tar archívumok beceneve - még mindig általánosan használtak sok fájl vagy akár egy egész könyvtárfa (vagy akár erdők) egyetlen fájlba történő becsomagolására.
Egy kulcsfontosságú észben tartandó dolog, hogy egy sima tar fájl csak egy archívum, aminek az adata nincs tömörítve. Más szavakkal, ha becsomagolsz 100 50 kB-os fájlt egy tarba, akkor egy 5000 kB körüli archívumot kapsz. Az egyetlen haszon, amit a tar használatától várhatsz, egyedül a fájlrendszer okozta tárhelyveszteség elkerülése, mivel a legtöbb némileg tagoltan foglal le helyet (például az én rendszeremen egy egy bájt hosszúságú fájl 4 kB helyet foglal, 1000 ilyen pedig 4 MB-ot, amíg a megfelelő tar archívum "csak" 1 MB-ot).
Itt érdemes megemlíteni, hogy a tar természetesen nem az egyetlen szabványos Unix eszköz archívumok létrehozására. Programozók valószínűleg ismerik az ar-t, mivel ezt használják legtöbbször statikus eljáráskönyvtárak létrehozására. ami nem több, mint fordított fájlok archívuma. De az ar használható bármilyen archívum létrehozására. Valójában a Debian rendszereken használt .deb csomagfájlok ar archívumok! És a MacOS X-en lévő mpkg csomagok gzippel tömörített cpio archívumok. Ettől függetlenül sem az ar, sem a cpio nem ért el olyan népszerűséget, mint a tar a felhasználók között. Talán azért, mert a tar parancs elég jó volt és könnyen használható.
Nem az a fajta tar, amit te keresel
Az archívumok létrehozása jó. De ahogy telt az idő és a személyi számítógépek korának eljövetelével az emberek észrevették, hogy óriási tártelületet megtakaríthatnak az adatok tömörítésével. Így a tar bemutatkozása után egy évtizeddel kijött a zip az MS-DOS világába, egy tömörítést támogató archíváló formátumként. A legáltalánosabb tömörítési séma a ziphez a csökkentés, ami maga az LZ77 algoritmus implementációja. De a PKWARE általi fejlesztéstől a zip formátum szabadalmi megterhelésektől szenvedett évekig.
Így ezzel párhuzamosan létrehozták a gzipet, hogy egy szabad szoftverbe implementálják az LZ77 algoritmust, bármilyen PKWARE szabadalom megsértése nélkül.
Egy kulcseleme az Unix filozófiának, hogy "egy dolgot csinálj és csináld jól", a gzipet csak fájlok tömörítésére tervezték. Így ahhoz, hogy tömörített archívumot csinálj, először létre kell hoznod egy archívumot a tar segédprogrammal például és utána tömöríted az archívumot. Ez egy .tar.gz fájl (időnként .tgz-nek rövidítik, hogy bővítsék a zűrzavart - és, hogy megfeleljenek a rég elfeledett 8.3 MS-DOS-os fájlnév korlátozásoknak.
Ahogy a számítógép tudomány fejlődött, egyéb tömörítési algoritmusokat hoztak létre jobb tömörítési arány érdekében. Például a Burrows–Wheeler algoritmust a bzip2-ben implementálták (.tar.bz2 archívumokhoz vezetett). Vagy újabban az xz, ami egy LZMA algoritmus implementáció, hasonló a 7zip segédprogramban használthoz.
ELÉRHETŐSÉG ÉS KORLÁTOK
Ma szabadon használhatsz bármilyen archív fájl formátumot Linuxon és Windowson egyaránt. De ahogy a zip formátum natívan támogatott Windowson, ez különösen jelen van kereszt-platformos környezetekben. Váratlan helyeken találkozhatsz a zip fájlformátummal. Például a Sun-nál Jar archívumokhoz van megtartva a fájlformátum, ami lefordított Java alkalmazások közzétételére használatos. Vagy a LibreOffice vagy egyéb irodai programcsomagok által használt OpenDocument fájlok (.odf, .odp). Mindezen fájlformátumok zip archívumok álcázva. Ha kíváncsi vagy, ne habozz kinyitni egyet, hogy lásd, mi van belül:
sh$ unzip some-file.odt Archive:some-file.odt extracting: mimetype inflating: meta.xml inflating: settings.xml inflating: content.xm [...] inflating: styles.xml inflating: META-INF/manifest.xml
Mindezek ellenére az Unix-szerű világban még mindig a tar arcíhívum típust részesítik előnyben, mert a zip fájlformátum nem támogat minden Unix fájlrendszer metaadatot megbízhatóan. Az utóbbi állítás bizonyos konkrét magyarázataihoz tudnod kell, hogy a ZIP fájlformátum csak egy kis részét adja meg a kötelező fájl attribútumoknak minden bejegyzés tárolásához: fájlnév, módosítás dátuma, jogosultságok. Ezeken az alapvető attribútumokon túl egy archívum csomagolónak tárolnia kell további metaadatokat a ZIP fejléc úgynevezett extra mezőjében. De ahogy az extra mezők implementáció meghatározottak, nincs garancia még a megfelelő archívumhoz ugyanazon metaadat halmaz tárolására és visszanyerésére sem. Ellenőrizzük ezt egy minta archívumon:
sh$ ls -lsn data/team total 0 0 -rw-r--r-- 1 1000 2000 0 Jan 30 12:29 team sh$ zip -0r archive.zip data/
sh$ zipinfo -v archive.zip data/team Central directory entry #5: --------------------------- data/team [...] apparent file type: binary Unix file attributes (100644 octal): -rw-r--r-- MS-DOS file attributes (00 hex): none The central-directory extra field contains: - A subfield with ID 0x5455 (universal time) and 5 data bytes. The local extra field has UTC/GMT modification/access times. - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes: 01 04 e8 03 00 00 04 d0 07 00 00.
Ahogy láthatod, a tulajdonjogi információ (UID/GID) az extra mező része — Talán nem egyértelmű, ha nem ismered a hexadecimálist, sem a ZIP metaadatot, ami little endian-ban van tárolva, de az "e803" rövidítve "03e8", amivel "1000" a fájl UID. És a "07d0" "d007", ami 2000, a fájl GID.
Ebben az adott esetben az Info-Zip eszköz elérhető a Debian rendszeremen, némi hasznos metaadatot tárolva az extra mezőben. De nincs garancia arra, hogy ezt az extra mezőt minden archiváló írja. És ha mégis, nincs garancia arra, hogy az archívum kibontására használt eszköz megérti.
Ellenben nem tagadhatjuk meg a hagyományt, a tarballok további használatának motivációjaként, ezzel a kis példával megértetted, hogy miért vannak még mindig olyan (ritka?) esetek, ahol a tar nem kiváltható zippel. Ez különösen igaz, ha meg szeretnéd tartani az összes szabványos fájl metaadatot.
TAR VS ZIP VS GZ HATÉKONYSÁG TESZT
Tárhelybeli hatékonyságról fogok beszélni, nem időbeli hatékonyságról, de ökölszabály, hogy minél hatékonyabb egy tömörítő algoritmus, annál több CPU-t igényel.
Valamint, hogy legyen fogalmad a különböző tömörítési algoritmusok által elérhető tömörítési arányról, összegyűjtöttem a merevlemezemen körülülbelül 100 MB-ot a népszerűbb fájlformátumokból. Itt vannak a Debian Strech rendszeremen elért eredmények (minden méret a du -sh-val lett kijelezve)
| fájltípus | .jpg | .mp3 | .mp4 | .odt | .png | .txt |
| fájlok száma | 2163 | 45 | 279 | 2990 | 2072 | 4397 |
| hely a lemezen | 98M | 99M | 99M | 98M | 98M | 98M |
| tar | 94M | 99M | 98M | 93M | 92M | 89M |
| zip (nincs tömörítés) | 92M | 99M | 98M | 91M | 91M | 86M |
| zip (csökkentés) | 87M | 98M | 93M | 85M | 77M | 28M |
| tar + gzip | 86M | 98M | 93M | 82M | 77M | 27M |
| tar + bz2 | 87M | 98M | 93M | 42M | 71M | 22M |
| tar + xz | 70M | 98M | 22M | 348K | 51M | 19M |
Becsült tárhely nyereség .jpg, .mp3 és .txt fájlokon
Arra bíztatlak, hogy ezeket az eredményeket erős fenntartásokkal kezeld. Az adatfájlok tulajdonképpen a merevlemezemen lévő fájlok voltak és nem tartom őket reprezentatívnak semmilyen módon. Aztán be kell vallanom, hogy nem véletlenszerűen választottam ki ezeket a fájlokat. Korábban már említettem, hogy az .odf fájlok eleve .zip fájlok. Így a tömörítéssel elért szerény nyereség nem meglepő (kivéve a bzip2 és az xz esetében, de ezeket az adatfájljaim alacsony különbözősége által okozott statisztikai rendellenességnek tartom - számos biztonsági mentés alkalmazása vagy ugyanazon dokumentumok verzióival történő munka.
Most a .jpg, .mp3 és .mp4-et illetően: Talán tudod, hogy ezek eleve tömörített adatfájlok. Még jobb, talán hallottad, hogy ezek veszteséges tömörítést használnak. Ez azt jelenti, hogy nem állíthatod vissza pontosan az eredeti képet egy JPEG tömörítés után. És ez igaz. De ami kevésbé ismert a veszteséges tömörítés fogalma után, az az, hogy az adat másodjára veszteségmentes Huffman változó szóhosszúságú algoritmussal kerül tömörítésre az adatredundancia eltávolítása érdekében.
Mindezen okok miatt várható, hogy JPEG képek vagy MP3/MP4 fájlok tömörítése nem vezet nagy nyereséghez. Kérlek vedd figyelembe, hogy egy tipikus fájl tartalmaz magasan tömörített adatot és némi tömörítetlen metaadatot is egyaránt, ezzel nyerhetünk egy kicsit itt. Ez megmagyarázza, hogy miért van észrevehető nyereségem JPEG képeknél, miután sok van belőle - így az összesített metaadat méret nem annyira elhanyagolható a teljes fájlmérethez viszonyítva. Még egyszer, az MP4 fájlok xz-vel történő tömörítésénél tapasztalt meglepő eredmények valószínűleg a különféle tesztjeim során használt MP4 fájlok nagy hasonlóságával kapcsolatosak. Vagy nem?
Hogy véglegesen eloszlassuk ezeket a kétségeket, erősen bíztatlak, hogy csináld meg a saját összehasonlításaidat. És ne habozz megosztani velünk az észrevételeidet a lenti hozzászólás részleggel!
Felhasznált forrás: Tar Vs Zip Vs Gz: Difference and Efficiency
Nincsenek megjegyzések:
Megjegyzés küldése