Convertir XZ en ZIP

XZ est simplement ce que l’amont publie. Les versions source, les paquets de distribution, les arborescences du noyau et des chaînes d’outillage entières sont massivement livrées en `.tar.xz`, parce que le fichier est téléchargé des milliers de fois et construit une fois, et que chaque mégaoctet économisé est un mégaoctet économisé de manière répétée. Le résumé du registre qualifie xz de standard pour les téléchargements de source et de paquets.

Cette convention a été formée par et pour des personnes qui ont un shell, où `tar -xJf` déballe les deux couches en une commande, où rien n’a besoin d’être installé et où la question ne se pose jamais. Hors de ce chemin, c’est inutile : Windows affiche un type de fichier inconnu, macOS n’offre rien d’utile, et le téléchargement reste dans un dossier en étant quatre mégaoctets de quelque chose. Le format a été choisi par des gens qui ne rencontreront jamais ce problème, pour de bonnes raisons qui ne vous incluent pas, et c’est pourquoi la conversion existe plutôt qu’une discussion sur la question de savoir si l’amont aurait dû publier un ZIP.

XZ compresse un flux unique et rien d’autre. Dans notre registre, c’est un format de flux à un seul membre, et l’absence de toute structure de répertoire est listée parmi ses problèmes connus — un fichier `.xz` n’a aucun champ pour un nom, un chemin ou un bit de permission.

Les noms vivent dans le TAR en dessous : un bloc d’en-tête pour chaque fichier, son contenu en séquence, pas de compression propre et pas d’index. XZ n’apprend jamais que les octets qu’il compresse décrivent des fichiers. Retrouver votre répertoire exige donc d’annuler deux choses distinctes, et ne faire que la première vous laisse tenir un `.tar` qui n’est pas plus ouvrable sous Windows que le fichier de départ. Ce deuxième fichier est là où la plupart des gens concluent que quelque chose a mal tourné, et c’est aussi là que la conversion sur cette page diffère d’un outil qui se contente d’ôter l’emballage extérieur.

LZMA2 code une répétition comme une référence à quelque chose jusqu’à 64 Mo en amont, et il le fait avec un codeur arithmétique qui dépense moins de bits que les codes Huffman de DEFLATE. Face à la fenêtre de 32 Ko de ZIP, c’est environ deux mille fois plus de portée.

Sur une arborescence source, l’effet est spectaculaire, parce que la répétition est partout et qu’elle est étalée : le même en-tête de licence ouvrant deux cents fichiers, les mêmes lignes d’import, le même boilerplate généré, la même indentation. C’est pourquoi la version d’un projet est souvent une petite fraction de ce qu’elle déballe, et pourquoi le ZIP qui revient de cette page aura l’air étonnamment grand à côté du fichier que vous avez téléversé. Aucun des deux chiffres n’a tort — ce sont deux mesures honnêtes du même contenu sous des compresseurs qui sont à deux décennies et trois ordres de grandeur l’un de l’autre.

Avant que quoi que ce soit ne soit extrait, l’archive est interrogée sur ce qu’elle prétend contenir, et un total déclaré au-dessus de 2 Go est refusé avec un message simple. Sur la plupart des paires d’archives, ce garde-fou existe pour des fichiers délibérément malveillants et ne se déclenche jamais sur un fichier réel.

Cette paire est l’exception. Un compresseur puissant appliqué à une grande arborescence peut mettre bien plus de 2 Go de contenu dans un fichier assez petit pour être téléversé confortablement, donc une archive source ordinaire et tout à fait honnête peut se voir refusée. C’est une limite délibérée plutôt qu’une défaillance : le convertisseur a un répertoire de travail borné et sauvegardé en mémoire, et un budget de soixante secondes, et une archive de cette taille appartient à un outil local plutôt qu’à un service web.

Beaucoup, en termes relatifs. ZIP compresse chaque entrée indépendamment contre une fenêtre de 32 Ko et écrit un répertoire d’elles, donc il ne peut pas voir par-dessus les frontières des fichiers, et encore moins 64 Mo en arrière. Tout ce que le long dictionnaire trouvait est payé à nouveau.

Pour un lecteur qui veut regarder à l’intérieur d’une version, c’est un échange correct — le ZIP s’ouvre sans logiciel et la taille n’a d’importance que tant qu’il reste dans un dossier de téléchargements. Pour tout ce qui est stocké ou déplacé plus loin, c’est un mauvais échange, et la meilleure réponse est de garder le `.tar.xz` exactement comme l’amont l’a publié et de l’ouvrir avec un outil local, puisque rien de ce que lit un bureau standard ne compressera à hauteur.

