Convertir ZIP en XZ

Le temps de compression est payé par une machine, une fois. Le transfert est payé par tous ceux qui récupèrent le fichier, à chaque fois, et sur un forfait mesuré ou un CDN, il est payé en argent autant qu’en secondes. Cette asymétrie est tout l’argument en faveur de XZ, et c’est pourquoi le résumé du format dans notre registre le qualifie de standard pour les téléchargements de source et de paquets.

Cela vous dit aussi exactement quand ne pas vous en soucier. Une archive qu’un seul collègue ouvrira une fois n’a aucune économie à optimiser : les secondes passées à empaqueter sont les seules secondes impliquées dans toute la vie du fichier, et gzip aurait déjà fini. Tendez la main vers XZ quand le fichier a un public, un miroir, une facture CDN ou une longue durée de vie, et laissez-le tranquille quand le fichier a un seul destinataire. Le même raisonnement explique pourquoi les distributions ont déplacé leurs archives de paquets vers xz il y a des années et pourquoi personne ne se soucie de compresser un artefact de build qui vit onze minutes à l’intérieur d’un pipeline.

XZ est un compresseur plutôt qu’une archive. Le registre l’enregistre comme un format de flux à un membre et signale l’absence de toute structure de répertoire comme un problème connu — il n’y a nulle part dans un fichier `.xz` où un nom, un chemin ou un bit de permission puisse vivre.

Le contenu de votre ZIP est donc mis en page dans un TAR, qui porte tout cela, et XZ compresse le tarball comme un objet unique. Ce n’est pas un contournement inventé pour ce convertisseur ; c’est l’arrangement qu’utilise l’ensemble de l’écosystème Unix, et c’est pourquoi l’extension que vous voyez sur chaque version source est `.tar.xz` plutôt qu’un simple `.xz`. Cela signifie aussi que les deux couches font vraiment des travaux distincts, ce qui vaut la peine d’être retenu quand vous publiez : remplacer xz par un autre compresseur ensuite ne change rien au tar à l’intérieur, donc la structure de l’archive n’est pas une décision que vous verrouillez aujourd’hui.

Le chiffre est l’histoire. DEFLATE, qu’utilisent ZIP et gzip, code une répétition comme une référence à quelque chose dans les 32 derniers Ko. LZMA2 dans XZ peut référencer quelque chose jusqu’à 64 Mo en arrière — deux mille fois la distance — et code ces références avec un codeur de plage qui coûte moins de bits que les codes Huffman de DEFLATE.

Là où cela se voit, c’est toute archive dont la répétition est étalée : une arborescence source où le même en-tête de licence ouvre deux cents fichiers, un jeu de données d’exports CSV similaires, un dossier de documents bâtis à partir d’un même modèle. Là où cela se voit le moins, c’est un ZIP de photographies ou de vidéo, parce que le contenu a été compressé avant d’être archivé et qu’il ne reste rien à trouver pour une fenêtre plus longue.

Un grand dictionnaire n’est pas gratuit à l’autre bout. Le décompresseur doit garder cette fenêtre en mémoire pour résoudre les références qui s’y trouvent, donc la mémoire nécessaire pour déballer suit à peu près le dictionnaire avec lequel le fichier a été empaqueté plutôt que la taille du fichier lui-même.

Sur n’importe quel bureau ou serveur, c’est sans conséquence. Cela cesse d’être sans conséquence sur du petit matériel — un routeur, une carte de classe microcontrôleur, un agent de build contraint — qui est le seul endroit où la modeste fenêtre de 32 Ko de gzip est un avantage plutôt qu’une limitation. Si vous savez que votre archive est destinée à quelque chose de petit, c’est une raison de publier un `.tar.gz` à côté.

Ils partagent une famille de compression et le registre donne aux deux un dictionnaire pouvant atteindre 64 Mo, donc sur le taux il y a peu de différence. La différence est ce qui entoure les données compressées. 7Z est un conteneur avec son propre répertoire d’entrées, son propre chiffrement et ses propres sommes de contrôle. XZ est un compresseur enroulé autour d’un flux unique.

Pour la diffusion, le flux l’emporte par convention : chaque boîte Linux et macOS a `tar` et `xz`, et presque aucune n’a 7-Zip installé par défaut. Pour une archive que vous gardez et parcourez plutôt que vous publiez, 7Z est la meilleure forme parce que vous pouvez lister et extraire un fichier sans déballer deux couches. Même compression, ergonomies opposées.

