Convertir GZ en XZ

Personne ne convertit un fichier gzippé qu’il est sur le point d’ouvrir. Le lecteur ici regarde quelque chose qui s’est accumulé : une année de logs applicatifs tournés, des dumps de base de données nocturnes gardés pour conformité, un jeu de données de recherche qui doit rester disponible et qui se lit une fois par trimestre, des artefacts de CI que personne n’a supprimés. Gzip était le bon choix quand les fichiers ont été écrits — il est rapide, il est partout, et il était déjà dans la config de rotation des logs — et il n’est pas le bon choix pour la seconde moitié de la vie du fichier.

Cette distinction est toute la décision. Gzip optimise pour le moment de l’écriture et de la lecture ; XZ optimise pour les années entre les deux. Si l’archive va être récupérée et déballée par quelque chose qui est pressé, ou par un appareil avec très peu de mémoire, laissez-la telle quelle. Si elle va rester en stockage froid et se lire presque jamais, la conversion est proche de l’argent gratuit, et cela vaut la peine de la faire sur tout le dossier plutôt qu’un fichier à la fois.

Le nombre dans le registre est toute l’explication. Gzip, normalisé comme RFC 1952 en mai 1996, utilise DEFLATE avec une fenêtre d’historique de 32 Ko : quand il compresse l’octet un million, il peut voir en arrière jusqu’à l’octet neuf cent soixante-huit mille et pas plus loin. Tout ce qui s’est répété plus tôt est compressé à nouveau à partir de rien, comme si cela n’avait jamais été vu. XZ, depuis 2009, porte un dictionnaire que le registre enregistre jusqu’à 64 Mo — deux mille fois la portée.

C’est pourquoi le gain est énorme sur certaines entrées et nul sur d’autres. Une année de lignes de log répète les mêmes quarante modèles de messages pendant des gigaoctets, et gzip les redécouvre chacun des milliers de fois tandis que XZ les apprend une fois. Un dump SQL répète les noms de colonnes sur chaque ligne. Les arborescences source répètent les en-têtes de licence, les imports et le boilerplate à travers des centaines de fichiers. En face, un GZ qui tient une photographie ou une vidéo n’a pas de répétition à longue distance à trouver, parce que la redondance a été retirée par JPEG ou H.264 avant que gzip ne la voie, et le plus puissant compresseur du monde ne peut pas inventer une structure qui n’y est pas.

Le temps de compression est le coût évident et le moins important, parce qu’il est payé une fois par une machine qui ne vous attend pas. XZ est radicalement plus lent que gzip à la même tâche — c’est la conséquence directe de chercher dans un dictionnaire deux mille fois plus grand — et pour un travail que vous lancez la nuit sur un seau de stockage, ce n’est pas un problème qui mérite une optimisation.

La mémoire à la décompression est le coût qui décide réellement des choses, et c’est celui que les gens manquent. Gzip a besoin de sa fenêtre de 32 Ko pour déballer, ce qui veut dire rien du tout ; XZ a besoin d’un tampon à l’échelle du dictionnaire avec lequel le fichier a été écrit. Sur un portable ou un serveur, c’est sans particularité. Sur un routeur, un petit appareil embarqué, un conteneur à mémoire plafonnée ou un agent de build aux limites serrées, c’est la différence entre l’archive qui s’ouvre et le processus qui se fait tuer. Vérifiez la machine qui déballera le fichier, pas celle qui le compresse.

Les deux formats compressent exactement un flux, donc aucun ne sait ce qu’est un répertoire. En pratique un `.gz` est presque toujours un `.tar.gz` : un TAR portant les noms et les dossiers, avec gzip autour. La conversion ôte les deux couches, puis remet les deux — les membres sont rassemblés dans un TAR frais et ce TAR est compressé avec xz.

Le cas qu’il vaut la peine de connaître est celui où la source n’était pas un tarball. Un simple `access.log.gz` tient un fichier ordinaire, et le réemballage construit tout de même un TAR autour, donc ce qui revient est un tarball contenant `access.log` plutôt qu’un fichier compressé nu. C’est inoffensif si vous le déballez avec `tar xJf` et confus si vous allez chercher `unxz` et trouvez un fichier appelé `output.tar`. Si votre outillage attend un flux compressé unique sans rien d’emballé autour, c’est le détail à prévoir.

Un flux gzip a un champ d’en-tête pour le nom du fichier d’origine, ce qui explique pourquoi décompresser `dump.gz` sur une machine Unix peut vous redonner `dump.sql` même si rien dans l’extension ne le disait. XZ n’a pas un tel champ. Il stocke une vérification d’intégrité et rien sur l’origine des données.

