ZIP ⇄ TAR.GZ omzetter

Twee archiefformaten die anders denken

ZIP en TAR.GZ lossen hetzelfde probleem op met tegengestelde filosofieën. Een ZIP comprimeert elk bestand afzonderlijk en houdt aan het einde een index bij, zodat je één enkel bestand eruit kunt halen zonder de rest aan te raken — handig, en de reden waarom ZIP het alledaagse formaat op Windows werd. Een tarball doet het andersom: tar plakt eerst elk bestand aan elkaar tot één lange stream, waarna gzip die stream in zijn geheel comprimeert. Alles samen comprimeren maakt het resultaat vaak kleiner als een archief veel kleine, gelijkaardige bestanden bevat, omdat patronen die bestanden delen dan één keer gecomprimeerd worden in plaats van per bestand — maar er kan niets uitgepakt worden zonder de stream vanaf het begin te lezen. Geen van beide is beter; ze zijn opgegroeid op verschillende systemen, en deze converter verplaatst je bestanden simpelweg tussen de twee werelden.

Wat de reis overleeft — en wat niet

Je mapstructuur en de inhoud van elk bestand komen byte voor byte over — de conversie pakt uit en weer in, hij hercodeert nooit wat er in de bestanden zit. Wat niet overleeft, is de metadata eromheen. Herverpakte items komen eruit met standaardrechten en zonder hun oorspronkelijke wijzigingsdatums, wat in één praktisch geval een verschil maakt: een shellscript dat naar een tarball wordt omgezet, verliest zijn uitvoerbaarheidsbit, dus op Linux heeft het na het uitpakken eerst een snelle chmod +x nodig voordat het draait. Erg lange paden verdienen ook een vermelding — de klassieke tar-header slaat ongeveer honderd tekens van een pad op, houd diep geneste mapnamen dus binnen de perken. Doen exacte rechten en datums er echt toe, zoals bij een systeem-back-up, maak de tarball dan op de machine zelf met het tar-commando; een formaatconversie is het verkeerde gereedschap voor die ene klus, en dat is beter om te zeggen dan om het pas ná een restore te ontdekken.

Wanneer je er echt de moeite voor zou doen

Het verkeer loopt beide kanten op. Richting tarball: een Linux-server, een CI-pipeline of een collega op de commandoregel verwacht een .tar.gz, en jij hebt een ZIP rechtstreeks van Windows. Richting ZIP: een opensource-release of een serverback-up komt binnen als .tar.gz en iemand moet hem met niets meer dan een dubbelklik op Windows openen. In beide gevallen is het alternatief een archiefprogramma installeren of een commandoregel opzoeken — deze pagina bestaat zodat een omweg van dertig seconden dat in plaats daarvan doet, zonder dat het archief je machine verlaat. Dat laatste is het stille voordeel van het in de browser doen: een broncode-dump, de bestanden van een klant of een map contracten raakt nooit iemands server aan, want er is helemaal geen server bij betrokken — de conversie zou zelfs werken met je internetverbinding losgekoppeld.

Grenzen die je moet kennen vóór een groot archief

Alles hier gebeurt in het geheugen van je browser, dus het praktische plafond hangt af van je apparaat — archieven van een paar honderd megabytes zijn meestal prima op een desktop, terwijl een tablet eerder afhaakt. Wachtwoordbeveiligde archieven worden in geen van beide richtingen ondersteund; verwijder eerst de beveiliging. En omdat de conversie echt opnieuw comprimeert, verschuift de uitvoergrootte een beetje in de ene of de andere richting — dat is normaal, geen dataverlies. Eén route om te onthouden: RAR-archieven kunnen nergens rechtstreeks omgezet worden naar een tarball, maar de RAR naar ZIP-tool zet een RAR eerst om naar ZIP-vorm, en van daaruit brengt deze pagina hem de rest van de weg.

Hoe het werkt

De volledige omzetting draait in je browser met de ingebouwde compressie-engine: het archief wordt uitgepakt, in het andere formaat opnieuw ingepakt en meteen aan jou teruggegeven. Er wordt niets naar een server gestuurd, dus zelfs grote of privé-archieven verlaten je toestel nooit.