Handbücher für die Kommandozeile

Man » bzip2-Handbuch online - detaillierte Online-Dokumentation für die bzip2-Manpage

🌍
bzip2, bunzip2 - ein Block-sortierender Dateikompressor, v1.0.8
bzcat - dekomprimiert Dateien nach stdout
bzip2recover - stellt Daten aus beschädigten bzip2-Dateien wieder her

SYNTAX

bzip2 [ -cdfkqstvzVL123456789 ] [ Dateinamen ... ]
bzip2 [ -h|--help ]
bunzip2 [ -fkvsVL ] [ Dateinamen ... ]
bunzip2 [ -h|--help ]
bzcat [ -s ] [ Dateinamen ... ]
bzcat [ -h|--help ]
bzip2recover Dateiname

BESCHREIBUNG

bzip2 komprimiert Dateien mit dem Burrows-Wheeler-Block-Sortieralgorithmus für Textkomprimierung und Huffman-Kodierung. Die Komprimierung ist im Allgemeinen deutlich besser als die von herkömmlichen LZ77/LZ78-basierten Kompressoren erzielte und nähert sich der Leistung der PPM-Familie statistischer Kompressoren.

Die Befehlszeilenoptionen sind absichtlich sehr ähnlich denen von GNU gzip, aber sie sind nicht identisch.

bzip2 erwartet eine Liste von Dateinamen, die den Befehlszeilenflags beigefügt werden. Jede Datei wird durch eine komprimierte Version von sich selbst ersetzt, mit dem Namen "ursprünglicher_Name.bz2". Jede komprimierte Datei hat dasselbe Änderungsdatum, dieselben Berechtigungen und, wann immer möglich, dieselben Eigentumsrechte wie die entsprechende Originaldatei, so dass diese Eigenschaften bei der Dekomprimierung korrekt wiederhergestellt werden können. Die Dateinamenbehandlung ist naiv in dem Sinne, dass es keinen Mechanismus gibt, um ursprüngliche Dateinamen, Berechtigungen, Eigentumsrechte oder Daten in Dateisystemen zu erhalten, denen diese Konzepte fehlen oder die erhebliche Dateinamenlängenbeschränkungen aufweisen, wie z. B. MS-DOS.

bzip2 und bunzip2 überschreiben standardmäßig keine vorhandenen Dateien. Wenn dies geschehen soll, geben Sie das Flag -f an.

Wenn keine Dateinamen angegeben werden, komprimiert bzip2 von der Standardeingabe in die Standardausgabe. In diesem Fall wird bzip2 keine komprimierte Ausgabe in ein Terminal schreiben, da dies völlig unverständlich und daher sinnlos wäre.

bunzip2 (oder bzip2 -d) dekomprimiert alle angegebenen Dateien. Dateien, die nicht mit bzip2 erstellt wurden, werden erkannt und ignoriert, und es wird eine Warnung ausgegeben. bzip2 versucht, den Dateinamen für die dekomprimierte Datei aus dem der komprimierten Datei wie folgt zu erraten:

Dateiname.bz2 wird zu Dateiname
Dateiname.bz wird zu Dateiname
Dateiname.tbz2 wird zu Dateiname.tar
Dateiname.tbz wird zu Dateiname.tar
andererName wird zu andererName.out

Wenn die Datei nicht mit einer der bekannten Endungen .bz2, .bz, .tbz2 oder .tbz endet, beschwert sich bzip2, dass es den Namen der ursprünglichen Datei nicht erraten kann, und verwendet den ursprünglichen Namen mit .out angehängt.

Wie bei der Komprimierung führt die Angabe keiner Dateinamen dazu, dass von der Standardeingabe in die Standardausgabe dekomprimiert wird.


bunzip2 wird eine Datei korrekt dekomprimieren, die eine Verkettung von zwei oder mehr komprimierten Dateien ist. Das Ergebnis ist die Verkettung der entsprechenden dekomprimierten Dateien. Die Integritätsprüfung (-t) von verketteten komprimierten Dateien wird ebenfalls unterstützt.

Sie können Dateien auch in die Standardausgabe komprimieren oder dekomprimieren, indem Sie die -c-Option angeben. Mehrere Dateien können auf diese Weise komprimiert und dekomprimiert werden. Die resultierenden Ausgaben werden nacheinander an stdout weitergeleitet. Das Komprimieren mehrerer Dateien auf diese Weise erzeugt einen Datenstrom, der mehrere komprimierte Dateidarte enthält. Ein solcher Datenstrom kann nur mit bzip2 Version 0.9.0 oder höher korrekt dekomprimiert werden. Ältere Versionen von bzip2 stoppen nach dem Dekomprimieren der ersten Datei im Datenstrom.