Les deux formats se vérifient eux-mêmes. Un ZIP stocke un CRC par entrée, donc un membre endommagé est détecté au moment de l’extraction. XZ porte une vérification sur son flux compressé — CRC-32, CRC-64 ou SHA-256 selon la façon dont il a été écrit — et refuse de vous remettre des données qui ne correspondent pas.

Ce qui change, c’est la granularité. Dans un ZIP, la vérification est par fichier, donc une mauvaise entrée est un mauvais fichier. Dans un `.xz`, la vérification couvre le flux, donc un dégât est signalé pour l’archive entière et le tar à l’intérieur peut être irrécupérable au-delà du dégât. Pour tout ce que vous publiez, un fichier de somme de contrôle externe à côté du téléchargement vaut les deux lignes qu’il prend.

Un flux gzip peut enregistrer le nom de fichier d’origine ; un flux XZ n’enregistre rien de tel. C’est de la compression avec un en-tête décrivant la vérification et les filtres, et aucune place pour un nom ou un horodatage.

Cela met toute la charge de décrire le fichier sur ce que vous l’appelez. Les téléchargements ici prennent votre radical d’origine plus l’extension cible, donc `release-1.4.zip` revient en `release-1.4.xz` ; le renommer en `release-1.4.tar.xz` avant de publier est la différence entre un téléchargement que les gens reconnaissent et un qu’il faut sonder. C’est la seule chose véritablement utile que vous puissiez faire au fichier après l’avoir converti.

La conversion tourne sur notre convertisseur plutôt que dans votre navigateur, donc le ZIP est téléversé par une connexion chiffrée, déballé avec 7-Zip, taré, compressé avec xz et renvoyé. Le téléversement, les intermédiaires et la sortie sont supprimés à la fin de la tâche ; l’espace de travail est sauvegardé en mémoire et s’en va avec le conteneur qui l’a utilisé.

Les conséquences sont les 25 Mo par fichier du niveau gratuit, un plafond de soixante secondes par tâche, un refus pour toute archive déclarant plus de 2 Go de contenu déballé, et un échec propre plutôt qu’un blocage sur un ZIP protégé par mot de passe. Si l’archive est véritablement sensible, xz-utils et 7-Zip font cela hors ligne sur votre propre machine.

Les projets qui réussissent cela livrent deux fichiers. Le `.tar.xz` est pour les personnes qui le déballeront dans un shell ou un script, où le téléchargement plus petit est de la bande passante réelle et où l’outillage est installé depuis que le système d’exploitation l’a été. Le ZIP reste pour toute personne sous Windows qui veut le double-cliquer, regarder à l’intérieur et ne jamais penser aux algorithmes de compression. Les deux sont faits à partir de la même arborescence et aucun n’est un compromis.

Ce n’est pas de l’indécision ; ce sont deux publics avec des contraintes réellement différentes, et un seul fichier ne peut pas servir les deux sans pénaliser l’un d’eux. Si vous ne livrez jamais qu’un seul artefact, livrez celui que vos téléchargeurs réels peuvent ouvrir — une archive magnifiquement compressée que personne ne peut déballer est un ticket d’assistance avec un excellent taux, et les octets que vous avez économisés sont remboursés bien des fois dans des messages demandant ce qu’est un `.tar.xz`.

Si le ZIP fait partie d’un build censé être reproductible, sachez que le rempaquetage n’est pas une opération neutre. Les octets des membres sont conservés exactement, mais l’archive autour d’eux est écrite à neuf : l’ordre des entrées, les horodatages et les choix du compresseur viennent tous de la machine qui empaquette plutôt que de l’archive que vous avez téléversée. Deux conversions du même ZIP peuvent donc différer l’une de l’autre tout en étant toutes deux entièrement correctes.

Cela n’a d’importance que si quelque chose en aval somme de contrôle l’archive plutôt que son contenu. Les pipelines de version qui publient un hash à côté du téléchargement devraient générer ce hash à partir du fichier qu’ils livrent réellement, calculé après le rempaquetage final, et jamais repris d’un artefact antérieur. Si une sortie octet-identique entre exécutions est une exigence, cela appartient à une chaîne d’outils locale et épinglée où les réglages de compression sont les vôtres à fixer, et pas à un convertisseur web.