Décompresser du LZMA2 signifie tenir le dictionnaire avec lequel le fichier a été compressé, donc la mémoire requise suit ce réglage plutôt que la taille du fichier compressé. Un petit `.xz` écrit avec un grand dictionnaire est plus exigeant à déballer que sa taille ne le suggère.

Sur n’importe quel ordinateur portable ou serveur, c’est sans conséquence. Cela devient réel sur du matériel contraint — un routeur, une petite carte embarquée, un agent de build à mémoire plafonnée — et c’est le seul argument technique durable en faveur de la modeste fenêtre de 32 Ko de gzip en 2026. C’est aussi une raison pour laquelle certains projets publient encore un `.tar.gz` à côté du `.tar.xz`.

Tous les fichiers xz ne sont pas des tarballs. Une seule image disque compressée, un gros log, un vidage de base de données — appliquer xz à un fichier unique, c’est le format utilisé exactement comme conçu, sans TAR nulle part.

Le convertisseur lit ce qui est sorti de la couche xz et essaie de l’analyser comme un TAR ; quand cela échoue, il traite le contenu comme le seul fichier qu’il est, et le ZIP contient cela. Parce que xz ne stocke aucun nom d’origine — comme bzip2 et contrairement à gzip — l’entrée est nommée par le pipeline plutôt que par quoi que ce soit que l’archive ait mémorisé, donc donnez au fichier un nom qui ait du sens avant de le transmettre.

Cette conversion se passe sur notre serveur plutôt que dans la page. Le fichier est téléversé par une connexion chiffrée, décompressé, déballé, empaqueté en ZIP à partir du répertoire extrait et renvoyé, et le téléversement, le tar intermédiaire et la sortie sont tous supprimés à la fin de la tâche.

L’espace de travail est sauvegardé en mémoire et borné, jeté avec le conteneur qui l’a utilisé. Les téléversements gratuits s’arrêtent à 25 Mo, chaque tâche est tuée à soixante secondes, et les archives protégées par mot de passe échouent avec un message plutôt que d’attendre une invite qui n’a nulle part où apparaître. Rien n’est conservé sur le fichier et personne ne le regarde.

Si l’archive va vers une machine Linux, un agent de build ou une image de conteneur, la convertir est un pas en arrière sur tous les axes : la cible a déjà xz installé, le ZIP est considérablement plus gros à déplacer, et les modes et appartenances que portait le TAR ne survivent pas au passage dans un ZIP. Une version source convertie en ZIP puis compilée échouera parfois exactement pour cette raison, d’une manière qui ressemble à un problème du projet plutôt que de l’archive.

Convertissez quand une personne sur un bureau doit regarder à l’intérieur, quand un formulaire de téléversement exige un ZIP et ne peut pas être discuté, ou quand vous transmettez du contenu à quelqu’un qui n’installera jamais un archiveur. Si des fichiers `.tar.xz` vous parviennent régulièrement, 7-Zip et Keka gèrent les deux couches localement sans plafond de taille et sans téléversement, et les versions récentes de Windows incluent une commande `tar` qui fait la même chose depuis un terminal. C’est la meilleure réponse à long terme que n’importe quel convertisseur.

Les versions source sont habituellement publiées avec un fichier de somme de contrôle et souvent avec une signature détachée, et les deux décrivent le `.tar.xz` exactement comme l’amont l’a écrit. Vérifiez par rapport au téléchargement d’origine avant même de convertir quoi que ce soit, parce qu’un ZIP rempaqueté ne correspondra à aucun des deux — les membres sont identiques mais l’archive autour d’eux est nouvelle, écrite par un outil différent à un moment différent.

Ce n’est pas un défaut de la conversion ; c’est à cela que sert la vérification. L’ordre correct est de vérifier la signature sur le fichier que vous avez récupéré, de vous assurer qu’il vient du projet, et seulement ensuite de le rempaqueter pour ce qui exige un ZIP. Convertir d’abord et vérifier ensuite produit une non-concordance qui a l’air alarmante et qui ne veut rien dire, et c’est une manière tout à fait courante pour les gens de conclure qu’un téléchargement parfaitement bon a été modifié.