Cela a une conséquence pratique aux deux extrémités de cette conversion et cela a causé un vrai bogue dans ce convertisseur, consigné dans le code : parce que gzip stocke un nom et xz non, un tarball interne arrive d’un GZ avec un nom sensé et d’un XZ avec ce que l’extracteur a choisi. La correction a été de forcer le type tar plutôt que de l’inférer à partir du nom. Pour vous, la leçon est plus simple — l’extension que vous mettrez sur le XZ téléchargé est la seule étiquette qu’il portera jamais, alors appelez-le `quelquechose.tar.xz` et pensez-le.

Les deux formats se vérifient eux-mêmes, ce qui est l’une des raisons pour lesquelles cette conversion peut être lancée sans surveillance. Un flux gzip se termine par un CRC-32 et la longueur décompressée ; un flux XZ porte sa propre vérification, CRC-64 par défaut, sur les données décompressées. Dans les deux cas, un téléchargement tronqué ou un bit basculé produit une erreur à la décompression plutôt qu’un fichier qui se lit silencieusement court.

Ce qu’aucun des deux ne peut faire, c’est vous dire quel fichier est endommagé, parce qu’à cette couche il n’y a pas de fichiers. Un ZIP ou un 7Z enregistre une somme de contrôle par entrée et peut rapporter qu’un membre sur quarante est corrompu ; un flux compressé ne peut que rapporter que le flux est corrompu. Si l’intégrité par membre est ce dont vous avez besoin d’une archive — parce que vous avez l’intention de récupérer le reste quand une partie pourrit — alors un compresseur de flux est la mauvaise forme pour le job quelle que soit sa qualité de compression.

Cette conversion ne tourne pas sur votre appareil. La plupart des outils sur ce site gardent le fichier local et le disent ; réemballer des archives est l’une des exceptions, parce qu’il faut 7-Zip et xz comme vrais programmes. Le fichier part par une connexion chiffrée vers un conteneur qui les exécute, et le conteneur n’a pas d’accès Internet sortant propre.

Chaque travail reçoit un répertoire de travail sur un système de fichiers en mémoire, et ce répertoire est supprimé dès que le travail se termine qu’il ait réussi ou non. Tout ce qui tourne encore après soixante secondes est tué — une archive malformée met un compresseur en boucle bien plus souvent qu’elle ne le fait échouer. Le niveau gratuit accepte 25 Mo par fichier téléversé, ce qui pour un tarball de logs gzippé est beaucoup de texte mais est un vrai plafond sur un jeu de données.

BZ2 est l’autre réponse traditionnelle à « gzip ne compresse pas assez cela », et sur la plupart du texte il perd maintenant contre XZ sur les deux axes à la fois — un moins bon taux et une décompression plus lente. Le registre marque BZ2 comme hérité pour cette raison. Son seul avantage restant est l’envers du point mémoire ci-dessus : bzip2 travaille en blocs d’au plus 900 Ko, si bien qu’en déballer un ne demande jamais beaucoup de mémoire.

Donc le choix n’est pas vraiment une affaire de taux. Choisissez XZ quand la machine qui déballera l’archive est un ordinateur ordinaire, ce qu’elle est en général, et choisissez BZ2 seulement quand elle ne l’est pas — un vieil appareil, un conteneur contraint, un système où xz n’est vraiment pas installé et ne peut pas l’être. Choisir BZ2 pour sa compression seule est une décision d’environ 2005 qui n’est plus vraie depuis longtemps.

Faites un fichier d’abord et regardez les deux tailles. Une seule archive représentative vous dit ce que le reste du dossier fera de manière bien plus fiable que n’importe quelle règle empirique, parce que la réponse est décidée par le contenu plutôt que par les formats — la même conversion qui divise par deux un tarball de logs ne fait rien du tout à un dossier de photos. Si le premier fichier bouge à peine, arrêtez-vous ; vous avez appris que la donnée n’a pas de redondance à longue distance et aucun compresseur n’en trouvera.

Puis vérifiez la liste plutôt que la taille seule. Lancez `tar tJf` sur le résultat et comparez le compte d’entrées et les chemins avec ce que le GZ contenait, en particulier le premier niveau : une archive empaquetée depuis l’intérieur d’un répertoire et une empaquetée depuis son parent diffèrent par un dossier de tête dans chaque chemin, et cette différence casse des scripts longtemps après que quiconque se souvienne d’avoir converti quoi que ce soit. Une fois que la liste correspond et que la taille est ce que vous attendiez, l’original n’a plus de travail à faire.