Provided by: manpages-de_2.5-1_all 
BEZEICHNUNG
bzip2, bunzip2 - ein blocksortierender Dateikompressor, Version 1.0.6
bzcat - Dateien dekomprimieren und in die Standardausgabe leiten
bzip2recover - Daten aus beschädigten Bzip2-Dateien wiederherstellen
ÜBERSICHT
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 blocksortierenden Textkompressionsalgorithmus nach
Burrows-Wheeler und der Huffman-Kodierung. Die Kompression wird generell als besser
angesehen als mit den konventionellen LZ77/LZ78-basierenden Kompressionsalgorithmen und
kommt der Performance der PPM-Familie statistischer Kompressoren nahe.
Die Befehlszeilenoptionen sind denen von GNU gzip absichtlich sehr ähnlich, aber nicht
völlig identisch.
bzip2 erwartet eine Liste von Dateinamen, die den Befehlszeilenoptionen mitgegeben werden.
Jede Datei wird durch deren komprimierte Version mit dem Namen Originalname.bz2 ersetzt.
Dabei werden die ursprünglichen Änderungszeitstempel, Zugriffsrechte und, wenn möglich,
auch die Eigentumsrechte des zugehörigen Originals übernommen, so dass diese Eigenschaften
bei der Dekomprimierung korrekt wiederhergestellt werden können. Auf Dateisystemen, denen
diese Möglichkeiten der Erhaltung von originalen Dateinamen, Zugriffsrechten,
Eigentumsverhältnissen und Zeitstempeln fehlen oder die Länge von Dateinamen eingeschränkt
ist, wie beispielsweise MS-DOS, ist diese Verarbeitung von Dateinamen harmlos.
bzip2 und bunzip2 überschreiben in der Voreinstellung existierende Dateien. Wenn Sie dies
verhindern wollen, verwenden Sie den Schalter -f.
Werden keine Dateinamen angegeben, dann liest bzip2 aus der Standardeingabe und leitet das
Ergebnis der Komprimierung in die Standardausgabe. In diesem Fall verweigert bzip2 die
komprimierte Ausgabe in ein Terminal, da die Ausgabe unverständlich und daher sinnlos
wäre.
bunzip2 (oder bzip2 -d) dekomprimiert alle angegebenen Dateien. Werden Dateien erkannt,
die nicht mit bzip2 komprimiert sind, werden diese ignoriert und eine Warnmeldung
ausgegeben. bzip2 versucht die Namen für die dekomprimierten Dateien folgendermaßen
abzuleiten:
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
Falls die Datei nicht eine der verarbeitbaren Endungen .bz2, .bz, .tbz2 oder .tbz hat,
reklamiert bzip2, dass der Name der Originaldatei nicht ermittelt werden kann, und
verwendet den Originalnamen mit der Endung .out.
Wie bei der Kompression wird auch bei der Dekompression aus der Standardeingabe gelesen
und das Ergebnis in die Standardausgabe geleitet, wenn keine Dateinamen angegeben werden.
bunzip2 dekomprimiert eine Datei korrekt, die aus zwei oder mehr komprimierten Dateien
verkettet ist. Das Ergebnis ist eine Verkettung der entsprechenden unkomprimierten
Dateien. Die Integritätsprüfung verketteter komprimierter Dateien mit -t wird dabei auch
unterstützt.
Sie können Dateien mit dem Schalter -c auch in die Standardausgabe komprimieren oder
dekomprimieren. Auf diese Weise können mehrere Dateien verarbeitet werden. Die Ergebnisse
werden nacheinander in die Standardausgabe geleitet. Die Kompression mehrerer Dateien auf
diese Weise erzeugt einen Datenstrom, der mehrere komprimierte Dateien enthält. Ein
solcher Datenstrom kann nur mit bzip2 in Version 0.9.0 oder neuer korrekt dekomprimiert
werden. Ältere Versionen von bzip2 brechen den Vorgang nach der Dekomprimierung der ersten
Datei des Datenstroms ab.
bzcat (oder bzip2 -dc) dekomprimieren alle angegebenen Dateien in die Standardausgabe.
bzip2 liest die Argumente nacheinander aus den Umgebungsvariablen BZIP2 und BZIP. Diese
werden stets vor der Verarbeitung von Befehlszeilenargumenten ausgewertet. Dadurch
erhalten Sie eine bequeme Möglichkeit, Standardargumente zu übergeben.
Die Kompression wird immer ausgeführt, selbst wenn die komprimierte Datei etwas größer als
das Original ist. Dateien, die kleiner als 100 Bytes sind, tendieren dazu, durch die
Kompression größer zu werden, da der Kompressionsalgorithmus eine konstante Datenmenge von
etwa 50 Bytes selbst benötigt. Zufallsdaten (die in der Ausgabe der meisten
Dateikompressoren enthalten sind) werden mit 8,05 Bit pro Byte kodiert, was einem Zuwachs
von 0,5% entspricht.
Als Selbsttest zu Ihrem Schutz verwendet bzip2 32-Bit-CRC-Prüfungen, um sicherzustellen,
dass die Originaldatei und deren dekomprimierte Version identisch sind. Dies schützt vor
Beschädigung der komprimierten Daten und auch gegen noch nicht entdeckte Fehler in bzip2
(was hoffentlich unwahrscheinlich ist). Die Möglichkeit, dass die Beschädigung der Daten
unentdeckt bleibt, ist sehr gering, etwa einmal in vier Milliarden verarbeiteten Dateien.
Zu bedenken ist, dass die Prüfung bei der Dekompression ausgeführt wird und daher nur
festgestellt wird, dass ein Problem besteht. Bei der Wiederherstellung der originalen
unkomprimierten Daten hilft dies nicht. Sie können mit bzip2recover versuchen, die Daten
aus den beschädigten Dateien wiederherzustellen.
Rückgabewerte sind: 0 für ein normales Beenden, 1 für umgebungsbedingte Probleme (Datei
nicht gefunden, ungültige Argumente, Ein-/Ausgabefehler usw.), 2 verweist auf eine
beschädigte komprimierte Datei, 3 auf einen internen Konsistenzfehler (beispielsweise ein
Bug), der bzip2 zum Absturz bringt.
OPTIONEN
-c --stdout
komprimiert oder dekomprimiert in die Standardausgabe.
-d --decompress
erzwingt die Dekompression. Bei bzip2, bunzip2 und bzcat handelt es sich
tatsächlich um dasselbe Programm. Die Entscheidung über die vorzunehmenden Aktionen
geschieht auf der Basis des verwendeten Namens. Dieser Schalter setzt diesen
Mechanismus außer Kraft und erzwingt die Dekompression mit bzip2.
-z --compress
erzwingt die Kompression unabhängig vom aufgerufenen Befehlsnamen (als Ergänzung zu
-d).
-t --test
überprüft die Integrität der angegebenen Datei(en), aber dekomprimiert sie nicht.
Es wird lediglich ein Kompressionsversuch ausgeführt und das Ergebnis ausgegeben.
-f --force
erzwingt das Überschreiben der Ausgabedateien. Normalerweise überschreibt bzip2
vorhandene Ausgabedateien nicht. Außerdem überschreibt bzip2 mit dieser Option
harte Verknüpfungen zu Dateien, was normalerweise nicht geschehen würde.
bzip2 verweigert normalerweise die Dekomprimierung von Dateien, denen die korrekten
»magischen« Dateikopf-Bytes fehlen. Falls die Dekomprimierung mit -f erzwungen
wird, werden solche Dateien unverändert übergangen. Dies entspricht dem Verhalten
von GNU gzip.
-k --keep
behält (löscht keine) Eingabedateien während der Komprimierung oder
Dekomprimierung.
-s --small
verringert den Speicherbedarf für Kompression, Dekompression und Tests. Dateien
werden mit einem modifizierten Algorithmus dekomprimiert und getestet, der
lediglich 2,5 Bytes pro Block-Byte erfordert. Das bedeutet, dass für die
Dekomprimierung einer Datei nie mehr als 2300 kB Speicher erforderlich sind,
wenngleich dies dann nur mit der Hälfte der normalen Geschwindigkeit geschieht.
Während der Komprimierung wählt die Option -s eine Blockgröße von 200 kB, was den
Speicherverbrauch auf etwa diese Größe begrenzt. Das geht allerdings zu Lasten des
Kompressionsverhältnisses. Kurz gesagt, wenn Ihr Rechner über wenig Speicher
verfügt (8 Megabyte oder weniger), sollten Sie stets die Option -s verwenden. Siehe
SPEICHERVERWALTUNG unten.
-q --quiet
unterdrückt Warnmeldungen, sofern diese nicht von grundlegender Bedeutung sind.
Meldungen zu Ein-/Ausgabefehlern sowie weiteren kritischen Ereignissen werden
weiterhin angezeigt.
-v --verbose
aktiviert den ausführlichen Modus. Dabei werden die Kompressionsraten für jede
verarbeitete Datei angezeigt. Wird diese Option mehrmals angegeben, erhöht sich
damit die Menge der ausgegebenen Informationen. Dies ist primär für Diagnosezwecke
gedacht.
-h --help
gibt eine Hilfe aus und beendet das Programm.
-L --license -V --version
zeigt die Softwareversion und die Lizenzbedingungen an.
-1 (oder --fast) bis -9 (oder --best)
setzt bei der Komprimierung die Blockgröße auf 100 kB, 200 kB … 900 kB. Dies ist
bei der Dekomprimierung wirkungslos. Siehe SPEICHERVERWALTUNG unten. Die Aliase
--fast und --best dienen nur der Kompatibilität zu GNU gzip. Insbesondere --fast
sorgt nicht wirklich für einen Geschwindigkeitszuwachs, und --best wählt lediglich
das Standardverhalten.
-- fasst alle nachfolgenden Argumente als Dateinamen auf, selbst dann, wenn sie mit
einem Minuszeichen beginnen. Dadurch können Sie beispielsweise »bzip2 --
-meinedatei« verarbeiten lassen.
--repetitive-fast --repetitive-best
Diese Schalter sind in den Versionen ab 0.9.5 überflüssig. Sie ermöglichten in
früheren Versionen eine grobe Beeinflussung des Verhaltens des Sortieralgorithmus,
was gelegentlich durchaus sinnvoll war. Für den verbesserten Algorithmus in den
Versionen nach 0.9.5 sind diese Schalter irrelevant.
SPEICHERVERWALTUNG
bzip2 komprimiert große Dateien blockweise. Die Größe der Blöcke beeinflusst sowohl das
erreichte Kompressionsverhältnis als auch den Speicherbedarf für Kompression und
Dekompression. Die Schalter -1 bis -9 geben die Blockgröße von 100000 bis 900000 Bytes an
(Letzteres ist die Voreinstellung). Bei der Dekompression wird die für die Kompression
verwendete Blockgröße aus dem Dateikopf der komprimierten Datei ermittelt. Aus diesem Wert
leitet bunzip2 selbst den für die Dekompression erforderlichen Speicherbedarf ab. Da die
Blockgrößen in den komprimierten Dateien selbst gespeichert werden, sind die Schalter -1
bis -9 bei der Dekompression nicht von Bedeutung und werden daher ignoriert.
Die Erfordernisse zur Kompression und Dekompression können folgendermaßen abgeschätzt
werden (in Bytes):
Kompression: 400 k + ( 8 x Blockgröße )
Dekompression: 100 k + ( 4 x Blockgröße ) oder
100 k + ( 2.5 x Blockgröße )
Größere Blöcke bringen nur geringfügig bessere Ergebnisse. Die effektivste Kompression
ergibt sich aus den ersten 200 bis 300 kB der Blockgröße, dies sollte beachtet werden,
wenn bzip2 auf weniger leistungsfähigen Rechnern verwendet wird. Ebenfalls beachtet
werden sollte, dass der Speicherbedarf für die Dekompression schon durch die bei der
Kompression gewählte Blockgröße bestimmt wird.
Bei Dateien, die mit den voreingestellten 900 kB großen Blöcken komprimiert sind, benötigt
bunzip2 etwa 3700 kB für die Dekompression. Um die Dekompression auch auf Rechnern mit 4
MB Speicher zu ermöglichen, steht eine Option für bunzip2 zur Verfügung, die den
Speicherbedarf auf 2300 kB nahezu halbiert, was allerdings auch eine Halbierung der
Dekompressionsgeschwindigkeit nach sich zieht. Sie sollten den dafür zuständigen Schalter
-s daher nur verwenden, wenn dies wirklich nötig ist.
Generell sollten Sie stets versuchen, die größtmöglichen Blöcke zu verwenden, die der zur
Verfügung stehende Speicher zulässt. Dadurch wird das maximale Kompressionsverhältnis
erreicht. Die Kompressions- und Dekompressionsgeschwindigkeiten werden durch die
Blockgröße praktisch nicht beeinflusst.
Ein weiterer wichtiger Punkt betrifft Dateien, die in einen einzigen Block passen – also
wohl die meisten Dateien, wenn Sie eine große Blockgröße wählen. Die Größe des
tatsächlichen Speichers ist proportional zur Dateigröße, da die Datei kleiner als ein
Block ist. Beispielsweise werden durch die Kompression einer 20000 Byte großen Datei mit
dem Schalter -9 rund 7600 kB Speicher belegt, aber tatsächlich nur 400 k + 20000 * 8 = 560
kB davon genutzt. Auf ähnliche Weise belegt die Dekomprimierung 3700 kB, nutzt aber nur
100 k + 20000 * 4 = 180 kB.
Die folgende Tabelle fasst den maximalen Speicherbedarf für die jeweilige Blockgröße
zusammen. Außerdem wird die komprimierte Gesamtgröße der 14 Dateien des »Calgary Text
Compression Corpus« angezeigt, die sich auf 3141622 Bytes beläuft. Diese Spalte vermittelt
einen Eindruck, wie die Kompression mit der Blockgröße variiert. Diese Zahlen verleiten
allerdings dazu, den Vorteil größerer Blöcke für größere Dateien zu unterschätzen, da der
Corpus durch kleinere Dateien dominiert wird.
Kompres- Dekompres- Decompres- Corpus-
Schalter sion sion sion mit -s Größe
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642
DATEN AUS BESCHÄDIGTEN DATEIEN WIEDERHERSTELLEN
bzip2 komprimiert Dateien in Blöcken, wobei jeder Block üblicherweise 900 kB groß ist. Die
Blöcke werden unabhängig voneinander verarbeitet. Falls ein Medien- oder
Übertragungsfehler dazu führt, dass eine aus mehreren Blöcken bestehende .bz2-Datei
beschädigt wird, kann es dennoch gelingen, die Daten der unbeschädigten Blöcke
wiederherzustellen.
Der komprimierten Darstellung jedes Blocks ist ein 48-Bit-Muster überlagert, was die
Erkennung der Blockgrenzen mit hinreichender Sicherheit ermöglicht. Jeder Block enthält
außerdem seine eigene 32-Bit-CRC-Prüfsumme, so dass beschädigte Blöcke von unbeschädigten
Blöcken unterschieden werden können.
Mit bzip2recover können Sie nach Blöcken in .bz2-Dateien suchen und jeden Block in einer
eigenen .bz2-Datei speichern. Dann können Sie mit bzip2 die Integrität dieser Dateien
prüfen und sie dekomprimieren, sofern sie unbeschädigt sind.
bzip2recover akzeptiert ein einzelnes Argument, den Namen der beschädigten Datei, und
schreibt eine Reihe von Dateien nach dem Namensschema rec00001file.bz2, rec00002file.bz2
usw., welche die dekomprimierten Blöcke enthalten. Die Namen der Ausgabedateien sind so
gestaltet, dass durch Verwendung von Platzhaltern bei der Weiterverarbeitung – zum
Beispiel »bzip2 -dc rec*file.bz2 > reparierte_Daten« – die Dateien in der richtigen
Reihenfolge bearbeitet werden.
bzip2recover wird am häufigsten bei großen .bz2-Dateien eingesetzt werden, da diese viele
Blöcke enthalten. Es ist sinnlos, es bei beschädigten Ein-Block-Dateien einzusetzen, da
ein einzelner beschädigter Block nicht wiederhergestellt werden kann. Wenn Sie den
potenziellen Datenverlust durch Medien- oder Übertragungsfehler minimieren wollen, sollten
Sie eine Verringerung der Blockgröße in Erwägung ziehen.
HIWEISE ZUR PERFORMANCE
In der Sortierphase der Kompression werden ähnliche Zeichenketten in der Datei
zusammengeführt. Aus diesem Grund werden Dateien, die sehr lange Reihen sich mehrere
Hundert Male wiederholender Symbole enthalten, wie »aabaabaabaab …«, möglicherweise
langsamer komprimiert als normal. Die Versionen 0.9.5 und neuer arbeiten in dieser
Beziehung weitaus besser. Das Verhältnis zwischen der Kompressionsdauer im ungünstigsten
Fall und dem Durchschnitt bewegt sich im Bereich von 10:1. In früheren Versionen konnte
das Verhältnis durchaus 100:1 betragen. Wenn gewünscht, können Sie mit der Option -vvvv
den Fortschritt sehr detailreich anzeigen lassen.
Die Geschwindigkeit der Dekomprimierung wird durch dieses Phänomen nicht beeinträchtigt.
bzip2 belegt üblicherweise einige Megabyte Speicher, in denen es arbeitet, und lädt dann
alles nach Bedarf nach dem Zufallsprinzip. Das heißt, dass sowohl für die Komprimierung
als auch die Dekomprimierung von entscheidender Bedeutung ist, wie schnell Ihr Rechner den
Inhalt des Zwischenspeichers verwirft. Daher können kleine Änderungen am Code zur
Reduzierung der Verwerfungsrate unverhältnismäßig große Verbesserungen der Performance
bewirken. Es ist vorstellbar, dass die Performance von bzip2 auf Rechnern mit sehr großen
Zwischenspeichern am besten ist.
EINSCHRÄNKUNGEN
Die Meldungen zu Ein-/Ausgabe-Fehlern sind nicht so hilfreich, wie sie idealerweise sein
sollten. bzip2 versucht, Ein-/Ausgabe-Fehler zu erkennen und sauber zu beenden, aber die
Details des Problems sind manchmal eher irreführend.
Diese Handbuchseite bezieht sich auf die Version 1.0.6 von bzip2. Die von dieser Version
erzeugten komprimierten Daten sind vollständig abwärts- und aufwärtskompatibel zu den
früher veröffentlichten Versionen 0.1pl2, 0.9.0, 0.9.5, 1.0.0, 1.0.1, 1.0.2 und neuer,
allerdings mit der folgenden Ausnahme: Die Versionen 0.9.0 und neuer können mehrere
verkettete komprimierte Dateien korrekt dekomprimieren. In der Version 0.1pl2 ist dies
nicht möglich, das Programm bricht nach der Dekomprimierung der ersten Datei das
Datenstroms ab.
Die Versionen von bzip2recover vor 1.0.2 verwendeten 32-Bit-Ganzzahlen zum Darstellen der
Bit-Positionen in komprimierten Dateien, daher konnte es nicht mit Dateien umgehen, die
größer ale 512 Megabytes sind. Die Versionen 1.0.2 und neuer verwenden 64-Bit-Ganzzahlen
auf jenen Plattformen, die diese unterstützen (entsprechende GNU-Versionen und Windows).
Wenn Sie bzip2recover ohne Argumente aufrufen, wird angezeigt, ob Ihre Version mit einer
solchen Einschränkung erstellt wurde. In jedem Fall können Sie sich selbst eine
uneingeschränkte Version erstellen, wenn Sie das Programm neu kompilieren und
»MaybeUInt64« dabei auf eine vorzeichenlose 64-Bit-Ganzzahl setzen.
AUTOR
Julian Seward, jsewardbzip.org.
http://www.bzip.org
Die in bzip2 umgesetzten Ideen gehen (mindestens) auf folgende Mitwirkende zurück: Michael
Burrows und David Wheeler (die blocksortierende Umwandlung), David Wheeler (der
Huffman-Encoder), Peter Fenwick (das strukturierte Benennungsschema im ursprünglichen bzip
sowie zahlreiche Verbesserungen) sowie Alistair Moffat, Radford Neal und Ian Witten (der
arithmetische Encoder im ursprünglichen bzip). Ich bin ihnen für ihre Hilfe, Unterstützung
und Beratung sehr zu Dank verpflichtet. Im Handbuch der Quelldistribution finden Sie
Hinweise zur Herkunft der Dokumentation. Christian von Roques regte mich an, nach
schnelleren Sortieralgorithmen zu suchen, die die Kompression beschleunigen. Bela Lubkin
ermunterte mich, die im ungünstigsten Fall erreichbare Performance der Kompression zu
verbessern. Donna Robinson hat die Dokumentation auf das XML-Format migriert. Die
bz*-Skripte wurden aus jenen von GNU gzip abgeleitet. Viele Leute schickten Patches,
halfen bei Problemen mit der Portabilität, stellten Hardware leihweise zur Verfügung,
standen beratend zur Seite oder waren ganz allgemein hilfreich.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Mario Blättermann
<mario.blaettermann@gmail.com> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG
übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an <debian-l10n-german@lists.debian.org>.
bzip2(1)