bzcat (oder bzip2 -dc) dekomprimiert alle angegebenen Dateien in die Standardausgabe.

bzip2 liest Argumente aus den Umgebungsvariablen BZIP2 und BZIP, in dieser Reihenfolge, und verarbeitet diese, bevor Argumente von der Befehlszeile gelesen werden. Dies bietet eine praktische Möglichkeit, Standardargumente anzugeben.

Die Komprimierung wird immer durchgeführt, auch wenn die komprimierte Datei etwas größer als die ursprüngliche Datei ist. Dateien mit weniger als etwa hundert Bytes werden in der Regel größer, da der Komprimierungsmechanismus einen konstanten Overhead von etwa 50 Bytes aufweist. Zufällige Daten (einschließlich der Ausgabe der meisten Dateikomprimierungsprogramme) werden mit etwa 8,05 Bits pro Byte codiert, was einer Expansion von etwa 0,5 % entspricht.

Als Selbstkontrolle verwendet bzip2 32-Bit-CRCs, um sicherzustellen, dass die dekomprimierte Version einer Datei mit dem Original identisch ist. Dies schützt vor Beschädigung der komprimierten Daten und vor unentdeckten Fehlern in bzip2 (hoffentlich sehr unwahrscheinlich). Die Wahrscheinlichkeit, dass Datenbeschädigung unentdeckt bleibt, ist mikroskopisch klein, etwa eine Chance von vier Milliarden für jede verarbeitete Datei. Beachten Sie jedoch, dass die Prüfung bei der Dekomprimierung erfolgt, so dass sie nur feststellen kann, ob etwas nicht stimmt. Sie kann Ihnen nicht helfen, die ursprünglichen, unkomprimierten Daten wiederherzustellen. Sie können bzip2recover verwenden, um zu versuchen, Daten aus beschädigten Dateien wiederherzustellen.

Rückgabewerte: 0 für einen normalen Beendigung, 1 für Umgebungsprobleme (Datei nicht gefunden, ungültige Flags, E/A-Fehler usw.), 2, um eine beschädigte komprimierte Datei anzuzeigen, 3 für einen internen Konsistenzfehler (z. B. einen Fehler), der dazu führte, dass bzip2 einen Fehler erzeugte.

OPTIONEN

-c --stdout

Komprimieren oder dekomprimieren in die Standardausgabe.

-d --decompress

Erzwingt die Dekomprimierung. bzip2, bunzip2 und bzcat sind im Wesentlichen dasselbe Programm, und die Entscheidung darüber, welche Aktionen ausgeführt werden sollen, wird auf der Grundlage des verwendeten Namens getroffen. Dieses Flag setzt diesen Mechanismus außer Kraft und zwingt bzip2 zur Dekomprimierung.

-z --compress

Das Gegenstück zu -d: Erzwingt die Komprimierung, unabhängig vom Aufrufnamen.

-t --test

Überprüfen Sie die Integrität der angegebenen Datei(en), ohne sie zu dekomprimieren. Dies führt tatsächlich eine Testdekomprimierung durch und verwirft das Ergebnis.


-f --force

Überschreibt Ausgabedateien, falls diese bereits existieren. Normalerweise überschreibt bzip2 keine vorhandenen Ausgabedateien. Erzwingt außerdem, dass bzip2 symbolische Links zu Dateien aufhebt, was es normalerweise nicht tut.

Normalerweise lehnt bzip2 das Dekomprimieren von Dateien ab, die nicht die korrekten Magic-Header-Bytes enthalten. Wenn jedoch die Option -f (Force) verwendet wird, werden solche Dateien unverändert weitergeleitet. So verhält sich GNU gzip.

-k --keep

Behält die Eingabedateien während der Komprimierung oder Dekomprimierung bei (löscht sie nicht).

-s --small

Reduziert den Speicherbedarf für die Komprimierung, Dekomprimierung und das Testen. Dateien werden mit einem modifizierten Algorithmus dekomprimiert und getestet, der nur 2,5 Bytes pro Block-Byte benötigt. Dies bedeutet, dass jede Datei mit 2300 KB Speicher dekomprimiert werden kann, wenn auch mit etwa der halben normalen Geschwindigkeit.

