Tar Vs Zip Vs Gz: verschil en efficiëntie

Tijdens het downloaden van bestanden is het niet ongebruikelijk om de .tar-, .zip- of .gz- extensies te zien. Maar weet u het verschil tussen Tar en Zip en Gz? Waarom we ze gebruiken en welke is efficiënter, tar of zip of gz?

Het verschil tussen tar, zip en gz

Als je gehaast bent of gewoon iets gemakkelijk wilt onthouden, hier is het verschil tussen zip en tar en gz:

.tar == ongecomprimeerd archiefbestand

.zip == (meestal) gecomprimeerd archiefbestand

.gz == bestand (archief of niet) gecomprimeerd met gzip

Een beetje geschiedenis van archiefbestanden

Zoals zoveel dingen over Unix & Unix-achtige systemen, begint het verhaal lang geleden, in een niet zo verre melkweg genaamd de jaren zeventig. In een koude ochtend van januari 1979 verscheen het tar- hulpprogramma als onderdeel van de nieuw uitgebrachte Unix V7.

Het tar- hulpprogramma is ontworpen als een manier om efficiënt veel bestanden op banden te schrijven. Zelfs als tapedrives tegenwoordig voor de overgrote meerderheid van individuele Linux-gebruikers onbekend zijn, worden tarballs - de bijnaam van tar- archieven - nog steeds vaak gebruikt om verschillende bestanden of zelfs hele mappenboom (of zelfs forests) in één bestand te verpakken.

Een belangrijk ding om te onthouden is dat een gewoon tar- bestand slechts een archief is waarvan de gegevens niet zijn gecomprimeerd. Met andere woorden, als u 100 bestanden van 50 kB tarreert, krijgt u een archief met een grootte van ongeveer 5000 kB. De enige winst die u kunt verwachten als u alleen tar gebruikt, is door de verspilling van het bestandssysteem te vermijden, omdat de meeste van hen ruimte op een bepaalde granulariteit toewijzen (bijvoorbeeld op mijn systeem gebruikt een één byte lang bestand 4 KB schijfruimte, 1000 van ze gebruiken 4MB maar het bijbehorende tar-archief "slechts" 1MB).

Het is de moeite waard om hier te vermelden dat tar zeker niet de enige standaard Unix-tool is om archieven te maken. Programmeurs kennen waarschijnlijk ar zoals het tegenwoordig meestal wordt gebruikt om statische bibliotheken te maken, die niet meer zijn dan archieven van gecompileerde bestanden. Maar ar kan worden gebruikt om archieven van welke aard dan ook te maken. In feite zijn .deb- pakketbestanden die op Debian-systemen worden gebruikt archieven! En op MacOS X zijn mpkg- pakketten cpio- archieven die met gzip zijn gecomprimeerd (waren?). Dat gezegd hebbende, noch ar noch cpio wonnen evenveel populariteit als teer bij gebruikers. Misschien omdat het tar-commando goed genoeg en eenvoudiger te gebruiken was.

Niet het soort teer waarnaar je op zoek bent

Het maken van archieven is leuk. Maar met het verstrijken van de tijd en met de komst van het tijdperk van de personal computer, beseften mensen dat ze enorme besparingen konden realiseren op opslag door gegevens te comprimeren . Dus een decennium na de introductie of tar, zip kwam uit in de MS-DOS-wereld als een archiefformaat dat compressie ondersteunt . Het meest voorkomende compressieschema voor zip is deflate, wat zelf een implementatie is van het LZ77-algoritme. Maar commercieel ontwikkeld door PKWARE, heeft het zi p- formaat jarenlang last gehad van patentbezwaren.

Dus parallel hiermee is gzip gemaakt om het LZ77-algoritme in een gratis software te implementeren zonder PKWARE-patent te breken.

Een belangrijk element van de Unix-filosofie is "Doe het een ding en doe het goed", gzip is ontworpen om alleen bestanden te comprimeren. Dus om een gecomprimeerd archief te maken, moet u eerst een archief maken met behulp van het tar- hulpprogramma bijvoorbeeld. En daarna comprimeer je dat archief. Dit is een .tar.gz- bestand (soms afgekort als .tgz om opnieuw toe te voegen aan die verwarring - en om te voldoen aan de lang vergeten 8.3 MS-DOS bestandsnaambeperkingen).

