Convertir TAR en ZIP

Les archives TAR qui ne sont pas compressées sont presque toujours une sortie de machine. `docker save` en écrit une. Les outils de sauvegarde et les panneaux d’hébergement en écrivent comme intermédiaire. Les jeux de données sont déversés en TAR parce que la chaîne qui les a produits allait les compresser ensuite et ne l’a pas fait. Les systèmes de build les produisent comme artefact à passer à l’étape suivante.

Cela compte parce que cela indique à quoi s’attendre à l’intérieur : beaucoup de fichiers, des noms générés par machine, des chemins profonds, et aucune pensée donnée à l’archive en tant que chose qu’une personne ouvrira un jour. Cette conversion est en général le moment où la sortie d’une machine devient le fichier d’une personne, ce qui est un travail vraiment différent de réempaqueter une archive que quelqu’un a assemblée exprès.

La plupart des conversions d’archive ici échangent un compresseur contre un autre et la taille bouge un peu dans un sens ou dans l’autre. Celle-ci part de rien. La compression du TAR, dans notre registre, est enregistrée comme aucune — il écrit des en-têtes et des contenus de fichiers en séquence et ne touche jamais un seul octet de leur contenu.

Donc un ZIP du même contenu est compressé là où le TAR ne l’était pas, et sur la matière que les archives TAR portent habituellement — fichiers sources, JSON, journaux, configuration, couches de conteneur pleines de texte — la différence est grande plutôt que marginale. C’est la conversion rare où le gain de compatibilité et le gain de taille pointent dans la même direction, ce qui est pourquoi elle n’a besoin d’aucun argument pour ou contre : il n’y a pas de compromis à faire ici au-delà de la perte des métadonnées Unix décrites plus bas.

TAR est un flux de blocs fixes de 512 octets et rien d’autre. Chaque membre coûte un bloc d’en-tête portant son nom, sa taille, son mode et son horodatage, plus son contenu complété jusqu’au prochain multiple de 512, et l’archive entière se termine par deux blocs de zéros. Il n’y a pas d’index et pas de répertoire central nulle part dans le fichier.

Sur une archive de quelques gros fichiers, ce surcoût est invisible. Sur une archive qui en contient des milliers de petits — un `node_modules`, un checkout, un répertoire de minuscules documents JSON — le remplissage seul peut représenter une fraction sérieuse du fichier. Un ZIP a aussi un surcoût par entrée, mais il est de quelques dizaines d’octets plutôt que d’un arrondi à un demi-kilooctet, et les entrées sont en plus compressées.

ZIP écrit un répertoire central à la fin listant chaque entrée et où elle commence. Un programme peut donc lire le contenu d’une grande archive sans en décompresser aucune partie, et extraire un seul fichier du milieu sans toucher aux autres. C’est ce qui fait qu’un ZIP se comporte comme un dossier dans l’Explorateur Windows.

Un TAR n’a aucun index du tout, donc le lister signifie le lire depuis le début, et extraire un fichier du milieu signifie marcher devant tout ce qui le précède. Cette conception est une conséquence de l’âge et de la finalité du format — il a été écrit en 1979 pour des dérouleurs de bande, où la recherche en arrière n’était pas de mise — et c’est pourquoi tout outil qui parcourt des archives est plus à son aise avec un ZIP.

Un TAR stocke un mode, un utilisateur et un groupe pour chaque membre, et c’est pour cela que les flux de déploiement et d’empaquetage s’en servent. ZIP n’a aucun endroit pour rien de tout cela que les outils de bureau honorent, donc cela ne passe pas la conversion.

La règle générale sur les paires d’archive ici est que les membres sortent octet pour octet et que ce que le conteneur savait d’eux est ce qui est en jeu — un mot de passe, et sur certains formats les permissions et les horodatages. Pour un TAR c’est la partie à laquelle penser, parce qu’un TAR issu d’un build ou d’un export de conteneur est bien plus susceptible de dépendre d’un bit exécutable qu’un ZIP fait sur un bureau.

Le gain de taille décrit plus haut n’est pas automatique. Si l’archive contient des photographies, de la vidéo, des PDF ou des fichiers qui ont eux-mêmes été compressés avant d’être archivés, DEFLATE n’a presque rien à trouver et le ZIP arrive près du TAR moins son remplissage.

