bzip2, bunzip2 − compacteur de fichiers par tri de blocs, v1.0.2
bzcat − décompacte les fichiers sur stdout.
bzip2recover − récupère des données de fichiers bzip2 endommagés.

bzip2 [ −cdfkqstvzVL123456789 ] [ noms-fichiers ... ]
bunzip2 [ −fkvsVL ] [ noms-fichiers ... ]
bzcat [ −s ] [ noms-fichiers ... ]
bzip2recover nom-fichier

bzip2 compacte des fichiers en utilisant l’algorithme de réduction de texte par tri de blocs de Burrows-Wheeler, et le codage d’Huffman. La réduction est généralement nettement meilleure que celle atteinte par des compacteurs plus conventionnels basés sur LZ77/LZ78, et approche les performances de la famille des compacteurs statistiques PPM.

Les options de ligne de commandes sont délibérément très similaires à celles de GNU gzip, mais elles ne sont pas identiques.

bzip2 attend une liste de noms de fichiers pour accompagner les options de ligne de commandes. Chaque fichier est remplacé par une version compactée de lui−même, avec le nom « nom-original.bz2 ». Chaque fichier compacté a la même date de modification, les mêmes permissions et, quand c’est possible, les mêmes propriétés que celles du fichier original, de sorte que ces caractéristiques peuvent être correctement restaurées au moment de la décompression. Le traitement du nom du fichier est naïf dans le sens qu’il n’y a pas de mécanisme pour préserver les noms, permissions, propriétés et dates des fichiers situés dans des systèmes de fichiers où ces concepts font défaut, ou qui souffrent de restrictions strictes sur la longueur des noms de fichiers, comme MS-DOS.

bzip2 et bunzip2, n’écraseront par défaut pas les fichiers existants. Si vous voulez que cela se produise, utilisez l’option −f.

Si aucun nom de fichier n’est indiqué, bzip2 compacte de l’entrée standard vers la sortie standard. Dans ce cas, bzip2 n’écrira pas la sortie compactée sur un terminal, puisque cela serait incompréhensible et donc inutile.

bunzip2 (ou bzip2 −d) décompacte tous les fichiers précisés. Les fichiers qui n’ont pas été créés par bzip2 sont détectés et ignorés, et un avertissement est émis. bzip2 tente de deviner le nom du fichier décompacté à partir de celui du fichier compacté de la manière suivante :

nom-fichier.bz2 devient nom-fichier nom-fichier.bz devient nom-fichier nom-fichier.tbz2 devient nom-fichier.tar nom-fichier.tbz devient nom-fichier.tar unautrenom devient unautrenom.out

Si le fichier ne se termine pas par l’un des suffixes reconnus, à savoir .bz2, .bz, .tbz2 ou .tbz, bzip2 se plaindra de ne pas pouvoir deviner le nom du fichier original, et utilisera le nom du fichier auquel il ajoutera .out à la fin.

Comme pour la compression, ne pas fournir de nom de fichier provoque la décompression de l’entrée standard sur la sortie standard.

bunzip2 décompactera correctement un fichier qui est la concaténation de deux fichiers compactés ou plus. Le résultat est la concaténation des fichiers non compactés correspondants. Le test d’intégrité (−t) des fichiers compactés concaténés est également supporté.

Vous pouvez aussi compacter ou décompacter des fichiers sur la sortie standard en fournissant l’option −c. Plusieurs fichiers peuvent être compactés et décompactés de cette façon. Les sorties résultantes sont envoyées séquentiellement sur stdout. La compression de multiples fichiers d’une telle façon génère un flux contenant des représentations multiples de fichiers compactés. Un tel flux ne peut être décompacté correctement que par bzip2 version 0.9.0 ou ultérieure. Les versions antérieures de bzip2 s’arrêteront après la décompression du premier fichier du flux.

bzcat (ou bzip2 -dc) décompactent tous les fichiers spécifiés sur la sortie standard.

bzip2 lira les arguments dans les variables d’environnement BZIP2 et BZIP, dans cet ordre, et les traitera avant tout autre argument lu à partir de la ligne de commandes. Ceci donne une façon pratique de fournir des arguments par défaut.

La compression est toujours effectuée, même si le fichier compacté est légèrement plus volumineux que le fichier original. Les fichiers de moins d’une centaine d’octets ont tendance à s’agrandir, car le mécanisme de compression comporte toujours un surplus constant d’à peu près 50 octets. Les données aléatoires (incluant la sortie de la plupart des compacteurs de fichiers) sont codées à environ 8.05 bits par octet, ce qui donne une expansion d’environ 0.5 %.

