Convertir ZIP en TAR

Personne ne convertit vers TAR pour le stockage. On convertit parce que quelque chose en aval ne lit que les tarballs : un contexte de build de conteneur, un script de déploiement, un point d’import, un outil écrit en 1998 et toujours discrètement porteur. TAR date de 1979 et se standardise comme POSIX.1-2001 ustar, ce qui explique pourquoi tant d’infrastructures le supposent — à l’époque où la plupart de ces logiciels ont été écrits, un tarball était simplement ce qu’était une archive.

Cela fait de ceci une conversion de compatibilité au même sens que PDF est une conversion de compatibilité pour un document. Vous n’améliorez l’archive d’aucune façon mesurable ; vous changez les programmes qui l’accepteront, et vous payez pour cela en octets. Jugez le résultat à l’aune de l’outil en aval qui a cessé de se plaindre, et non de la taille du fichier qu’il a produit. Cela veut aussi dire que le tarball est en général jetable : une fois que le build l’a consommé ou que l’import a tourné, le ZIP dont vous partiez reste la copie qui vaut la peine d’être gardée, et le TAR peut s’en aller.

C’est la phrase que la plupart des pages sur cette paire omettent. Un ZIP applique DEFLATE à chaque entrée qu’il contient ; un TAR n’applique rien à rien. Convertir l’un en l’autre déballe donc la compression et ne la remplace pas, ce qui veut dire que la sortie est très souvent plusieurs fois la taille de l’entrée.

Pour du contenu riche en texte, le multiplicateur est le plus grand — code source, exports CSV, logs et XML se déflatent tous bien, donc défaire cela est coûteux et la croissance peut être plusieurs fois supérieure. Pour un ZIP plein de JPEG, MP4 ou PDF, la différence est faible, parce que ces contenus étaient déjà compressés avant d’être archivés et que le ZIP ne faisait pour ainsi dire rien. Cela vaut la peine de prédire dans quel cas vous êtes avant que le téléchargement ne vous surprenne, en particulier si le tarball doit voyager ensuite : une conversion qui quadruple un fichier est acceptable sur un disque local et coûteuse sur un réseau.

TAR est un flux de blocs fixes de 512 octets. Chaque membre reçoit un bloc d’en-tête portant son nom, sa taille, son mode et son horodatage, suivi de son contenu arrondi au multiple suivant de 512, et l’archive se termine par deux blocs de zéros. Il n’y a pas d’index, pas de table de compression et pas de répertoire central.

La conséquence apparaît sur les archives de nombreux petits fichiers. Cinq cents fichiers d’un kilooctet coûtent au moins un en-tête et deux blocs de contenu chacun, donc le remplissage seul est mesurable — une des raisons pour lesquelles un TAR d’une arborescence source a l’air curieusement grand à côté du ZIP dont il vient, indépendamment de la compression qui a été retirée.

TAR peut enregistrer un mode de fichier, un utilisateur et un groupe, ce qui est exactement la raison pour laquelle l’outillage Unix l’aime. Ce qu’il ne peut pas faire, c’est inventer ces valeurs. Elles viennent de ce que le déballage de votre ZIP a produit sur notre convertisseur, et non de la machine où les fichiers vivaient à l’origine.

Traitez donc les modes dans la sortie comme non spécifiés plutôt que conservés, et fixez-les explicitement après extraction si quoi que ce soit en dépend — un bit exécutable sur un script est la victime habituelle. Le registre énonce la forme générale de cela pour chaque paire d’archives : les membres ressortent octet pour octet, et ce que le conteneur portait *sur* eux est la partie à risque.

Une grande part de ceux qui cherchent cette paire ont en fait besoin d’un tarball compressé, parce que c’est ce que disait l’instruction qu’ils suivaient. Si la cible est un téléchargement, un artefact de version ou quoi que ce soit qui traverse un réseau, le TAR brut est la mauvaise moitié de la réponse.

Convertir plutôt le ZIP en GZ produit exactement cela. Toute cible ici qui ne peut pas contenir plus d’un fichier — GZ, BZ2 et XZ — est construite en faisant d’abord un TAR puis en le compressant, ce qui est ce que la convention `.tar.gz` a toujours signifié. Demandez TAR quand un outil veut un tarball ; demandez GZ quand un humain veut un téléchargement.

