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