ZIP naar TAR omzetten

Niemand converteert naar TAR voor opslag. Het gebeurt omdat iets verderop alleen tarballs leest: een containerbuildcontext, een implementatiescript, een importpunt, gereedschap uit 1998 dat nog steeds stilletjes onmisbaar is. TAR dateert uit 1979 en is gestandaardiseerd als POSIX.1-2001 ustar.

Dat maakt dit een compatibiliteitsomzetting, vergelijkbaar met hoe PDF dat is voor een document. Je verbetert het archief niet meetbaar; je verandert welke programma’s het accepteren, en betaalt daarvoor in bytes.

Een ZIP past DEFLATE toe op elk item dat het bevat; een TAR past niets toe op iets. Het ene omzetten naar het andere pakt de compressie dus uit zonder vervanging, wat betekent dat de uitvoer vaak meermaals de omvang van de invoer is.

Bij tekstrijke inhoud is de vermenigvuldiging het grootst — broncode, CSV-exports en logs comprimeren goed, dus dat ongedaan maken is duur. Bij een ZIP vol JPEG’s of MP4’s is het verschil klein, omdat die al gecomprimeerd waren voordat ze werden gearchiveerd.

TAR is een stroom van vaste blokken van 512 bytes. Elk lid krijgt één headerblok met naam, grootte, modus en tijdstempel, gevolgd door zijn inhoud afgerond op het volgende veelvoud van 512, en het archief eindigt met twee blokken nullen.

Het gevolg valt op bij archieven met veel kleine bestanden. Vijfhonderd bestanden van één kilobyte kosten elk minstens een header en twee inhoudsblokken, dus de opvulling alleen al is meetbaar.

TAR kan een bestandsmodus, gebruiker en groep vastleggen, en dat is precies waarom Unix-gereedschap er graag mee werkt. Wat het niet kan, is die waarden verzinnen — ze komen van wat het uitpakken van je ZIP op onze converter opleverde, niet van de machine waar de bestanden oorspronkelijk stonden.

Behandel de rechten in de uitvoer als ongespecificeerd in plaats van bewaard, en zet ze na het uitpakken expliciet als er iets van afhangt.

Een groot deel van de mensen die naar dit paar zoeken, heeft eigenlijk een gecomprimeerde tarball nodig. Is de bestemming een download of iets dat over een netwerk gaat, dan is de kale TAR de verkeerde helft van het antwoord.

De ZIP omzetten naar GZ levert precies dat op. Elk doel hier dat niet meer dan één bestand kan bevatten — GZ, BZ2 en XZ — wordt gemaakt door eerst een TAR te bouwen en die te comprimeren.

Archiefwerk is een van de omzettingen op deze site die een echte machine nodig heeft, dus het bestand reist. Het gaat over een versleutelde verbinding naar onze converter, 7-Zip pakt de ZIP uit en schrijft de TAR, en zowel de upload als de uitvoer worden verwijderd zodra de taak eindigt.

De limieten die daarbij horen: 25 megabyte per bestand op de gratis laag, en een harde stop na zestig seconden per taak.

Twee weigeringen zijn de moeite waard om vooraf te kennen. Een archief dat opgeeft meer dan 2 GB uit te pakken wordt geweigerd voordat er ook maar één byte wordt geschreven. En een ZIP die niets blijkt te bevatten, krijgt een duidelijke melding in plaats van een lege tarball.

Versleutelde ZIP-bestanden stoppen hier ook. De uitpakker krijgt bewust een leeg wachtwoord mee, zodat een beveiligd archief meteen faalt met een leesbare foutmelding. Verwijder het wachtwoord eerst lokaal.

Het originele ustar-formaat slaat een bestandsgrootte op in een octaal veld van twaalf tekens, wat niets voorbij 8 GiB kan uitdrukken, en namen in een veld van honderd tekens met een prefix van honderdvijfenvijftig.

Moderne uitbreidingen lossen beide op en moderne gereedschappen schrijven ze standaard, dus de meeste mensen komen geen van beide grenzen ooit tegen. Op de gratis laag hier is geen van beide bereikbaar — de limiet van 25 MB op de invoer komt lang eerder dan het formaat dat doet.

Voor langdurige bewaring heeft TAR één eigenschap die de gecomprimeerde formaten missen: schade blijft lokaal. Een beschadigd stuk in een ongecomprimeerde tarball kost je alleen de bestanden in dat stuk, en alles erna is nog leesbaar.

Een gecomprimeerd archief is veel minder vergevingsgezind: een verkeerde byte vroeg in een aaneengesloten stroom kan alles erna kosten. Dat is het eerlijke argument om een kale TAR naast een gecomprimeerde kopie te bewaren in plaats van in plaats daarvan.

ZIP behandelt verpakking en compressie als één bewerking. Een TAR neemt die beslissing niet: geen compressie-instelling, geen niveau, geen algoritme — hij legt vast hoe de bestanden heten en zet hun bytes op volgorde, en stopt daar.

Die scheiding is waarom Unix-gereedschap zo vrij samenwerkt. Dezelfde tarball kan door gzip voor snelheid, xz voor omvang, of niets voor een tussenstap. Vroeg je om een TAR omdat een latere fase zijn eigen artefacten comprimeert, dan heb je precies die keuze bewust gemaakt.