Convertir XZ en GZ

gzip a été publié par Jean-loup Gailly et Mark Adler en 1992, et la version 1.0 est sortie quelques mois plus tard. Trente ans plus tard, c’est le format de compression que tout Unix-like produit par défaut, que tout outil de sauvegarde sait lire, que tout langage de programmation a dans sa bibliothèque standard. Il utilise l’algorithme DEFLATE, combinaison de LZ77 et Huffman, ce qui produit une bonne compression sur la plupart des contenus sans être le meilleur disponible.

C’est précisément la raison pour laquelle un XZ est converti en GZ : la destination exige une compression que rien ne refuse. Pour un script de build, un outil d’archivage, un téléchargement destiné à un public varié, un script shell qui appelle `gunzip`, GZ est la réponse sans négociation. C’est ce que la conversion produit, et c’est ce qu’elle fait.

XZ utilise LZMA2 avec un dictionnaire de 64 Mo, ce qui lui permet de capturer des répétitions à longue distance dans un flux et de produire des fichiers 30 à 40 pour cent plus petits que gzip sur les contenus textuels et les binaires structurés. GZ utilise DEFLATE avec une fenêtre de 32 Ko, ce qui est suffisant pour la plupart des motifs locaux mais ne capture pas les répétitions à grande échelle.

Pour un texte, un code source, un binaire structuré, un tarball de source, le GZ produit par la conversion sera sensiblement plus gros que le XZ source — souvent 30 à 50 pour cent plus gros. Pour une image, un média déjà compressé, un PDF, un JPG, la différence est marginale parce que l’amont a déjà aplati les motifs. La conversion ne peut pas faire mieux que l’algorithme, et gzip est en dessous de xz sur la plupart des contenus où xz est meilleur.

XZ est un format de flux à un seul membre, sans champ pour un nom ou un chemin. Un fichier `.xz` peut contenir un seul fichier — un dump, un log, une image disque —, ou il peut être la couche extérieure d’un `.tar.xz` où la structure de répertoire vit dans le TAR en dessous.

La conversion essaie de détecter ce qui sort de la couche xz et agit en conséquence : si le contenu est un TAR valide, il est déballé, et chaque membre est recompressé en GZ dans un tar de sortie. Si ce n’est pas un TAR, le contenu est traité comme un seul fichier, recompressé en GZ, et nommé d’après le pipeline plutôt que d’après quoi que ce soit que l’archive ait mémorisé. C’est explicite dans le code source, et c’est la même logique que pour les autres conversions d’archives.

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 peut le déclencher, comme toutes les conversions depuis xz. Un XZ suffisamment compressé peut mettre plusieurs gigaoctets de contenu déballé dans un fichier assez petit pour être téléversé confortablement. 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.

Contrairement à bzip2 et xz, gzip stocke le nom du fichier source dans son en-tête, ce qui veut dire qu’un `gunzip fichier.gz` produit un fichier avec le nom d’origine. C’est explicite dans le format, et c’est la propriété qui rend GZ plus commode que XZ ou BZ2 dans un workflow où les noms comptent.

La conversion préserve cette propriété : le nom du fichier interne du XZ est utilisé quand il existe, et un nom par défaut est utilisé sinon. Pour un cas où un script de build attend un nom précis dans le tar déballé, c’est ce qui rend la conversion vers GZ préférable à la conversion vers BZ2, et c’est explicite dans le code source que c’est la propriété de format qui est exploitée.

GZ utilise une fenêtre de 32 Ko, ce qui veut dire que la mémoire requise est bornée et modeste. C’est l’une des raisons pour lesquelles GZ a survécu sur du matériel contraint et reste utile quand la compression doit se faire rapidement. La conversion hérite de cette propriété : un XZ décompressé puis recompressé en GZ consomme moins de mémoire et de temps que la conversion vers BZ2 ou XZ.

Pour un usage interactif, c’est ce qui rend GZ plus pratique. Pour un archivage à long terme, c’est moins bon, et c’est explicite dans le code source que c’est l’équilibre entre vitesse et taux de compression qui distingue les formats. La conversion ne peut pas changer l’équilibre, et c’est à la destination de décider.

Le fichier est téléversé par une connexion chiffrée, décompressé par 7-Zip, recompressé en GZ, et le résultat est 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.

Les fichiers survivent byte pour byte, ce qui est la propriété qu’archive la conversion : aucun bit n’est modifié, aucun nom n’est changé dans le cas d’un tar, aucune permission n’est touchée. Le contenu des fichiers est exactement ce qu’il était dans la source, parce que la compression est déterministe et que la décompression redonne le flux d’origine.

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 permissions POSIX d’origine, les horodatages de modification, le bit setuid si le tar source le portait. C’est explicite dans le code source, et c’est la propriété commune à toutes les conversions d’archives. Pour un cas où ces métadonnées comptent, le bon outil est un archiveur local qui les transporte.

Pour une compression maximale sur des contenus où la taille compte vraiment — sauvegarde, distribution, archive — xz ou zstd produisent des fichiers sensiblement plus petits. Pour un contenu textuel, la différence est souvent 30 à 40 pour cent, et c’est explicite dans le code source que c’est la propriété de l’algorithme.

Choisir GZ est un choix de compatibilité, pas un choix de compression. Pour un fichier destiné à un système d’exploitation ancien, à un script qui appelle `gunzip`, à un utilisateur qui ne sait pas ce qu’est xz, c’est le bon choix. Pour un fichier où la taille compte et où la destination accepte plusieurs formats, c’est rarement le meilleur, et c’est explicite que la conversion ne peut pas faire mieux que l’algorithme le permet.

Déposez jusqu’à cent XZ ensemble, et chacun sort en GZ. 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 lues par un outil qui n’accepte que `.tar.gz`, 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 GZ. La taille totale du ZIP sera typiquement plus grande que celle du ZIP d’entrée, parce que GZ est moins efficace que XZ, et c’est explicite dans le code source que c’est la propriété de l’algorithme. Pour un cas où la taille compte, c’est une raison supplémentaire de reconsidérer le choix de GZ en sortie.