Naarmate de informatica evolueerde, werden andere compressie-algoritmen ontworpen voor een hogere compressieverhouding. Het algoritme Burrows-Wheeler geïmplementeerd in bzip2 (leidend tot .tar.bz2- archieven). Of recenter xz, een LZMA- algoritme-implementatie vergelijkbaar met die gebruikt in het 7zip- hulpprogramma.

Beschikbaarheid en beperkingen

Vandaag kunt u vrijelijk elke archiefbestandsindeling gebruiken op zowel Linux als Windows.

Maar aangezien het zip- formaat native wordt ondersteund op Windows, is dit vooral aanwezig in platformonafhankelijke omgevingen. U kunt het zip- bestandsformaat zelfs vinden op onverwachte plaatsen. Het bestandsformaat is bijvoorbeeld bewaard door Sun voor JAR- archieven die worden gebruikt om gecompileerde Java-toepassingen te distribueren. Of voor OpenDocument-bestanden ( .odf, .odp ...) die worden gebruikt door LibreOffice of andere kantoorsuites. Al die bestandsformaten zijn zip-archieven in een vermomming. Als je nieuwsgierig bent, aarzel dan niet om een ​​van hen uit te pakken om te zien wat erin zit:

 sh $ unzip some-file.odt Archive: some-file.odt extraheren: mimetype opblazen: meta.xml opblazen: settings.xml opblazen: content.xm [...] oppompen: styles.xml opblazen: META-INF / manifest .xml 

Dat gezegd hebbende, zou ik in de Unix-achtige wereld nog steeds het tar- archieftype prefereren omdat het zip- bestandsformaat niet alle metadata van het Unix-bestandssysteem betrouwbaar ondersteunt. Voor enkele concrete verklaringen van die laatste verklaring, moet u weten dat het ZIP-bestandsformaat alleen een kleine set verplichte bestandskenmerken definieert om voor elk item op te slaan: bestandsnaam, wijzigingsdatum, permissies. Naast deze basisattributen kan een archiver extra metadata opslaan in het zogenaamde extra veld van de ZIP-header. Maar omdat extra velden door de implementatie worden gedefinieerd, zijn er geen garanties, zelfs niet voor compatibele archivarissen om dezelfde set metagegevens op te slaan of op te halen. Laten we dat controleren in een voorbeeldarchief:

 sh $ ls -lsn data / team total 0 0 -rw-r - r-- 1 1000 2000 0 30 jan 12:29 team sh $ zip -0r archive.zip data / 
 sh $ zipinfo -v archive.zip data / team Centrale directory-invoer # 5: --------------------------- data / team [.. .] schijnbaar bestandstype: binaire Unix-bestandskenmerken (100644 octaal): -rw-r - r-- MS-DOS bestandskenmerken (00 hex): geen Het extra veld van de centrale directory bevat: - Een subveld met ID 0x5455 ( universele tijd) en 5 databytes. Het lokale extra veld heeft UTC / GMT-modificatie / toegangstijden. - Een subveld met ID 0x7875 (Unix UID / GID (elke grootte)) en 11 databytes: 01 04 e8 03 00 00 04 d0 07 00 00. 

Zoals je ziet, maken de eigendomsinformatie (UID / GID) deel uit van het extra veld - het is misschien niet vanzelfsprekend als je hexadecimaal niet kent, noch dat ZIP-metadata little-endian zijn opgeslagen, maar voor korte "e803" is "03e8" met is "1000", het bestand UID. En "07d0" is "d007" wat 2000 is, het bestand GID.

In dat specifieke geval heeft de Info-ZIP zip- tool die beschikbaar is op mijn Debian-systeem enkele nuttige metadata opgeslagen in het extra veld. Maar er is geen garantie dat dit extra veld door elke archiver wordt geschreven. En zelfs als dit aanwezig is, is er geen garantie dat dit wordt begrepen door de tool die wordt gebruikt om het archief uit te pakken.