Während der Komprimierung wählt -s eine Blockgröße von 200 KB, was den Speicherbedarf auf etwa die gleiche Größe begrenzt, jedoch auf Kosten der Komprimierungsrate. Kurz gesagt, wenn Ihr Computer wenig Speicher hat (8 MB oder weniger), verwenden Sie -s für alles. Siehe MEMORY MANAGEMENT unten.

-q --quiet

Unterdrückt nicht unbedingt benötigte Warnmeldungen. Meldungen über E/A-Fehler und andere kritische Ereignisse werden nicht unterdrückt.

-v --verbose

Verbose-Modus: Zeigt das Komprimierungsverhältnis für jede verarbeitete Datei an. Weitere -v-Optionen erhöhen die Ausführlichkeitsstufe und geben viele Informationen aus, die hauptsächlich für Diagnosezwecke von Interesse sind.

-h --help

Gibt eine Hilfemeldung aus und beendet das Programm.

-L --license -V --version

Zeigt die Softwareversion, die Lizenzbedingungen an.

-1 (oder --fast) bis -9 (oder --best)

Legt die Blockgröße beim Komprimieren auf 100 KB, 200 KB ... 900 KB fest. Hat beim Dekomprimieren keine Auswirkungen. Siehe MEMORY MANAGEMENT unten. Die Aliase --fast und --best dienen hauptsächlich der Kompatibilität mit GNU gzip. Insbesondere macht --fast die Sache nicht wesentlich schneller, und --best wählt lediglich das Standardverhalten aus.

-- Behandelt alle nachfolgenden Argumente als Dateinamen, auch wenn sie mit einem Bindestrich beginnen. Auf diese Weise können Sie Dateien mit Namen verarbeiten, die mit einem Bindestrich beginnen, z. B.: bzip2 -- -myfilename.

--repetitive-fast --repetitive-best

Diese Flags sind in Versionen 0.9.5 und höher überflüssig. Sie ermöglichten in früheren Versionen eine gewisse grobe Steuerung des Verhaltens des Sortieralgorithmus, was manchmal nützlich war. Versionen 0.9.5 und höher verfügen über einen verbesserten Algorithmus, der diese Flags irrelevant macht.

MEMORY MANAGEMENT

bzip2 komprimiert große Dateien in Blöcken. Die Blockgröße beeinflusst sowohl das erzielte Komprimierungsverhältnis als auch den für die Komprimierung und Dekomprimierung benötigten Speicher. Die Flags -1 bis -9 geben die Blockgröße auf 100.000 Byte bis 900.000 Byte an (Standard). Beim Dekomprimieren wird die für die Komprimierung verwendete Blockgröße aus dem Header der komprimierten Datei gelesen, und bunzip2 reserviert dann nur so viel Speicher, wie zum Dekomprimieren der Datei benötigt wird. Da Blockgrößen in komprimierten Dateien gespeichert werden, folgt daraus, dass die Flags -1 bis -9 beim Dekomprimieren irrelevant sind und daher ignoriert werden.

Die Anforderungen an Komprimierung und Dekomprimierung in Bytes können wie folgt geschätzt werden:

Komprimierung: 400 k + (8 x Blockgröße)

Dekomprimierung: 100 k + (4 x Blockgröße) oder
100 k + (2,5 x Blockgröße)

Größere Blockgrößen führen zu schnell abnehmenden Grenzerträgen. Der Großteil der Komprimierung erfolgt durch die ersten zwei oder drei hundert k der Blockgröße, was bei der Verwendung von bzip2 auf kleinen Maschinen zu berücksichtigen ist. Es ist auch wichtig zu verstehen, dass die Speicheranforderung für die Dekomprimierung während der Komprimierung durch die Wahl der Blockgröße festgelegt wird.

Für mit der Standardblockgröße von 900 k komprimierte Dateien benötigt bunzip2 etwa 3700 k, um sie zu dekomprimieren. Um die Dekomprimierung jeder Datei auf einer Maschine mit 4 Megabyte Speicher zu unterstützen, verfügt bunzip2 über eine Option, um die Dekomprimierung mit etwa der Hälfte dieser Speichermenge, etwa 2300 k, durchzuführen. Die Dekomprimierungsgeschwindigkeit wird ebenfalls halbiert, sodass Sie diese Option nur dann verwenden sollten, wenn es unbedingt erforderlich ist. Das entsprechende Flag ist -s.