Comme vérification interne pour votre sécurité, bzip2 utilise des CRC 32 bits pour s’assurer que la version décompactée d’un fichier est identique à l’original. Ceci permet une protection contre la corruption des données compactées, et contre des bogues non détectés de bzip2 (heureusement très improbables). La probabilité qu’une corruption de données passe inaperçue est infime, environ une chance sur 4 milliards pour chaque fichier compacté. Soyez toutefois conscient que la vérification se produit lors de la décompression, et qu’elle ne peut donc vous informer que lorsque quelque chose s’est mal passé. Elle ne peut pas vous permettre de récupérer les données non compactées originales. Vous pouvez utiliser bzip2recover pour essayer de récupérer des données de fichiers endommagés.

Valeurs de retour : 0 pour une sortie normale, 1 pour des problèmes d’environnement (fichier non trouvé, options invalides, erreurs d’entrée/sortie, etc.), 2 pour indiquer un fichier compacté corrompu, 3 pour une erreur de cohérence interne (un bogue, p.ex.) qui a fait paniquer bzip2.

−c --stdout

Compacter ou décompacter sur la sortie standard.

−d --decompress

Forcer la décompression. bzip2, bunzip2 et bzcat constituent en fait le même programme, et la décision quant aux actions à entreprendre est déterminée sur base du nom du fichier utilisé. Cette option surcharge ce mécanisme, et force bzip2 à décompacter.

−z --compress

Le complément de −d : force la compression, quel que soit le nom d’invocation.

−t --test

Vérifier l’intégrité des fichiers spécifiés, mais ne pas les décompacter. Cela effectue en fait une décompression de test, et jette ensuite le résultat décompacté.

−f --force

Forcer l’écrasement des fichiers en sortie. Normalement, bzip2 n’écrase pas les fichiers préexistants. Force également bzip2 à briser les liens matériels de fichiers, ce qu’il ne ferait pas autrement.

bzip2 refuse normalement de décompacter des fichiers s’ils n’ont pas les octets d’en-tête magique corrects. S’il est forcé (-f), il traversera de tels fichiers sans les modifier. C’est la façon dont GNU gzip se comporte.

−k --keep

Garder (ne pas effacer) les fichiers d’entrée durant la compression ou la décompression.

−s --small

Réduire l’utilisation de la mémoire pour la compression, la décompression et la vérification. Les fichiers sont décompactés et testés en utilisant un algorithme modifié qui requiert uniquement 2.5 octets par octet de bloc. Cela signifie que tout fichier peut être décompacté avec 2300 Ko de mémoire, même s’il le sera à une vitesse deux fois lente que la normale.

Durant la compression, −s sélectionne une taille de bloc de 200 Ko, ce qui limite l’utilisation de mémoire d’à peu près le même nombre, aux dépens du coefficient de compression. Bref, si votre machine possède peu de mémoire vive (8 Mo ou moins), utilisez −s pour tout ce que vous faites. Voir GESTION DE LA MÃMOIRE plus bas.

−q --quiet

Supprimer les messages d’avertissement non essentiels. Les messages se rapportant aux erreurs d’E/S et à d’autres événements critiques ne sont pas supprimés.

−v --verbose

Mode verbeux -- montre le coefficient de compression pour chaque fichier traité. Des −v supplémentaires augmentent le niveau de volubilité, en affichant des tas d’informations qui sont principalement utiles à des fins de diagnostic.

−L --license -V --version

Afficher la version du logiciel, les termes de la licence et les conditions d’utilisation.

−1 (ou −−fast) Ã −9 (ou −−best)

Fixer la taille de bloc à 100, 200, ... 900 Ko lors de la compression. N’a aucun effet lors de la décompression. Voyez GESTION DE LA MÃMOIRE ci−dessous. Les alias −−fast et −−best sont principalement destinés à la compatibilité avec GNU gzip. En particulier, −−fast n’accélère pas significativement la compression. Et −−best sélectionne simplement le comportement par défaut.

−-

Traiter tous les arguments ultérieurs comme des noms de fichiers, même s’ils débutent par un tiret. Ainsi, vous pouvez traiter des fichiers dont le nom commence par un tiret. Exemple : bzip2 −- −monfichier.

−-repetitive-fast --repetitive-best

Ces options sont redondantes dans les versions 0.9.5 et ultérieures. Elles fournissaient un contrôle assez grossier sur le comportement de l’algorithme de tri dans les versions antérieures, ce qui était parfois utile. Les versions 0.9.5 et ultérieures disposent d’un algorithme amélioré qui rend l’usage de ces options inutile.

