Convertir TAR en GZ

Les TAR non compressés sont plus rares que les gzippés et ils surgissent à des endroits reconnaissables. `docker save` en écrit un. Les scripts de sauvegarde à qui on a dit d’empaqueter mais pas de compresser en écrivent un. Certaines chaînes de NAS et de bande en produisent un parce que la compression se passe ailleurs. Et des gens en écrivent un par accident, parce que `tar cf` et `tar czf` ne diffèrent que d’un caractère et qu’un seul des deux rend le fichier plus petit.

Le résultat est une archive qui fait à peu près la somme de tout ce qu’elle contient plus une quantité surprenante de surcoût. C’est très bien sur un disque local et coûteux partout ailleurs : sur un envoi sur une connexion lente, sur un bucket facturé au gigaoctet-mois, dans une limite de pièce jointe, dans un cache de CI qui est relu à chaque build. Cette conversion est le seul rempaquetage de ce site où la réponse est presque toujours oui, parce qu’il n’y a pas de coût de compatibilité — `.tar.gz` est plus universellement compris qu’un `.tar` seul.

La structure du TAR date de 1979 et elle est charmante de simplicité : un en-tête de 512 octets décrivant un fichier, puis le fichier lui-même complété jusqu’à la prochaine limite de 512 octets, puis l’en-tête suivant, et deux blocs de zéros à la fin pour marquer la fin. Rien n’est compressé et rien n’est indexé. Le format a été conçu pour des lecteurs de bande, où les blocs de taille fixe étaient l’intérêt.

Le coût de cela apparaît sur les petits fichiers. Un fichier d’un octet occupe 1 024 octets dans un TAR — un bloc d’en-tête complet et un bloc de données complet. Dix mille fichiers de configuration, fichiers source ou documents JSON qui font en moyenne quelques centaines d’octets portent plusieurs mégaoctets d’en-têtes et de remplissage qui ne contiennent aucune information. Gzip est extrêmement bon exactement sur ce cas : les longues suites d’octets zéro se compriment en presque rien, donc une bonne part du gain sur une archive de petits fichiers vient de la suppression du surcoût plutôt que de la compression du contenu.

Gzip utilise DEFLATE avec une fenêtre d’historique de 32 Ko, et c’est le nombre qui décide de tout dans cette conversion. Dans toute fenêtre de 32 Ko il trouve les chaînes répétées et les remplace par des références, puis code ce qui reste en Huffman. Sur de la prose, du code, des logs, du XML, du JSON et de la configuration, c’est un gain important et fiable.

Ce qu’il manque, c’est la répétition à longue distance. Si le même en-tête de licence apparaît dans deux cents fichiers répartis dans un tarball de 40 Mo, gzip le compresse deux cents fois séparément parce qu’il n’en voit jamais deux à la fois. C’est l’écart que XZ et 7Z existent pour fermer, et c’est pourquoi ils battent gzip de beaucoup sur les archives composées de nombreux fichiers similaires. La réponse de gzip, c’est qu’il est rapide, qu’il streame, et qu’il est installé absolument partout — ce qui pour un fichier qu’on déplace plutôt qu’on archive est d’ordinaire le meilleur compromis.

Cela mérite d’être dit franchement parce que cela surprend ceux qui s’attendent à ce qu’un emballage soit appliqué autour de leur fichier existant. La conversion déballe le TAR que vous avez téléversé, puis écrit un nouveau TAR à partir du contenu extrait et le compresse avec gzip. Les fichiers à l’intérieur sont identiques au bit près ; le tarball autour est neuf.

Deux conséquences en découlent. D’abord, une somme de contrôle publiée pour le TAR d’origine ne correspondra à rien ici, parce que vous ne détenez plus le TAR d’origine — si une empreinte doit vérifier, compressez le fichier avec `gzip` sur votre propre machine à la place, ce qui laisse le tarball intact. Ensuite, ce que l’ancien conteneur a enregistré sur ses membres peut changer : la note du registre pour cette paire le dit textuellement, et les permissions et horodatages sont les champs en danger. Pour un paquet source ou une archive documentaire, c’est sans importance, et pour un artefact de déploiement, ce n’est pas le cas.

Un flux gzip a un champ d’en-tête pour le nom de fichier d’origine, ce qui explique que `gunzip backup.gz` sur une machine Unix produise un fichier appelé `backup.tar` alors que rien dans la commande ne le disait. C’est une petite courtoisie que le format accorde, et c’est la raison pour laquelle un fichier gzippé est légèrement moins anonyme qu’un xz ou un bzip2, qui ne stockent aucun nom.

