Convertir BZ2 en GZ

Bzip2 date de 1996, conçu par Julian Seward pour produire des fichiers plus petits que gzip sur la plupart des entrées. La technique est la transformée de Burrows-Wheeler suivie d’un codage de Huffman, ce qui donne en général 10 à 15 pour cent de mieux que Deflate sur du texte et du code. Le coût est la vitesse : bzip2 est notablement plus lent à compresser et à décompresser que gzip, et il utilise plus de mémoire.

Gzip date de 1992 et utilise Deflate, la combinaison LZ77 et Huffman que PKZIP avait popularisée. C’est plus rapide à compresser, plus rapide à décompresser, et c’est le défaut de tar, des paquets Debian, et de la majorité des outils Unix. La conversion de BZ2 vers GZ est ce que vous faites quand la portabilité compte plus que la taille : un fichier .gz se décompresse partout, un fichier .bz2 demande bzip2 qui n’est pas garanti sur toutes les plateformes.

La conversion est sans perte, et c’est ce que le registre signifie en marquant cette paire lossless. Le BZ2 est décompressé, le contenu binaire est exactement ce qu’il était à l’intérieur, et GZ est construit en compressant ce même contenu. La somme de contrôle CRC32 du GZ peut être vérifiée contre gunzip -t, et le SHA-256 du contenu décompressé est identique à celui qu’avait le contenu dans BZ2.

Cette garantie est ce qui rend la conversion utile. Un fichier peut voyager dans deux formats sans que personne ne s’inquiète de savoir s’il a été altéré en route, et c’est précisément la propriété qu’une archive doit avoir. La conversion préserve cela et le rend visible, et c’est l’unique cas où la conversion est strictement équivalente à une ré-émission.

Un fichier GZ commence par 10 octets d’en-tête qui contiennent un magic number, une version, un horodatage, des drapeaux d’extras, le nom du fichier d’origine, et un commentaire optionnel. Le BZ2 n’a pas d’en-tête, ou plutôt n’a qu’un magic number de deux octets, et c’est tout : pas d’horodatatage, pas de nom de fichier, pas de commentaire.

La conversion écrit un en-tête GZ avec l’horodatage du fichier BZ2 si l’information est disponible, et un nom de fichier dérivé du nom BZ2 (la substitution de .bz2 par .gz). Pour un fichier qui voyage à travers des sauvegardes horodatées, l’information est utile ; pour un fichier qui voyage en pièce jointe, elle est cosmétique. Aucune information n’est inventée : l’horodatage est mis à l’heure de la conversion quand l’original ne le porte pas, et c’est explicite dans la spécification.

Pour le même contenu, GZ est en général plus gros que BZ2 de 5 à 15 pour cent, parce que Bzip2 trouve des redondances que Deflate ne voit pas sur la transformée de Burrows-Wheeler. La différence est invisible sur un petit fichier et visible sur un corpus de plusieurs gigaoctets où chaque pour cent compte.

Si la taille compte plus que la portabilité, garder BZ2 d’origine est la bonne réponse. Si la portabilité Unix compte plus que la taille, GZ est la bonne réponse. Pour un corpus destiné à être archivé pour des années, le format est souvent un compromis, et c’est la lecture du fichier par les destinataires qui doit décider : un dépôt Debian préfère .gz, un dépôt Fedora accepte les deux, un dépôt R utilise .gz par convention historique.

GZ a un niveau de compression de 6 par défaut, sur une échelle de 1 à 9. Le niveau 6 est ce que gzip utilise, et c’est le bon compromis entre temps de compression et taille résultante. Le niveau 9 prend plusieurs fois plus de temps pour un gain typique de 1 à 2 pour cent, et n’est utile que pour un corpus destiné à être compressé une fois et décompressé souvent.

La conversion utilise le niveau par défaut, parce que c’est ce que la grande majorité des cas veut. Pour un cas qui veut autre chose, la conversion post-hoc avec gzip -9 fichier produit le résultat en une commande, et c’est l’édition qui vaut la peine quand on sait que le fichier sera archivé pour des années et décompressé souvent.