Versuchen Sie im Allgemeinen, die größte Blockgröße zu verwenden, die Ihre Speicherbeschränkungen zulassen, da dies die erzielte Komprimierung maximiert. Komprimierungs- und Dekomprimierungsgeschwindigkeit werden von der Blockgröße kaum beeinflusst.

Ein weiterer wichtiger Punkt gilt für Dateien, die in einen einzigen Block passen – das bedeutet die meisten Dateien, die Sie bei Verwendung einer großen Blockgröße verarbeiten würden. Die tatsächlich verwendete Speichermenge ist proportional zur Größe der Datei, da die Datei kleiner als ein Block ist. Beispielsweise wird beim Komprimieren einer Datei mit einer Größe von 20000 Byte mit dem Flag -9 der Komprimierer etwa 7600 k Speicher zuweisen, aber nur 400 k + 20000 * 8 = 560 k davon tatsächlich verwenden. In ähnlicher Weise weist der Dekomprimierer 3700 k zu, verwendet aber nur 100 k + 20000 * 4 = 180 k.

Hier ist eine Tabelle, die die maximale Speichernutzung für verschiedene Blockgrößen zusammenfasst. Außerdem wird die gesamte komprimierte Größe für 14 Dateien des Calgary Text Compression Corpus mit einer Gesamtgröße von 3.141.622 Byte angegeben. Diese Spalte gibt einen Anhaltspunkt dafür, wie die Komprimierung mit der Blockgröße variiert. Diese Zahlen neigen dazu, den Vorteil größerer Blockgrößen für größere Dateien zu unterschätzen, da das Corpus hauptsächlich aus kleineren Dateien besteht.

Komprimieren Dekomprimieren Dekomprimieren Corpus Flag Nutzung Nutzung -s Nutzung Größe

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

DATEN AUS BESCHÄDIGTEN DATEIEN WIEDERHERSTELLEN

bzip2 komprimiert Dateien in Blöcken, üblicherweise 900 k groß. Jeder Block wird unabhängig voneinander verarbeitet.

Wenn ein Medien- oder Übertragungsfehler dazu führt, dass eine mehrblockige .bz2-Datei beschädigt wird, ist es möglicherweise möglich, Daten aus den unbeschädigten Blöcken in der Datei wiederherzustellen.


Die komprimierte Darstellung jedes Blocks wird durch ein 48-Bit-Muster begrenzt, wodurch es möglich ist, die Blockgrenzen mit angemessener Sicherheit zu finden. Jeder Block enthält auch eine eigene 32-Bit-CRC, so dass beschädigte Blöcke von unbeschädigten Blöcken unterschieden werden können.

bzip2recover ist ein einfaches Programm, dessen Zweck darin besteht, Blöcke in .bz2-Dateien zu suchen und jeden Block in eine eigene .bz2-Datei zu schreiben. Sie können dann bzip2 -t verwenden, um die Integrität der resultierenden Dateien zu testen und die unbeschädigten Dateien zu dekomprimieren.

bzip2recover akzeptiert ein einzelnes Argument, den Namen der beschädigten Datei, und schreibt eine Reihe von Dateien "rec00001file.bz2", "rec00002file.bz2" usw., die die extrahierten Blöcke enthalten. Die Ausgabedatei-Namen sind so konzipiert, dass die Verwendung von Wildcards in der nachfolgenden Verarbeitung – zum Beispiel "bzip2 -dc rec*file.bz2 > recovered_data" – die Dateien in der richtigen Reihenfolge verarbeitet.

bzip2recover ist am nützlichsten für große .bz2-Dateien, da diese viele Blöcke enthalten. Es ist offensichtlich sinnlos, es bei beschädigten Einzelblockdateien zu verwenden, da ein beschädigter Block nicht wiederhergestellt werden kann. Wenn Sie potenzielle Datenverluste durch Medien- oder Übertragungsfehler minimieren möchten, sollten Sie in Erwägung ziehen, mit einer kleineren Blockgröße zu komprimieren.

LEISTUNGSHINWEISE

