Convertir XZ en BZ2

bzip2 a été publié par Julian Seward en 1996 et standardisé dans la plupart des distributions Linux entre 1998 et 2000. Il utilise la transformée de Burrows-Wheeler suivie d’un codage de Huffman, ce qui produit des fichiers substantiellement plus petits que gzip sur la plupart des contenus, et moins bons que xz ou zstd sur les mêmes contenus. Le format a eu son heure de gloire entre 2000 et 2015 environ, et il reste attendu dans certains contextes précis : des archives historiques, des outils qui ont été écrits à cette époque, des scripts de build qui ont bzip2 dans leurs dépendances, des systèmes embarqués qui n’embarquent pas xz.

Cette conversion sert ces cas-là. Le XZ est décompressé en mémoire, puis le flux est recompressé en BZ2 par la même chaîne d’outillage. Le résultat est un fichier bzip2 standard, lisible par tout ce qui lit du `.bz2`, et c’est la seule chose qu’elle fait.

XZ utilise LZMA2, un algorithme de dictionnaire de 64 Mo combiné à un codage arithmétique de plage, ce qui en fait l’un des compresseurs généralistes les plus efficaces disponibles. BZ2 utilise la transformée de Burrows-Wheeler sur des blocs de 900 Ko, suivie d’un Move-To-Front et d’un codage de Huffman, ce qui produit une bonne compression sur les motifs locaux mais ne capture pas les répétitions à longue distance.

Pour un texte, un binaire, un code source, la différence typique est que BZ2 fait un fichier 10 à 20 pour cent plus gros que XZ sur le même contenu, et c’est explicite dans le code source. Pour une image ou un média déjà compressé, la différence est marginale parce que la compression d’amont a déjà aplati les motifs. La conversion ne peut pas faire mieux que l’algorithme le permet, et BZ2 est en dessous de XZ sur la plupart des contenus.

BZ2 travaille par blocs de 900 Ko et chaque bloc est traité indépendamment, ce qui veut dire que la mémoire requise est bornée et modeste. C’est l’une des raisons pour lesquelles BZ2 a survécu sur du matériel contraint où xz est trop gourmand. La conversion hérite de cette propriété : un XZ décompressé en mémoire puis recompressé en BZ2 demande moins de mémoire vive qu’une compression XZ directe.

Le temps est l’autre face. BZ2 est plus lent que XZ à la compression et plus lent à la décompression sur les contenus où XZ est meilleur. Pour un fichier qu’on ne touche qu’une fois, c’est sans importance. Pour un fichier qu’on compresse et décompresse en boucle, c’est un coût qu’il faut prendre en compte, et c’est explicite dans le code source que c’est la propriété fondamentale de l’algorithme.

XZ est un format de flux à un seul membre, sans aucun champ pour un nom, un chemin ou un bit de permission. Un fichier `.xz` peut contenir un seul fichier compressé — un dump de base de données, 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 BZ2 dans un tar de sortie. Si ce n’est pas un TAR, le contenu est traité comme un seul fichier, recompressé en BZ2, 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. XZ est suffisamment efficace pour mettre plusieurs gigaoctets de contenu déballé dans un fichier assez petit pour être téléversé confortablement, et un fichier source honnête peut donc 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.

Le fichier est téléversé par une connexion chiffrée, décompressé par 7-Zip, recompressé en BZ2, 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é, 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, et la conversion perd ce qu’elle ne peut pas transporter.

Pour un fichier qui n’a pas d’exigence explicite de format, BZ2 est rarement le meilleur choix en 2026. gzip est plus largement lu et plus rapide ; xz compresse mieux sur la plupart des contenus ; zstd est meilleur sur à peu près tout et est en train de s’imposer comme le nouveau défaut. Choisir BZ2 par habitude est un cas où l’habitude devance la décision.

La conversion existe parce qu’il y a des contextes où BZ2 est exigé, et c’est ce qu’elle sert. Pour un cas où le format est libre, prendre gzip pour la compatibilité, xz pour la taille, zstd pour les deux. La conversion BZ2 est une conversion contrainte par la destination, pas un choix par défaut à valider.

Déposez jusqu’à cent XZ ensemble, et chacun sort en BZ2. 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.bz2`, 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 BZ2. La taille totale du ZIP sera typiquement plus grande que celle du ZIP d’entrée, parce que BZ2 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 BZ2 en sortie.

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 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.