Bzip2 permet en théorie de concaténer plusieurs flux en un seul fichier, et certains outils anciens en ont profité pour produire des fichiers .bz2 multi-blocs. GZ ne peut pas : un fichier GZ a un seul flux compressé, et toute concaténation est lue comme une erreur par gunzip.

La conversion traite un seul flux BZ2, et un fichier multi-blocs déclenche un message d’erreur plutôt qu’une conversion silencieuse et incorrecte. Pour un fichier multi-blocs légitime, il faut d’abord le décomposer en flux unitaires avec bzip2 -dc fichier.bz2 > decompressed, puis re-compresser chaque flux en GZ séparément. Pour un fichier qui n’est en réalité qu’BZ2 corrompu concaténé avec un autre, c’est l’édition qui découvre l’origine de la corruption.

Les serveurs web peuvent compresser à la volée avec Content-Encoding: gzip, et le navigateur décompresse à la réception. Le fichier .gz sur disque est le même format que ce flux, ce qui est commode : un curl --compressed enregistre un fichier .gz qui peut être ré-utilisé tel quel. C’est une coïncidence de format, pas une conséquence technique, et la conversion n’a aucune opinion sur le sujet.

Pour un fichier .gz destiné à être servi en HTTP, le niveau de compression et les en-têtes ont moins d’importance que pour une archive de longue durée, parce que la décompression est faite à la volée par le navigateur. Pour un fichier .gz destiné à être archivé, le niveau de compression et les sommes de contrôle sont ce qui compte, et c’est cette dernière catégorie qui justifie l’existence de la conversion.

Bzip2 porte une somme CRC32 en fin de flux, et la conversion la vérifie pendant la décompression. Si la décompression produit moins d’octets que l’en-tête annonçait, ou si la somme ne correspond pas, la conversion s’arrête avec un message explicite plutôt que d’écrire GZ corrompu.

GZ porte deux sommes de contrôle : un CRC32 dans l’en-tête GZ, et optionnellement une taille non compressée. La conversion calcule le CRC32 et l’écrit dans le pied de fichier, et c’est la valeur que gunzip -t vérifiera. Pour une vérification supplémentaire, gzip -t -v affiche la taille décompressée attendue, et c’est l’édition qui détecte la corruption que les sommes internes ne voient pas.

Une archive complète est souvent tar.gz ou tar.bz2, ce qui combine le conteneur tar avec l’un ou l’autre des compresseurs. Convertir tar.bz2 en tar.gz demande deux étapes : décompresser le bz2, puis re-compresser le tar en gz. La première étape produit un fichier .tar qui est plusieurs fois plus gros que le bz2 d’origine, et la deuxième étape le recompresse.

Pour un fichier tar.bz2, le bon réflexe est de l’extraire directement, plutôt que de le recompresser en tar.gz. La conversion tar.bz2 vers tar.gz existe comme utilité, mais elle n’a de sens que pour des outils qui ne lisent pas bzip2 — et c’est de moins en moins courant. Pour un cas où elle est utile, la conversion post-hoc avec tar cjf fichier.tar.bz2 -C /source && gzip -9 fichier.tar fait le travail en deux commandes.

Cette conversion est particulière : elle est exécutée côté serveur, dans un conteneur, parce que la compression bzip2 et gzip demande un binaire natif que le navigateur ne peut pas fournir. Le fichier est téléversé sur api.quinvert.com, écrit dans un répertoire temporaire, traité par 7-Zip, et le résultat est retourné. Le répertoire temporaire est supprimé dans un bloc finally qui s’exécute aussi sur les chemins d’erreur, et le résultat est servi avec Cache-Control: no-store.

Pour un usage avec un contenu sensible — un projet non publié, un dépôt de code privé, un jeu de données sous embargo — c’est la conversion qu’il faut regarder de plus près. La limite est 25 Mo par fichier, 100 conversions par visiteur par jour, fuseau UTC, et le compteur est réinitialisé à minuit UTC. Pour un contenu plus sensible, garder BZ2 et le servir depuis votre propre infrastructure est la bonne réponse.