bzip2 compacte les fichiers de grande taille par blocs. La taille de bloc affecte à la fois le coefficient de compression atteint, et la quantité de mémoire nécessaire pour la compression et la décompression. Les options −1 à −9 précisent la taille de bloc utilisée, de 100.000 octets à 900.000 octets (par défaut) respectivement. Au moment de la décompression, la taille de bloc utilisée pour la compression est lue à partir de l’en−tête du fichier compacté, et bunzip2 s’alloue ensuite juste assez de mémoire pour décompacter ce fichier. Puisque les tailles de blocs sont conservées dans les fichiers compactés, il s’ensuit que les options −1 à −9 ne sont pas pertinentes, et sont donc ignorées durant la décompression.

Les exigences mémoire de la compression et de la décompression, en octets, peuvent être estimées à :

Compression : 400 Ko + ( 8 x taille de bloc )

Décompression : 100 Ko + ( 4 x taille de bloc ), ou 100 Ko + ( 2.5 x taille de bloc )

Des largeurs de blocs plus importantes voient les bénéfices marginaux retirés diminuer rapidement. La plus grosse partie de la compression provient des deux ou trois cents premiers Ko de taille de bloc, un fait à retenir quand on utilise bzip2 sur de petites machines. Il est également important de savoir que les exigences mémoire de la décompression sont fixées au moment de la compression par le choix d’une taille de bloc.

Pour les fichiers compactés avec la taille de bloc par défaut de 900 Ko, bunzip2 aura besoin d’environ 3700 Ko pour la décompression. Pour permettre la décompression de tout fichier sur une machine avec 4 Mo de RAM, bunzip2 possède une option pour décompacter en n’utilisant que la moitié environ de ces 3700 Ko, à savoir à peu près 2300 Ko. La vitesse de décompression est également réduite de moitié, et vous ne devriez donc utiliser cette option (−s) qu’en cas de nécessité absolue.

En général, essayez d’utiliser la taille de bloc la plus grande que vos exigences mémoire permettent, car cela maximise la réduction obtenue. Les vitesses de compression et de décompression ne sont virtuellement pas affectées par la taille de bloc.

Un autre aspect significatif s’applique aux fichiers qui peuvent tenir dans un seul bloc, c.-à -d. la plupart des fichiers que vous rencontrez en utilisant une grande taille de bloc. La quantité réelle de mémoire utilisée est proportionnelle à la taille du fichier, puisque le fichier est plus petit qu’un bloc. Par exemple, compacter un fichier de 20000 octets avec l’option -9 forcera le compacteur à allouer environ 7600 Ko de mémoire, mais n’en utilisera réellement que 400 Ko + 20000 * 8 = 560 Ko. De même, le décompacteur allouera 3700 Ko mais n’utilisera que 100 Ko + 20000 * 4 = 180 Ko.

Voici une table qui résume l’utilisation maximale de la mémoire pour différentes tailles de blocs, ainsi que la taille compactée totale de 14 fichiers du Calgary Text Compression Corpus totalisant 3.141.622 octets. Cette table donne un certain aperçu de l’évolution de la compression avec la taille de bloc. Ces chiffres tendent à minimiser l’avantage des tailles de blocs plus importantes pour des fichiers plus grands, puisque le Corpus est dominé par des petits fichiers.

Usage Usage Usage Taille du Option compr. décompr. décompr. -s Corpus

-1 1200 Ko 500 Ko 350 Ko 914704 -2 2000 Ko 900 Ko 600 Ko 877703 -3 2800 Ko 1300 Ko 850 Ko 860338 -4 3600 Ko 1700 Ko 1100 Ko 846899 -5 4400 Ko 2100 Ko 1350 Ko 845160 -6 5200 Ko 2500 Ko 1600 Ko 838626 -7 6100 Ko 2900 Ko 1850 Ko 834096 -8 6800 Ko 3300 Ko 2100 Ko 828642 -9 7600 Ko 3700 Ko 2350 Ko 828642

bzip2 compresse les fichiers en blocs, habituellement longs de 900 Ko. Chaque bloc est traité indépendamment. Si un défaut du support physique ou une erreur de transmission endommage un fichier .bz2 multi−blocs, il peut être possible de récupérer des données à partir des blocs non endommagés du fichier.

La représentation compactée de chaque bloc est délimitée par un motif de 48 bits, ce qui permet de trouver les limites des blocs avec une probabilité raisonnable. Chaque bloc comporte également son propre CRC 32 bits, de sorte que les blocs corrompus peuvent être distingués des autres.

bzip2recover est un programme simple dont le but est de rechercher des blocs dans les fichiers .bz2, et d’écrire chaque bloc détecté dans son propre fichier .bz2. Vous pouvez alors utiliser bzip2 −t pour tester l’intégrité des fichiers résultants, et décompacter ceux qui ne sont pas endommagés.