Ne comptez pas dessus pour quoi que ce soit d’important. Beaucoup d’outils écrivent un nom générique dans ce champ, beaucoup d’autres l’ignorent à l’extraction, et un fichier qui passe par un système qui réécrit les archives le perd entièrement. L’extension que vous donnez au téléchargement est l’étiquette qui sera réellement lue, donc faites-la se terminer en `.tar.gz` plutôt qu’en `.gz` et épargnez à la personne à l’autre bout d’avoir à déballer un mystère.

Un flux gzip se décode d’avant en arrière avec une fenêtre fixe de 32 Ko et sans index, ce qui ressemble à une limitation et qui est la source de son plus grand avantage. Cela veut dire que l’archive peut se consommer au fur et à mesure qu’elle arrive : `curl https://… | tar xzf -` déballe un téléchargement qui n’atteint jamais le disque, une sauvegarde peut être envoyée directement dans gzip puis vers un hôte distant, et un expéditeur de logs peut compresser à la volée sans savoir combien de données arrivent.

Le registre le signale sur le format lui-même, et c’est la raison pour laquelle gzip n’a pas été remplacé par quelque chose de plus fort en vingt ans d’efforts. Les formats qui ont un grand dictionnaire ont besoin d’une mémoire proportionnelle ; les formats avec un répertoire central ont besoin de la fin du fichier avant de pouvoir lister le début. Si votre tarball va être passé en flux, servi par HTTP, ou déballé par quelque chose de petit, gzip n’est pas le choix par compromis, c’est le bon choix.

Les trois ne se classent pas ; ils se placent à différents points de la même courbe. Gzip est le plus rapide à compresser et à décompresser et donne le plus petit gain. XZ donne de beaucoup le plus grand gain sur du texte, au prix d’un temps de compression important et de la mémoire nécessaire pour le déballer. BZ2 se place entre les deux sur le ratio, est lent à décompresser, et le registre le marque comme héritage.

Choisissez en fonction de ce qui arrive au fichier ensuite. Quelque chose qui sera récupéré et déballé à répétition, par des machines que vous ne contrôlez pas, à travers un tuyau — gzip. Quelque chose qui restera en stockage froid pendant des années et sera lu presque jamais — XZ. Quelque chose qui doit correspondre à un nom d artefact qu’un système de build attend déjà — celui que ce nom indique, et pas de raisonnement requis. Convertir un tarball coûte assez peu pour que tester les deux et comparer les tailles soit une manière légitime de décider.

Pas dans votre navigateur. La plupart des outils ici tournent sur votre propre appareil et le disent ; le rempaquetage d’archive est l’une des exceptions, parce qu’il demande 7-Zip et gzip en tant que vrais programmes. Le fichier voyage par une connexion chiffrée vers un conteneur qui les exécute et qui n’a pas d’accès internet sortant propre.

Chaque travail obtient un répertoire de travail sur un système de fichiers en mémoire qui est supprimé à la fin du travail quel que soit le résultat, et tout ce qui tourne encore après soixante secondes est tué plutôt que laissé à moudre. Le quota gratuit accepte 25 Mo par fichier téléversé, et c’est sur cette paire que cette limite mord le plus fort — un TAR est non compressé, donc 25 Mo de TAR représentent 25 Mo de contenu réel, là où 25 Mo de 7Z pourraient en représenter dix fois plus.

`tar xzf archive.tar.gz` gère les deux couches en une seule passe sur macOS, Linux et les BSD, et Windows moderne fournit un `tar` qui fait la même chose depuis PowerShell ou l’invite de commandes. Les archiveurs graphiques sur Windows déballent en général la couche gzip et vous laissent un `.tar` à ouvrir à nouveau, ce qui est le comportement qui envoie les gens chercher un format à conteneur unique à la place.

Avant que l’original ne parte, comparez le listing : `tar tzf` sur le résultat contre `tar tf` sur la source, même nombre et mêmes chemins. Le niveau racine est ce qu’il faut regarder, parce qu’une archive packée depuis l’intérieur d’un répertoire et une packée depuis son parent diffèrent par un dossier initial sur chaque entrée, et un script qui attendait l’une et a reçu l’autre échoue des mois plus tard pour des raisons dont personne ne se souvient. Une fois que les deux listings concordent, le TAR non compressé n’a plus de raison d’être.