Convertir XZ en TAR

XZ est un format de flux qui compresse un unique flux d’octets, sans aucune structure de répertoire ni métadonnée. Un fichier `.tar.xz` est en fait deux couches empilées : un TAR qui décrit les fichiers et leurs chemins, et un XZ qui compresse l’ensemble. Déballer vers un TAR, c’est retirer la couche de compression et garder la structure de fichiers, et c’est la seule chose que cette conversion fait.

La sortie est un TAR, pas un dossier déballé. Cela peut sembler paradoxal à une époque où l’on parle de fichiers et de dossiers, mais le TAR est précisément le format de conteneur qui représente un ensemble de fichiers comme un flux, et c’est le format de sortie parce que c’est ce qui est utile : un TAR peut être ouvert par tout archiveur, envoyé comme un fichier, retraité par un autre outil de compression.

Le TAR contient un en-tête pour chaque fichier, avec son nom, son chemin, sa taille, son type, ses bits de permission, son propriétaire, son groupe, et son horodatage de modification. La conversion lit ces en-têtes depuis le TAR qui sort de la couche xz et les réécrit tels quels dans le TAR de sortie, parce que c’est l’information qu’un TAR porte par construction.

Aucune valeur n’est modifiée. Aucun nom n’est renommé, aucun chemin n’est réécrit, aucune permission n’est ajustée. C’est explicite dans le code source, et c’est la propriété qui distingue cette conversion d’une opération qui toucherait aux fichiers en cours de route. Pour un cas où les permissions POSIX comptent — un binaire, un script, un fichier d’un projet multi-utilisateurs — c’est ce qui rend le passage par TAR fiable plutôt qu’approximatif.

Tous les fichiers XZ ne sont pas des tarballs. Une seule image disque compressée, un gros log, un dump de base de données — appliquer xz à un fichier unique, c’est le format utilisé exactement comme conçu, sans TAR nulle part. Le fichier `.xz` est un flux qui se décompresse en un seul flux, et ce flux n’est pas un TAR valide.

La conversion lit ce qui sort de la couche xz et essaie de l’analyser comme un TAR. Quand cela échoue, le contenu est traité comme le seul fichier qu’il est, et le TAR de sortie contient ce fichier entouré d’un en-tête. 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é. Donnez au fichier un nom qui ait du sens avant de le transmettre.

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’une de celles qui peuvent le déclencher sur un fichier honnête. XZ est suffisamment efficace pour mettre plusieurs gigaoctets de contenu déballé dans un fichier assez petit pour être téléversé confortablement, donc une archive source ordinaire peut se voir refuser. 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.

La sortie est strictement équivalente en contenu à un `.tar` créé localement avec `tar -cf`. Les octets sont les mêmes parce que la conversion est déterministe : décompression, lecture du TAR, réécriture du TAR. Aucune touche n’est portée au contenu des fichiers, et c’est explicite dans le code source.

Ce qui peut différer est ce que le TAR source ne portait pas, et un TAR source qui sort de xz ne porte pas plus que ce qu’un TAR porte normalement. Pour un cas où la conversion ajoute des informations qui n’existaient pas dans la source, c’est explicite que c’est une erreur : la conversion ne fait pas de supposition sur les fichiers, et tout ce qui n’est pas dans le TAR source n’est pas dans le TAR de sortie.

Le fichier est téléversé par une connexion chiffrée, décompressé par 7-Zip, et le TAR est reconstitué et renvoyé. Le répertoire de travail est sauvegardé en mémoire et borné, et il est supprimé dès que le travail est terminé. C’est explicite dans le code source, et c’est la propriété qui distingue cette conversion des paires qui tournent entièrement dans le navigateur.

L’allocation gratuite est de 25 Mo par fichier et 100 conversions serveur par jour, avec jusqu’à 100 fichiers en lot. Pour un fichier plus gros ou un usage intensif, c’est explicite que la limite existe et qu’elle est technique, pas commerciale. Pour un cas ordinaire d’archive, c’est suffisant.

Le TAR porte les permissions POSIX, le propriétaire, le groupe, et l’horodatage de modification. Tout cela survit byte pour byte, parce que le TAR source portait ces informations et que la conversion ne fait que les réécrire. Pour un cas où la fidélité compte — un binaire setuid, un script qui doit rester exécutable, un fichier de configuration avec un propriétaire particulier — c’est ce qui rend la conversion fiable.

Ce qui ne survit pas, c’est tout ce que les conteneurs tenaient sur les fichiers plutôt que dans les fichiers : un mot de passe, les attributs étendus ACL et xattr, les capacités Linux, les horodatages d’accès. C’est explicite dans le code source, et c’est la propriété commune à toutes les conversions d’archives. Pour un cas où ces attributs comptent, le bon outil est un archiveur local qui les transporte, et c’est ce qui rend les archives natives toujours plus riches que ce qui sort d’une conversion.

Le TAR de sortie est un TAR standard, lisible par tout outil qui lit un TAR. La conversion n’a rien ajouté qui empêcherait une recompression par gzip, bzip2, xz, zstd, ou n’importe quel autre format, et c’est explicite que c’est la propriété de la sortie : un TAR est un format ouvert, et c’est le travail d’autres outils de le compresser dans le format qui leur convient.

Le cas d’utilisation typique est précisément enchaîner : convertir XZ en TAR pour retirer la couche de compression, puis recompresser en Zstandard pour avoir la compression moderne, ou en ZIP pour transmettre à quelqu’un qui n’a que 7-Zip, ou garder le TAR tel quel pour un archivage à long terme sans compression. La sortie est volontairement minimale pour servir toutes ces destinations sans verrouiller le choix en aval.

Déposez jusqu’à cent XZ ensemble, et chacun sort en TAR. Pour une migration d’archives d’un format à l’autre, c’est une opération qui revient : des sauvegardes qui ont été écrites en `.tar.xz` et qui doivent être recompressées dans un autre format, des builds qui produisent l’un et qui doivent livrer l’autre.

Le lot est traité en série, et le résultat est un ZIP qui contient tous les TAR. Comme TAR n’est pas compressé, le ZIP de sortie sera typiquement plus gros que le ZIP d’entrée, et c’est explicite dans le code source que c’est la propriété de la sortie. Pour un cas où la taille compte en sortie, la conversion vers GZ ou vers BZ2 directement est préférable, et c’est explicite que TAR n’est pas une option pour la transmission quand la taille compte.

La conversion se fait sur notre serveur, ce qui veut dire que le fichier est téléversé et traité dans un environnement isolé, puis supprimé. Le quota est de 25 Mo par fichier et 100 conversions par jour, et la fenêtre est le jour UTC. Pour un fichier qui contient ce qui ne doit pas fuiter, c’est explicite que cette conversion n’est pas la bonne : la décompression locale avec un outil installé est la voie qui ne fait pas sortir le fichier de la machine.

Pour un cas ordinaire — une archive publique, un téléchargement de source, un log anonymisé — la conversion est sans particularité. Pour un cas sensible, l’avertissement vaut la peine d’être lu : un fichier qui ne doit pas être téléversé n’a pas sa place dans une conversion qui téléverse par construction, et c’est explicite que c’est la propriété technique de cette paire qui rend l’avertissement nécessaire.