Die Sortierphase der Komprimierung fasst ähnliche Zeichenketten in der Datei zusammen. Aus diesem Grund können Dateien, die sehr lange Wiederholungen von Symbolen enthalten, wie z. B. "aabaabaabaab ..." (wiederholt mehrere Hundert Male), langsamer komprimiert werden als normal. Versionen 0.9.5 und höher funktionieren in dieser Hinsicht viel besser als frühere Versionen. Das Verhältnis zwischen der schlimmsten und der durchschnittlichen Komprimierungszeit liegt in der Größenordnung von 10:1. Für frühere Versionen war diese Zahl eher 100:1. Sie können die Option -vvvv verwenden, um den Fortschritt im Detail zu überwachen, falls Sie dies wünschen.

Die Dekomprimierungsgeschwindigkeit wird durch diese Phänomene nicht beeinflusst.

bzip2 reserviert normalerweise mehrere Megabyte Speicher und greift dann auf diesen in ziemlich zufälliger Weise zu. Das bedeutet, dass die Leistung sowohl beim Komprimieren als auch beim Dekomprimieren weitgehend durch die Geschwindigkeit bestimmt wird, mit der Ihr Computer Cache-Fehler bedienen kann. Aus diesem Grund hat sich gezeigt, dass kleine Änderungen am Code, um die Anzahl der Cache-Fehler zu reduzieren, unverhältnismäßig große Leistungssteigerungen bewirken. Ich stelle mir vor, dass bzip2 auf Maschinen mit sehr großen Caches am besten funktioniert.

HINWEISE

I/O-Fehlermeldungen sind nicht so hilfreich, wie sie sein könnten. bzip2 versucht, I/O-Fehler zu erkennen und sauber zu beenden, aber die Details des Problems scheinen manchmal recht irreführend.

Diese Handbuchseite bezieht sich auf Version 1.0.8 von bzip2. Komprimierte Daten, die von dieser Version erstellt wurden, sind vollständig vorwärts- und rückwärtskompatibel mit den vorherigen öffentlichen Versionen, Versionen 0.1pl2, 9.0, 0.9.5, 1.0.0, 1.0.1, 1.0.2 und höher, mit der folgenden Ausnahme: 0.9.0 und höher können mehrere verkettete komprimierte Dateien korrekt dekomprimieren. 0.1pl2 kann dies nicht; es stoppt nach der Dekomprimierung nur der ersten Datei im Stream.


    bzip2recover-Versionen vor 1.0.2 verwendeten 32-Bit-Ganzzahlen, um Bitpositionen in komprimierten Dateien darzustellen, sodass sie keine komprimierten Dateien mit einer Größe von mehr als 512

Megabyte verarbeiten konnten. Versionen 0.2 und höher verwenden auf einigen Plattformen, die diese unterstützen (GNU-unterstützte Ziele und Windows), 64-Bit-Ganzzahlen. Um festzustellen, ob bzip2recover mit einer solchen Einschränkung erstellt wurde, führen Sie es ohne Argumente aus. In jedem Fall können Sie selbst eine unbegrenzte Version erstellen, wenn Sie es mit MaybeUInt64 neu kompilieren können, sodass es eine vorzeichenlose 64-Bit-Ganzzahl ist.

AUTOR

Julian Seward, _.

    https://sourceware.org/bzip2/

Die in bzip2 enthaltenen Ideen sind (zumindest) den folgenden Personen zu verdanken: Michael Burrows und David Wheeler (für die Block-Sortier-Transformation), David Wheeler (erneut für den Huffman-Coder), Peter Fenwick (für das strukturierte Codierungsmodell im ursprünglichen bzip und viele Verbesserungen) und Alistair Moffat, Radford Neal und Ian Witten (für den arithmetischen Coder im ursprünglichen bzip). Ich bin ihnen für ihre Hilfe, Unterstützung und Ratschläge sehr dankbar. Sehen Sie im Handbuch in der Quellverteilung nach Hinweisen auf Dokumentationsquellen. Christian von Roques ermutigte mich, nach schnelleren Sortieralgorithmen zu suchen, um die Komprimierung zu beschleunigen. Bela Lubkin ermutigte mich, die Worst-Case-Komprimierungsleistung zu verbessern. Donna Robinson hat die Dokumentation in XML umgewandelt. Die bz*-Skripte sind von denen von GNU gzip abgeleitet. Viele Leute haben Patches geschickt, bei Portierungsproblemen geholfen, Computer zur Verfügung gestellt, Ratschläge gegeben und waren insgesamt sehr hilfreich.