Cela vaut la peine d’être vérifié avant de supposer que la conversion résoudra un problème de transfert. Un TAR de 25 Mo de JPEG ne deviendra pas un ZIP de 6 Mo, et aucun compresseur sur ce site ou ailleurs n’y arrivera ; les octets ont été dépensés quand les photographies ont été encodées. Ce que vous obtenez toujours, c’est un fichier unique que toute machine peut ouvrir, ce qui est très souvent la vraie raison de convertir en premier lieu.

Cette paire tourne sur notre convertisseur plutôt que dans le navigateur. Le TAR est téléversé par une connexion chiffrée, extrait avec 7-Zip dans un répertoire de travail, réempaqueté en ZIP depuis l’intérieur de ce répertoire, puis renvoyé ; le téléversement et tous les intermédiaires sont supprimés à la fin du travail.

L’espace de travail est un système de fichiers borné adossé à de la mémoire, jeté avec le conteneur qui a exécuté le travail. Les limites sont 25 Mo par téléversement sur la version gratuite et un plafond strict de soixante secondes par travail, avec un refus net pour toute archive déclarant qu’elle se déballe en plus de 2 Go. Un TAR est non compressé, donc cette déclaration est rarement loin de la taille du fichier lui-même.

Si la destination est une machine Linux plutôt qu’un bureau, convertir en ZIP résout un problème que vous n’avez pas. Le geste idiomatique est de garder le TAR et de le compresser — convertir l’archive en GZ produit le `.tar.gz` que tout outil Unix déballe d’une seule commande, et conserve les modes et la propriété que le TAR portait.

Choisissez ZIP quand une personne sous Windows ou macOS doit ouvrir le fichier, ou quand un formulaire de téléversement l’exige. Choisissez une archive TAR compressée quand le fichier retourne dans de l’outillage. La différence n’est pas une affaire de goût technique ; c’est qui est à l’autre bout.

Le ZIP gagne une vérification que le TAR n’avait pas. Le champ `chksum` de TAR couvre le bloc d’en-tête et rien d’autre, donc un membre corrompu s’extrait en silence avec les mauvais octets dedans ; ZIP stocke un CRC-32 par entrée et signale la mauvaise par son nom. Chaque membre est copié sans être réencodé — un conteneur sans perte n’a rien à réencoder au départ. Le nombre d’entrées et les chemins dans le ZIP doivent correspondre exactement à ceux de l’archive TAR, et n’importe quel archiveur les liste sans rien extraire, ce qui fait de la comparaison un travail de trente secondes.

La seule chose qui mérite un coup d’œil délibéré est le niveau supérieur. Un TAR écrit depuis un répertoire parent porte un dossier de tête dans chaque chemin, et un écrit depuis l’intérieur ne le fait pas, et le ZIP reproduit fidèlement celui qu’il a trouvé. Si vos fichiers sortent un niveau plus profond que prévu, c’est la disposition du TAR d’origine qui transparaît plutôt que quelque chose que la conversion a introduit — et cela vaut la peine d’être su avant qu’un script qui hard-code le chemin ne s’exécute dessus.

Un TAR produit par `docker save` est un bon exemple d’une archive qui n’est pas vraiment un dossier. Il contient des blobs de couches, un manifest et des métadonnées JSON dont les noms sont de longues chaînes hexadécimales, et rien de tout cela n’est censé être lu par une personne. Le convertir en ZIP marche parfaitement et vous donne exactement cette structure, compressée, dans un fichier que votre machine ouvrira.

Ce qu’il ne vous donne pas, c’est l’image. Reconstruire une image exige de re-nourrir le TAR dans un runtime de conteneur, qui attend le TAR et pas un ZIP, donc une copie convertie sert à inspecter ou à faire suivre l’artefact, et non à le restaurer. La même prudence s’applique aux outils de sauvegarde qui écrivent des archives TAR avec leurs propres fichiers d’index à l’intérieur : l’archive se convertit proprement, et la question de savoir si l’outil qui l’a faite acceptera la version convertie en est une autre qui mérite d’être vérifiée avant que vous ne jetiez l’originale.