bzip2recover - stellt Daten aus beschädigten bzip2-Dateien wieder her
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
ein blocksortierender Dateikompressor
Dekomprimiert Dateien nach stdout
stellt Daten aus beschädigten bzip2-Dateien wieder her
bzip2 komprimiert Dateien mithilfe des Burrows-Wheeler-Blocksortierungs-Textkomprimierungsalgorithmus und der Huffman-Codierung. Die Komprimierung ist im Allgemeinen erheblich besser als die, die von konventionelleren Kompressoren auf LZ77/LZ78-Basis erreicht wird, und nähert sich der Leistung der PPM-Familie statistischer Kompressoren an.
Die Befehlszeilenoptionen ähneln bewusst denen von GNU gzip, sind aber nicht identisch.
bzip2 erwartet neben den Befehlszeilen-Flags eine Liste mit Dateinamen. Jede Datei wird durch eine komprimierte Version von sich selbst mit dem Namen „Originalname.bz2“ ersetzt. Jede komprimierte Datei hat dasselbe Änderungsdatum, dieselben Berechtigungen und, wenn möglich, denselben Besitz wie das entsprechende Original, sodass diese Eigenschaften zum Zeitpunkt der Dekomprimierung korrekt wiederhergestellt werden können. Die Handhabung von Dateinamen ist in dem Sinne naiv, dass es keinen Mechanismus gibt, um die ursprünglichen Dateinamen, Berechtigungen, Eigentümer oder Daten in Dateisystemen beizubehalten, in denen diese Konzepte fehlen oder in denen schwerwiegende Beschränkungen der Dateinamenlänge gelten, wie z. B. MS-DOS.
bzip2 und bunzip2 überschreiben standardmäßig keine vorhandenen Dateien. Wenn Sie möchten, dass dies geschieht, geben Sie das Flag -f an.
Wenn keine Dateinamen angegeben werden, komprimiert bzip2 von der Standardeingabe zur Standardausgabe. In diesem Fall wird bzip2 es ablehnen, komprimierte Ausgaben auf ein Terminal zu schreiben, da dies völlig unverständlich und daher sinnlos wäre.
bunzip2 (oder bzip2 -d) dekomprimiert alle angegebenen Dateien. Dateien, die nicht von bzip2 erstellt wurden, werden erkannt und ignoriert und eine Warnung ausgegeben. bzip2 versucht wie folgt, den Dateinamen der dekomprimierten Datei aus dem der komprimierten Datei zu erraten:
filename.bz2 becomes filename
filename.bz becomes filename
filename.tbz2 becomes filename.tar
filename.tbz becomes filename.tar
anyothername becomes anyothername.outWenn die Datei nicht mit einer der erkannten Endungen endet, .bz2, .bz, .tbz2 oder .tbz, bzip2 beschwert sich, dass es den Namen der Originaldatei nicht erraten kann und verwendet den Originalnamen mit angehängtem .out.
Wie bei der Komprimierung führt die Angabe ohne Dateinamen zu einer Dekomprimierung von der Standardeingabe zur Standardausgabe.
bunzip2 dekomprimiert korrekt eine Datei, bei der es sich um eine Verkettung von zwei oder mehr komprimierten Dateien handelt. Das Ergebnis ist die Verkettung der entsprechenden unkomprimierten Dateien. Integritätstests (-t) verketteter komprimierter Dateien werden ebenfalls unterstützt.
Sie können Dateien auch in die Standardausgabe komprimieren oder dekomprimieren, indem Sie das Flag -c angeben. Auf diese Weise können mehrere Dateien komprimiert und dekomprimiert werden. Die resultierenden Ausgaben werden sequentiell an stdout weitergeleitet. Durch die Komprimierung mehrerer Dateien auf diese Weise wird ein Stream generiert, der mehrere komprimierte Dateidarstellungen enthält. Ein solcher Stream kann nur von bzip2 Version 0.9.0 oder höher korrekt dekomprimiert werden. Frühere Versionen von bzip2 werden nach dem Dekomprimieren der ersten Datei im Stream angehalten.
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 sie vor allen Argumenten, die von der Befehlszeile gelesen werden. Dies bietet eine bequeme Möglichkeit, Standardargumente bereitzustellen.
Die Komprimierung wird immer durchgeführt, auch wenn die komprimierte Datei etwas größer als das Original ist. Dateien mit weniger als etwa einhundert Bytes werden tendenziell größer, da der Komprimierungsmechanismus einen konstanten Overhead im Bereich von 50 Bytes verursacht. Zufällige Daten (einschließlich der Ausgabe der meisten Dateikomprimierer) werden mit etwa 8,05 Bit pro Byte codiert, was einer Erweiterung von etwa 0,5 % entspricht.
Als Selbstprüfung zu Ihrem Schutz verwendet bzip2 32-Bit-CRCs, um sicherzustellen, dass die dekomprimierte Version einer Datei mit dem Original identisch ist. Dies schützt vor einer Beschädigung der komprimierten Daten und vor unentdeckten Fehlern in bzip2 (hoffentlich sehr unwahrscheinlich). Die Wahrscheinlichkeit, dass Datenbeschädigungen unentdeckt bleiben, ist mikroskopisch gering und beträgt etwa eins zu vier Milliarden für jede verarbeitete Datei. Beachten Sie jedoch, dass die Überprüfung bei der Dekomprimierung erfolgt und Ihnen daher nur mitgeteilt werden kann, dass etwas nicht stimmt. Es kann Ihnen nicht dabei helfen, die ursprünglichen unkomprimierten Daten wiederherzustellen. Mit bzip2recover können Sie versuchen, Daten aus beschädigten Dateien wiederherzustellen.
Rückgabewerte: 0 für einen normalen Exit, 1 für Umgebungsprobleme (Datei nicht gefunden, ungültige Flags, E/A-Fehler usw.), 2 für eine beschädigte komprimierte Datei, 3 für einen internen Konsistenzfehler (z. B. einen Fehler), der verursacht wurde bzip2 in Panik versetzen.
Zur Standardausgabe komprimieren oder dekomprimieren.
Dekompression erzwingen. bzip2, bunzip2 und bzcat sind eigentlich das gleiche Programm, und die Entscheidung darüber, welche Aktionen ausgeführt werden sollen, wird auf der Grundlage des verwendeten Namens getroffen . Dieses Flag überschreibt diesen Mechanismus und zwingt bzip2 zur Dekomprimierung.
Die Ergänzung zu -d: erzwingt die Komprimierung, unabhängig vom Aufrufnamen.
Überprüfen Sie die Integrität der angegebenen Datei(en), aber dekomprimieren Sie sie nicht. Dadurch wird tatsächlich eine Testdekomprimierung durchgeführt und das Ergebnis verworfen.
Überschreiben von Ausgabedateien erzwingen. Normalerweise überschreibt bzip2 keine vorhandenen Ausgabedateien. Zwingt bzip2 außerdem dazu, feste Links zu Dateien zu unterbrechen, was andernfalls nicht möglich wäre.
bzip2 lehnt es normalerweise ab, Dateien zu dekomprimieren, die nicht die richtigen Magic-Header-Bytes haben. Bei Erzwingung (-f) werden solche Dateien jedoch unverändert weitergeleitet. So verhält sich GNU gzip.
Eingabedateien während der Komprimierung oder Dekomprimierung behalten (nicht löschen).
Reduzieren Sie die Speichernutzung für Komprimierung, Dekomprimierung und Tests. Dateien werden mit einem modifizierten Algorithmus dekomprimiert und getestet, der nur 2,5 Bytes pro Blockbyte benötigt. Dies bedeutet, dass jede Datei in 2300 KB Speicher dekomprimiert werden kann, wenn auch mit etwa der Hälfte der normalen Geschwindigkeit.
Während der Komprimierung wählt -s eine Blockgröße von 200 KB, wodurch die Speichernutzung auf Kosten Ihres Komprimierungsverhältnisses auf ungefähr denselben Wert begrenzt wird. Kurz gesagt: Wenn Ihr Computer nur noch wenig Arbeitsspeicher hat (8 Megabyte oder weniger), verwenden Sie -s für alles. Siehe SPEICHERVERWALTUNG unten.
Unterdrücken Sie nicht wesentliche Warnmeldungen. Meldungen zu E/A-Fehlern und anderen kritischen Ereignissen werden nicht unterdrückt.
Ausführlicher Modus – zeigt das Komprimierungsverhältnis für jede verarbeitete Datei an. Darüber hinaus erhöhen -vs den Ausführlichkeitsgrad und spucken viele Informationen aus, die vor allem für Diagnosezwecke von Interesse sind.
Zeigen Sie die Softwareversion und die Lizenzbedingungen an.
Stellen Sie beim Komprimieren die Blockgröße auf 100 k, 200 k ... 900 k ein. Hat beim Dekomprimieren keine Auswirkung. Siehe SPEICHERVERWALTUNG unten. Die Aliase --fast und --best dienen in erster Linie der GNU-gzip-Kompatibilität. Insbesondere macht --fast die Dinge 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 verarbeiten, deren Namen mit einem Bindestrich beginnen, zum Beispiel: bzip2 -- -myfilename.
Diese Flags sind in den Versionen 0.9.5 und höher überflüssig. Sie ermöglichten eine grobe Kontrolle über das Verhalten des Sortieralgorithmus in früheren Versionen, was manchmal nützlich war. 0.9.5 und höher verfügen über einen verbesserten Algorithmus, der diese Flags irrelevant macht.
bzip2 komprimiert große Dateien in Blöcken. Die Blockgröße beeinflusst sowohl das erreichte Komprimierungsverhältnis als auch die für die Komprimierung und Dekomprimierung benötigte Speichermenge. Die Flags -1 bis -9 geben die Blockgröße auf 100.000 Byte bis 900.000 Byte (Standard) an. Zum Zeitpunkt der Dekomprimierung wird die für die Komprimierung verwendete Blockgröße aus dem Header der komprimierten Datei gelesen und bunzip2 reserviert sich dann gerade genug Speicher, um die Datei zu dekomprimieren. Da Blockgrößen in komprimierten Dateien gespeichert werden, sind die Flags -1 bis -9 für die Dekomprimierung irrelevant und werden daher ignoriert.
Der Komprimierungs- und Dekomprimierungsbedarf in Bytes kann wie folgt geschätzt werden:
Kompression:
400k + ( 8 x block size )
Dekompression:
100k + ( 4 x block size ), or 100k + ( 2.5 x block size )
Größere Blockgrößen führen zu schnell abnehmenden Grenzerträgen. Der größte Teil der Komprimierung kommt von den ersten zwei- oder dreihundertk der Blockgröße, eine Tatsache, die es zu beachten gilt, wenn bzip2 auf kleinen Maschinen verwendet wird. Es ist auch wichtig zu verstehen, dass der Speicherbedarf für die Dekomprimierung zum Zeitpunkt der Komprimierung durch die Wahl der Blockgröße festgelegt wird.
Für Dateien, die mit der Standardblockgröße von 900 KB komprimiert sind, benötigt bunzip2 etwa 3700 KB zum Dekomprimieren. Um die Dekomprimierung jeder Datei auf einem 4-Megabyte-Computer zu unterstützen, verfügt bunzip2 über eine Option zum Dekomprimieren mit etwa der Hälfte dieser Speichermenge, etwa 2300 KB. Auch die Dekompressionsgeschwindigkeit wird halbiert, daher sollten Sie diese Option nur bei Bedarf nutzen. Das relevante Flag ist -s.
Versuchen Sie im Allgemeinen, die größtmögliche Blockgröße zu verwenden, die die Speicherbeschränkungen zulassen, da dadurch die erreichte Komprimierung maximiert wird. Die Komprimierungs- und Dekomprimierungsgeschwindigkeit wird praktisch nicht von der Blockgröße beeinflusst.
Ein weiterer wichtiger Punkt gilt für Dateien, die in einen einzelnen Block passen – das bedeutet, dass die meisten Dateien, denen Sie begegnen würden, eine große Blockgröße verwenden. Die Menge des berührten realen Speichers ist proportional zur Größe der Datei, da die Datei kleiner als ein Block ist. Wenn Sie beispielsweise eine 20.000 Byte lange Datei mit dem Flag -9 komprimieren, reserviert der Kompressor etwa 7.600 KB Speicher, berührt aber nur 400 KB + 20.000 * 8=560 KB davon. Ebenso weist der Dekomprimierer 3700 KB zu, berührt aber nur 100 KB + 20000 * 4=180 KB.
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 von insgesamt 3.141.622 Bytes aufgezeichnet. Diese Spalte vermittelt einen Eindruck davon, 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 der Corpus von kleineren Dateien dominiert wird.
Compress Decompress Decompress Corpus
Flag usage usage -s usage Size
-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 828642bzip2 komprimiert Dateien in Blöcken, die normalerweise 900 KB lang sind. Jeder Block wird unabhängig behandelt. Wenn ein Medien- oder Übertragungsfehler dazu führt, dass eine .bz2-Datei mit mehreren Blöcken 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, was es ermöglicht, die Blockgrenzen mit angemessener Sicherheit zu finden. Jeder Block verfügt außerdem über einen eigenen 32-Bit-CRC, sodass beschädigte Blöcke von unbeschädigten unterschieden werden können.
bzip2recover ist ein einfaches Programm, dessen Zweck darin besteht, nach Blöcken in .bz2-Dateien zu suchen und jeden Block in eine eigene .bz2-Datei zu schreiben. Anschließend können Sie mit bzip2 -t die Integrität der resultierenden Dateien testen und die unbeschädigten Dateien dekomprimieren.
bzip2recover verwendet 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 Ausgabedateinamen sind so gestaltet, dass bei der Verwendung von Platzhaltern in der nachfolgenden Verarbeitung – zum Beispiel „bzip2 -dc rec*file.bz2 > wiederhergestellte_Daten“ – die Dateien in der richtigen Reihenfolge verarbeitet werden.
bzip2recover sollte vor allem bei großen .bz2-Dateien nützlich sein, da diese viele Blöcke enthalten. Es ist eindeutig 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, können Sie eine Komprimierung mit einer kleineren Blockgröße in Betracht ziehen.
In der Sortierphase der Komprimierung werden ähnliche Zeichenfolgen in der Datei zusammengefasst. Aus diesem Grund werden Dateien, die sehr lange Reihen sich wiederholender Symbole wie „aabaabaabaab ...“ (mehrere hundert Mal wiederholt) enthalten, möglicherweise langsamer als normal komprimiert. In dieser Hinsicht schneiden die Versionen 0.9.5 und höher deutlich besser ab als frühere Versionen. Das Verhältnis zwischen der Komprimierungszeit im ungünstigsten Fall und im durchschnittlichen Fall liegt im Bereich von 10:1. Bei früheren Versionen lag dieser Wert eher bei 100:1. Wenn Sie möchten, können Sie den Fortschritt mit der Option -vvvv sehr detailliert überwachen.
Die Dekompressionsgeschwindigkeit wird von diesen Phänomenen nicht beeinflusst.
bzip2 weist normalerweise mehrere Megabyte Speicher für den Betrieb zu und lädt dann den gesamten Speicher auf ziemlich zufällige Weise auf. Das bedeutet, dass die Leistung sowohl beim Komprimieren als auch beim Dekomprimieren weitgehend von der Geschwindigkeit abhängt, mit der Ihr Computer Cache-Fehler verarbeiten kann. Aus diesem Grund wurde beobachtet, dass kleine Änderungen am Code zur Reduzierung der Fehlerrate zu unverhältnismäßig großen Leistungsverbesserungen führten. Ich kann mir vorstellen, dass bzip2 auf Maschinen mit sehr großen Caches am besten funktioniert.
E/A-Fehlermeldungen sind nicht so hilfreich, wie sie sein könnten. bzip2 bemüht sich sehr, E/A-Fehler zu erkennen und sauber zu beenden, aber die Details des Problems scheinen manchmal ziemlich irreführend.
Diese Handbuchseite bezieht sich auf Version 1.0.8 von bzip2. Die von dieser Version erstellten komprimierten Daten sind vollständig auf- und abwärtskompatibel mit den vorherigen öffentlichen Versionen, Versionen 0.1pl2, 0.9.0, 0.9.5, 1.0 .0, 1.0.1, 1.0.2 und höher, jedoch 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, nachdem nur die erste Datei im Stream dekomprimiert wurde.
bzip2recover-Versionen vor 1.0.2 verwendeten 32-Bit-Ganzzahlen zur Darstellung von Bitpositionen in komprimierten Dateien, sodass sie komprimierte Dateien mit einer Länge von mehr als 512 Megabyte nicht verarbeiten konnten. Versionen 1.0.2 und höher verwenden 64-Bit-Ints auf einigen Plattformen, die sie unterstützen (von GNU unterstützte Ziele und Windows). Um festzustellen, ob bzip2recover mit einer solchen Einschränkung erstellt wurde, führen Sie es ohne Argumente aus. In jedem Fall können Sie sich eine unbegrenzte Version erstellen, wenn Sie sie neu kompilieren können, wobei MaybeUInt64 auf eine vorzeichenlose 64-Bit-Ganzzahl eingestellt ist.
Julian Seward, jseward@acm.org.
https://sourceware.org/bzip2/
Die in bzip2 verkörperten Ideen gehen (mindestens) auf die folgenden Personen zurück: Michael Burrows und David Wheeler (für die Blocksortierungstransformation), David Wheeler (wiederum für den Huffman-Codierer), Peter Fenwick ( für das strukturierte Codierungsmodell im ursprünglichen bzip und viele Verfeinerungen) und Alistair Moffat, Radford Neal und Ian Witten (für den arithmetischen Codierer im ursprünglichen bzip). I Für ihre Hilfe, Unterstützung und ihren Rat bin ich zu großem Dank verpflichtet. Hinweise auf Dokumentationsquellen finden Sie im Handbuch in der Quelldistribution. Christian von Roques ermutigte mich, nach schnelleren Sortieralgorithmen zu suchen, um die Komprimierung zu beschleunigen. Bela Lubkin ermutigte mich, die Komprimierungsleistung im ungünstigsten Fall zu verbessern. Donna Robinson hat die Dokumentation XMLisiert. Die bz*-Skripte sind von denen von GNU gzip abgeleitet. Viele Leute schickten Patches, halfen bei Portabilitätsproblemen, verliehen Maschinen, gaben Ratschläge und waren allgemein hilfsbereit.