Le rempaquetage d’archives est l’une des conversions sur ce site qui ont besoin d’une vraie machine, donc le fichier voyage. Il part par une connexion chiffrée vers notre convertisseur, 7-Zip déballe le ZIP et écrit le TAR, le résultat revient, et le téléversement comme la sortie sont supprimés à la fin de la tâche. Le répertoire de travail vit en mémoire et est jeté avec le conteneur.

Les limites sont celles qui vont avec cet arrangement : 25 Mo par fichier au niveau gratuit, et un arrêt net à soixante secondes par tâche. Soixante secondes est généreux pour un rempaquetage de cette taille et existe parce qu’une archive délibérément malformée a tendance à faire tourner un compresseur plutôt qu’à échouer.

Deux refus valent la peine d’être connus à l’avance. Une archive qui déclare se déballer à plus de 2 Go est rejetée avant qu’un seul octet ne soit écrit sur disque, ce qui est le garde-fou contre un ZIP construit pour remplir un système de fichiers. Et un ZIP qui se révèle vide reçoit un message clair plutôt qu’un tarball vide.

Les ZIP chiffrés s’arrêtent aussi ici. Le déballeur reçoit un mot de passe vide délibérément pour qu’une archive protégée échoue immédiatement avec une erreur lisible au lieu d’attendre une invite qui ne sera jamais répondue. Retirez le mot de passe localement d’abord et convertissez l’archive en clair.

Le registre signale les fichiers volumineux comme un problème connu de TAR, et la raison est dans l’en-tête : le format ustar d’origine stocke la taille de fichier dans un champ octal de douze caractères, qui ne peut pas exprimer quoi que ce soit au-delà de 8 Gio, et stocke les noms dans un champ de 100 caractères avec un préfixe de 155 caractères. Les chemins longs et les membres énormes étaient les deux choses qui cassaient.

Les extensions modernes résolvent les deux, et les outils modernes les écrivent par défaut, donc la plupart des gens ne rencontrent jamais l’une ou l’autre limite. Au niveau gratuit ici, ni l’une ni l’autre n’est de toute façon atteignable — le plafond de 25 Mo sur l’entrée arrive bien avant que le format ne le fasse — mais c’est la raison pour laquelle vous trouverez encore sur internet des conseils sur le fait de découper des tarballs.

Pour la conservation à long terme, TAR a une propriété que les formats compressés n’ont pas : le dégât reste local. Une région corrompue dans un tarball non compressé vous coûte les fichiers de cette région, et tout ce qui suit peut encore être lu, parce que la structure n’est rien de plus que des en-têtes et du contenu en séquence, sans état partagé entre les membres. Un outil qui parcourt les blocs peut sauter le dégât et continuer, et même un éditeur de texte vous montrera quels fichiers étaient impliqués.

Une archive compressée est bien moins indulgente. Un mauvais octet tôt dans un flux solide peut coûter tout ce qui suit, parce que chaque référence ultérieure dépend d’une sortie antérieure correctement décodée. C’est l’argument honnête pour stocker un TAR brut à côté d’une copie compressée plutôt qu’à sa place — le fichier compressé pour le déplacement, le non compressé pour la survie — et c’est une raison complètement différente de vouloir cette conversion que la raison d’outillage avec laquelle la plupart des lecteurs arrivent.

ZIP traite empaquetage et compression comme une seule opération, ce qui est commode et vous retire silencieusement un choix : l’archive est déflatée parce que c’est ce que fait ZIP, au niveau qu’a choisi l’outil qui l’a écrite. Un TAR ne prend pas une telle décision. Il n’a pas de réglage de compression, pas de niveau, pas de dictionnaire et pas d’algorithme — il enregistre comment les fichiers s’appellent et met leurs octets en ordre, et s’arrête là.

Cette séparation est la raison pour laquelle l’outillage Unix compose aussi librement. Le même tarball peut être passé à gzip pour la vitesse, xz pour la taille ou rien du tout pour une étape intermédiaire, et le choix peut être fait par celui qui déplace plutôt que par celui qui a empaqueté. Si vous avez demandé un TAR parce qu’une étape ultérieure compresse ses propres artefacts, vous avez pris exactement cette décision à dessein, et la sortie non compressée est le résultat correct plutôt qu’un résultat décevant.