bzip2recover prend un seul argument, le nom du fichier endommagé, et écrit un certain nombre de fichiers « rec0001file.bz2 », « rec0002file.bz2 », etc., contenant les blocs extraits. Les noms de fichiers en sortie sont choisis de sorte que l’utilisation de jokers dans des traitements ultérieurs -- par exemple, « bzip2 -dc rec*file.bz2 > données-récupérées » -- traite les fichiers dans le bon ordre.

bzip2recover devrait être principalement utilisé pour traiter les grands fichiers .bz2, puisque ceux−ci contiennent de nombreux blocs. Il est clairement futile d’essayer de l’utiliser sur des fichiers endommagés d’un seul bloc, car un seul bloc endommagé ne peut être récupéré. Si vous voulez minimiser toute perte potentielle de données à cause d’erreurs de transmission, vous devriez envisager d’utiliser une taille de bloc plus petite.

La phase de tri de la compression réunit les chaînes de caractères similaires présentes dans le fichier. De ce fait, les fichiers contenant de très longues suites de symboles répétés, comme « aabaabaabaab ... » (répétés plusieurs centaines de fois) peuvent être compactés plus lentement que la normale. Les versions 0.9.5 et ultérieures se conduisent nettement mieux que les versions précédentes de ce point de vue. Le rapport entre le temps de compression dans le pire des cas et dans le cas moyen est de l’ordre de 10 pour 1. Dans les versions antérieures, il était de 100 pour 1. Vous pouvez utiliser l’option −vvvv pour constater la progression dans les détails si vous le souhaitez.

La vitesse de décompression n’est pas affectée par ces phénomènes.

bzip2 alloue d’habitude plusieurs Mo de mémoire pour ses besoins, et ensuite charge le tout d’une manière assez aléatoire. Cela signifie que les performances, à la fois pour la compression et la décompression, sont largement déterminées par la vitesse à laquelle votre machine peut traiter les défauts de cache. De ce fait, de petites modifications au code pour réduire le taux d’échec en cache ont donné des améliorations de performance disproportionnées. J’imagine que bzip2 fonctionnera le mieux sur des machines possédant de très gros caches.

Les messages d’erreur d’E/S ne sont pas d’une grande utilité. bzip2 essaie vraiment de détecter les erreurs d’E/S et de s’arrêter proprement, mais les détails du problème rencontré peuvent parfois l’induire en erreur.

Cette page de manuel se rapporte à la version 1.0.2 de bzip2. Les données compactées créées par cette version sont entièrement compatibles en avant et en arrière avec les versions publiques précédentes 0.1pl2, 0.9.0, 0.9.5, 1.0.0 et 1.0.1 à l’exception près que les versions 0.9.0 et supérieures peuvent correctement décompacter de multiples fichiers compactés et concaténés, ce qui n’est pas le cas de la version 0.1pl2 ; celle-ci s’arrêtera après la décompression du premier fichier du flux.

Les versions de bzip2recover antérieures à celle-ci (1.0.2), utilisaient des entiers 32 bits pour représenter les positions des bits dans les fichiers compactés, et ne pouvaient donc pas traiter de fichiers compactés de plus de 512 Mo. Les versions 1.0.2 et ultérieures utilisent des entiers 64 bits sur certaines plate-formes qui en disposent (cibles supportées par GNU, et Windows). Pour établir si bzip2recover a été construit avec ou sans cette limitation, exécutez-le sans argument. Dans tous les cas, vous pouvez reconstruire une version non limitée si vous pouvez le recompiler avec MaybeUInt64 défini comme un entier 64 bits non signé.

Julian Seward, jseward@acm.org.

http://sources.redhat.com/bzip2

Les idées intégrées à bzip2 sont dues (entre autres) aux personnes suivantes : Michael Burrows et David Wheeler (pour la transformation par tri de blocs), David Wheeler (à nouveau, pour le codeur Huffman), Peter Fenwick (pour le modèle de codage structuré du bzip original, et pour de nombreux raffinements), et Alistair Moffat, Radford Neal et Ian Witten (pour le codeur arithmétique du bzip original). Je leur suis très redevable pour leur aide, leur soutien et leurs conseils. Voyez le manuel dans la distribution des sources pour obtenir des liens vers les sources de documentation. Christian von Roques m’encouragea à rechercher des algorithmes de tri plus rapides, afin d’accélérer la compression. Bela Lubkin m’encouragea à améliorer la performance de la compression dans le pire des cas. Les scripts bz* sont dérivés de ceux de GNU gzip. Beaucoup de personnes m’ont envoyé des correctifs, aidé pour des problèmes de portabilité, prêté des machines, donné des conseils et généralement été utiles.

Frédéric Delanoy <delanoy_f at yahoo.com>, 2002.