Terwijl we traditie niet kunnen afwijzen als een motivatie om nog steeds tarballs te gebruiken, begrijp je in dit kleine voorbeeld waarom er nog enkele (hoek?) Gevallen zijn waarin tar niet kan worden vervangen door zip . Dit geldt vooral als u alle standaard bestandsmetadata wilt behouden.

Tar vs Zip vs Gz Efficiency Test

Ik zal hier spreken over ruimte-efficiëntie, niet over tijdefficiëntie - maar als vuistregel, meer potentieel efficiënt is een compressie-algoritme, meer CPU vereist dit.

En om u een idee te geven van de compressieverhouding die is verkregen met verschillende algoritmen, heb ik op mijn harde schijf ongeveer 100 MB aan bestanden verzameld uit populaire bestandsindelingen. Hier zijn de resultaten behaald op mijn Debian Stretch-systeem (alle maten zoals gerapporteerd door du -sh ):

bestandstype.jpg.mp3.mp4.odt.png.tekst
aantal bestanden216345279299020724397
ruimte op schijf98m99M99M98m98m98m
teer94M99M98m93M92M89M
zip (geen compressie)92M99M98m91m91m86m
zip (laat leeglopen)87m98m93M85M77M28M
tar + gzip86m98m93M82M77M27M
tar + bz287m98m93M42M71M22M
tar + xz70M98m22M348K51M19M

Ten eerste moedig ik je aan om die resultaten met een enorme korrel zout te nemen: de databestanden waren eigenlijk bestanden die rondliepen op mijn harde schijf, en ik zou niet beweren dat ze op enigerlei wijze representatief waren. Dan moet ik bekennen dat ik die bestandstypes niet willekeurig heb gekozen. Ik heb het al gezegd, .odt- bestanden zijn al zip-bestanden. Dus de bescheiden winst die wordt behaald door ze een tweede keer te comprimeren, is niet verrassend (behalve voor bzip2 of xy, maar ik beschouw dat als een statistische afwijking veroorzaakt door de lage heterogeniteit van mijn gegevensbestanden - die verschillende back-ups of werkversies van dezelfde bevatten documenten).

Betreffende .jpg, .mp3 en .mp4 nu: misschien weet u dat het al gecomprimeerde databestanden zijn. Nog beter, je hebt misschien gehoord dat ze destructieve compressie gebruiken . Dat betekent dat je na een JPEG-compressie niet exact het originele beeld kunt reconstrueren. En dat is waar. Maar wat weinig bekend is, is na de destructieve compressiefase op zich, de gegevens worden een tweede keer gecomprimeerd met behulp van het niet-destructieve variabele algoritme Huffman-woordlengte om gegevensredundantie te verwijderen.

Om al deze redenen werd verwacht dat het comprimeren van JPEG-afbeeldingen of MP3 / MP4-bestanden geen grote winst oplevert. Let op: een typisch bestand bevat zowel de sterk gecomprimeerde gegevens als een aantal niet-gecomprimeerde metadata, we kunnen daar nog steeds een klein beetje winnen. Dit verklaart waarom ik nog steeds een merkbare winst voor JPEG-afbeeldingen heb, aangezien ik er veel van had - dus de algehele metadata was niet zo verwaarloosbaar in vergelijking met de totale bestandsgrootte. Nogmaals, de verrassende resultaten bij het comprimeren van MP4-bestanden met xz zijn waarschijnlijk gerelateerd aan de grote overeenkomsten tussen de verschillende MP4-bestanden die tijdens mijn tests werden gebruikt. Of zijn ze dat niet?

Om die twijfels uiteindelijk op te heffen, moedig ik je sterk aan om je eigen vergelijkingen te maken. En aarzel niet om uw observaties met ons te delen via de commentaarsectie hieronder!

Aanbevolen

Hoe software te installeren en te verwijderen in Ubuntu
2019
Cinnamon 3.0 vrijgegeven
2019
Hoe Google Drive te gebruiken in Linux
2019