bzip2 ist eine freie und offene Quelldurchführung des Algorithmus der Baue-Wheeler. Es wird entwickelt und von Julian Seward aufrechterhalten. Seward hat die erste öffentliche Ausgabe von bzip2, Version 0.15 im Juli 1996 gemacht. Die Stabilität und Beliebtheit des Kompressors sind im Laufe der nächsten mehreren Jahre gewachsen, und Seward hat Version 1.0 gegen Ende 2000 veröffentlicht.

Wie gzip ist es nur ein Kompressor für einzelne Dateien und nicht einen vollen archiver.

Kompressionsleistungsfähigkeit

Bzip2-Kompressen Deflationieren die meisten Dateien effektiver als der ältere LZW (.Z) und (.zip und.gz) Kompressionsalgorithmen, aber ist beträchtlich langsamer. LZMA ist allgemein raumeffizienter als bzip2 auf Kosten der langsameren Kompressionsgeschwindigkeit, während er viel schneller Dekompression hat.

Bzip2-Kompresse-Daten in Blöcken der Größe zwischen 100 und 900 Kilobyte und Gebrauch die Baue-Wheeler verwandeln sich, um oft wiederkehrende Charakter-Folgen in Reihen von identischen Briefen umzuwandeln. Es gilt dann Bewegung zur Vorderseite verwandeln sich und Huffman, der codiert. Bzip2'S-Vorfahr bzip hat das Arithmetik-Codieren statt Huffmans verwendet. Die Änderung wurde wegen einer Softwarepatent-Beschränkung vorgenommen.

Bzip2-Leistung ist asymmetrisch, weil Dekompression relativ schnell ist. Motiviert durch die große für die Kompression erforderliche Zentraleinheitszeit wurde eine modifizierte Version 2003 genannt pbzip2 geschaffen, der Nebenläufigkeit unterstützt hat, fast geradlinige Geschwindigkeitsverbesserungen auf der Mehrzentraleinheit und den Mehrkerncomputern gebend., diese Funktionalität ist ins Hauptprojekt nicht vereinigt worden.

Wie gzip ist bzip2 nur ein Datenkompressor. Es ist nicht ein archiver wie RAR oder SCHWIRREN; das Programm selbst hat keine Möglichkeiten für vielfache Dateien, Verschlüsselung oder Archiv-Aufspalten, aber in der UNIX Tradition, verlässt sich stattdessen auf getrennte Außendienstprogramme wie Teer und GnuPG für diese Aufgaben.

Kompressionsstapel

Bzip2 verwendet mehrere Schichten von Kompressionstechniken aufgeschobert aufeinander, die in der folgenden Ordnung während der Kompression und der Rückordnung während der Dekompression vorkommen:

1. Verschlüsselung der Lauf-Länge (RLE): Jede Folge von 4 bis 255 Konsekutivdoppelsymbolen wird durch die ersten vier Symbole und eine mehrmalige Länge zwischen 0 und 251 ersetzt. So wird die Folge "" durch "" ersetzt. Läufe von Symbolen werden immer nach vier Konsekutivsymbolen umgestaltet, selbst wenn die Lauf-Länge auf die Null veranlasst wird, die Transformation umkehrbar zu halten. Im Grenzfall kann es eine Vergrößerung 1.25 und bester Fall die Verminderung zu verursachen
2. Baue-Wheeler verwandeln sich (BWT): Das ist die umkehrbare Block-Sorte, die am Kern von bzip2 ist. Der Block ist völlig selbst enthalten, mit dem Eingang und den Produktionspuffern, die dieselbe Größe — in bzip2 bleiben, die Betriebsgrenze für diese Bühne ist 900 Kilobytes. Für die Block-Sorte wird eine (begriffliche) Matrix geschaffen, in dem Reihe den ganzen der Puffer, rotieren gelassen enthält, um vom Symbol anzufangen. Folgende Folge, die Reihen der Matrix werden in die alphabetische (numerische) Ordnung sortiert. Ein 24-Bit-Zeigestock wird versorgt, die Startposition dafür kennzeichnend, wenn der Block unumgestaltet wird. In der Praxis ist es nicht notwendig, die volle Matrix zu bauen; eher wird die Sorte mit Zeigestöcken für jede Position im Puffer durchgeführt. Der Produktionspuffer ist die letzte Säule der Matrix; das enthält den ganzen Puffer, aber wiederbestellt, so dass er wahrscheinlich große Läufe von identischen Symbolen enthalten wird.
3. Bewegung zur Vorderseite (MTF): Wieder verwandelt sich das verändert die Größe des bearbeiteten Blocks nicht. Jedes der Symbole im Gebrauch im Dokument wird in eine Reihe gelegt. Wenn ein Symbol bearbeitet wird, wird es durch seine Position (Index) in der Reihe ersetzt, und dieses Symbol wird zur Vorderseite der Reihe hergeschoben. Die Wirkung besteht darin, dass sofort wiederkehrende Symbole durch Nullsymbole ersetzt werden (lange Läufe jedes willkürlichen Symbols werden so Läufe von Nullsymbolen), während andere Symbole gemäß ihrer lokalen Frequenz kartografisch wiederdargestellt werden. Viele "natürliche" Daten enthalten identische Symbole, die innerhalb einer beschränkten Reihe wiederkehren (Text ist ein gutes Beispiel). Da sich die MTF verwandeln, teilt niedrige Werte Symbolen zu, die oft wieder erscheinen, läuft das auf einen Datenstrom hinaus, der viele Symbole in der niedrigen Reihe der ganzen Zahl enthält, viele von ihnen identisch seiend (können verschiedene wiederkehrende Eingangssymbole wirklich zu demselben Produktionssymbol kartografisch darstellen). Solche Daten können durch jede Vermächtnis-Kompressionsmethode sehr effizient verschlüsselt werden.
4. Verschlüsselung der Lauf-Länge (RLE): Lange Reihen von wiederholten Symbolen in der Produktion (normalerweise Nullen zu diesem Zeitpunkt) werden durch eine Kombination des Symbols und eine Folge von zwei speziellen Codes ersetzt, und, die die Lauf-Länge als eine Binärzahl vertreten, die größer ist als ein (1). Die Folge würde als vertreten; und das Darstellen des Werts 4 in der Dezimalzahl. Der Code der Lauf-Länge wird durch das Erreichen eines anderen normalen Symbols begrenzt. Dieser RLE-Prozess ist flexibler als der RLE des Schritts 1, weil es im Stande ist, willkürlich lange ganze Zahlen zu verschlüsseln (in der Praxis, wird das gewöhnlich durch die Block-Größe beschränkt, so dass dieser Schritt keinen Lauf von mehr als 900000 Bytes verschlüsselt). Die Lauf-Länge wird auf diese Mode verschlüsselt: Das Zuweisen von Platz-Werten von 1 zum ersten Bit, 2 zum zweiten, 4 zum dritten, usw. in der RUNA/RUNB Folge, multipliziert jeden Platz-Wert in einem RUNB-Punkt um 2, und fügt alle resultierenden Platz-Werte hinzu (für RUNA, und RUNB schätzt gleich) zusammen. So, die Folge RUNB, läuft RUNA auf den Wert (1*2 + 2) = 4 hinaus. Als ein mehr kompliziertes Beispiel:
5. :
6. Huffman, der codiert: Dieser Prozess ersetzt befestigte Länge-Symbole in der Reihe 0-258 mit auf der Frequenz des Gebrauches gestützten Codes der variablen Länge. Öfter verwendete Codes enden kürzer (2-3 Bit), während seltene Codes bis zu 20 Bit zugeteilt werden können. Die Codes werden sorgfältig ausgewählt, so dass keine Folge von Bit für einen verschiedenen Code verwirrt sein kann. Der Code des Endes des Stroms ist besonders interessant. Wenn es n verschiedene Bytes in den unkomprimierten Daten verwendete (Symbole) gibt, dann wird der Code von Huffman aus zwei RLE-Codes (RUNA und RUNB), n-1 Symbol-Codes und ein Code des Endes des Stroms bestehen. Wegen des vereinigten Ergebnisses des MTF und RLE encodings in den vorherigen zwei Schritten gibt es nie jedes Bedürfnis, im ersten Symbol im MTF Tisch ausführlich Verweise anzubringen, so ein Symbol für den Anschreiber des Endes des Stroms sparend (und erklärend, warum nur n-1 Symbole im Baum von Huffman codiert werden). Im äußersten Fall, wo nur ein Symbol in den unkomprimierten Daten verwendet wird, wird es keine Symbol-Codes überhaupt im Baum von Huffman geben, und der komplette Block wird aus RUNA und RUNB bestehen (implizit das einzelne Byte wiederholend), und ein Anschreiber des Endes des Stroms mit dem Wert 2.

:

1. Vielfache Tische von Huffman: Mehrere identisch große Tische von Huffman können mit einem Block verwendet werden, wenn der Gewinn davon, sie zu verwenden, größer ist als die Kosten des Umfassens des Extratisches. Mindestens zwei (2) und bis zu sechs (6) Tische können mit dem passendsten Tisch da sein, der wird wiederauswählt, bevor alle 50 Symbole in einer Prozession gegangen sind. Das ist im Vorteil, sehr antwortende Dynamik von Huffman zu haben, ohne unaufhörlich neue Tische liefern zu müssen, wie darin erforderlich wäre, DEFLATIONIEREN. Die Verschlüsselung der Lauf-Länge im vorherigen Schritt wird entworfen, um auf Codes aufzupassen, die eine umgekehrte Wahrscheinlichkeit des Gebrauches höher haben als der kürzeste Code Code von Huffman im Gebrauch.
2. Unäre Basis 1 Verschlüsselung: Wenn vielfache Tische von Huffman im Gebrauch sind, die Auswahl an jedem Tisch (hat 0 numeriert.. 5) wird von einer Liste durch ein nullbegrenztes Bit getan, das zwischen einem (1) und sechs (6) Bit in der Länge geführt ist. Die Auswahl ist in eine MTF Liste der Tische. Das Verwenden dieser Eigenschaft läuft auf eine maximale Vergrößerung von ungefähr 1.015, aber allgemein weniger hinaus. Diese Vergrößerung wird wahrscheinlich durch den Vorteil außerordentlich überschattet, passendere Tische von Huffman auszuwählen, und der allgemeine Fall des Weitergehens, denselben Tisch von Huffman zu verwenden, wird wie ein einzelnes Bit vertreten. Anstatt der unären Verschlüsselung effektiv ist das eine äußerste Form eines Baums von Huffman, wo jeder Code Hälfte der Wahrscheinlichkeit des vorherigen Codes hat.
3. Delta, das (Δ) verschlüsselt: Codebit-Längen von Huffman sind erforderlich, jeden der verwendeten Kanonischen Tische von Huffman wieder aufzubauen. Jede Bit-Länge wird als ein verschlüsselter Unterschied gegen die vorherige Codebit-Länge versorgt. Ein Nullbit (0) Mittel, dass die vorherige Bit-Länge für den aktuellen Code kopiert werden sollte, während ein ein Bit (1) bedeutet, dass ein weiteres Bit gelesen werden sollte und die Bit-Länge, erhöht, oder decremented auf diesem Wert gestützt. Im allgemeinen Fall wird ein einzelnes Bit pro Symbol pro Tisch verwendet, und der Grenzfall — von der Länge ein (1) zur Länge zwanzig (20) gehend — würde etwa 37 Bit verlangen. Infolge früher MTF Verschlüsselung würden Codelängen am 2-3bits lang (sehr oft verwendete Codes) anfangen und allmählich zunehmen, bedeutend, dass das Delta-Format — das Verlangen von ungefähr 300 Bit (38 Bytes) pro vollen Tisch von Huffman ziemlich effizient ist.
4. Spärliche Bit-Reihe: Ein bitmap wird verwendet, um sich zu zeigen, welche Symbole innerhalb des Blocks verwendet werden und in die Bäume von Huffman eingeschlossen werden sollten. Binäre Daten werden wahrscheinlich alle 256 durch ein Byte wiederpräsentablen Symbole verwenden, wohingegen Textdaten nur eine kleine Teilmenge von verfügbaren Werten verwenden können, vielleicht die ASCII-Reihe zwischen 32 und 126 bedeckend. Die Speicherung von 256 Nullbit würde ineffizient sein, wenn sie größtenteils unbenutzt wären. Eine spärliche Methode wird verwendet: Die 256 Symbole werden in 16 Reihen und nur zerteilt, wenn Symbole innerhalb dieses Blocks verwendet werden, ist eine eingeschlossene 16-Bit-Reihe. Die Anwesenheit von jeder dieser 16 Reihen wird durch eine zusätzliche 16-Bit-Bit-Reihe an der Vorderseite angezeigt. Der ganze bitmap verwendet zwischen 32 und 272 Bit der Lagerung (4-34 Bytes). Für die Unähnlichkeit würde der DEFLATIONIEREN Algorithmus die Abwesenheit eines Symbols durch die Verschlüsselung des Symbols zeigen als, Nullbit-Länge zu haben; das ist mit der Delta-Verschlüsselung sehr ineffizient, die in bzip2 verwendet ist, der der Grund für bzip2 ist, der eine getrennte Bit-Reihe hat.

Dateiformat

Ein Strom besteht aus einem 4-Byte-Kopfball, der von der Null oder den komprimierteren Blöcken sofort gefolgt ist, die von einem Anschreiber des Endes des Stroms gefolgt sind, der einen 32-Bit-CRC für den plaintext ganzen bearbeiteten Strom enthält. Die komprimierten Blöcke werden Bit-ausgerichtet, und kein Polstern kommt vor.

.magic:16 = 'BZ' Unterschrift/Zauberzahl

.version:8 = 'h' für Bzip2 ('das Codieren von H'uffman), '0' für Bzip1 hat (missbilligt)

.hundred_k_blocksize:8 = '1'.. '9' Block-Größe 100 Kilobytes 900 Kilobytes

.compressed_magic:48 = 0x314159265359 (BCD (Pi))

.crc:32 = Kontrollsumme für diesen Block

.randomised:1 = 0 => normal, 1 => randomised hat (missbilligt)

.origPtr:24 = Startzeigestock in BWT dafür gestalten danach unum

.huffman_used_map:16 = bitmap, Reihen von 16 Bytes, präsentiert Gegenwart/nicht

.huffman_used_bitmaps:0.. 256 = präsentieren bitmap, verwendeter Symbole, Gegenwart (Vielfachen 16)/nicht

.huffman_groups:3 = 2.. 6 Zahl von verschiedenen Tischen von Huffman im Gebrauch

.selectors_used:15 = Zahl von Zeiten, dass die Tische von Huffman (jeder 50 Bytes) getauscht werden

• .selector_list:1.. 6 = nullbegrenzte Bit-Läufe (0.. 62) des Tisches von MTF'ed Huffman (*selectors_used)

.start_huffman_length:5 = 0.. 20 Startbit-Länge für Deltas von Huffman

• .delta_bit_length:1.. 40 = 0 => folgendes Symbol; 1 => verändern Länge

{1 => Verminderungslänge; 0 => erhöhen Länge} (* (symbols+2) *groups)

.contents:2..  = hat Huffman Datenstrom bis zum Ende des Blocks verschlüsselt

.eos_magic:48 = 0x177245385090 (BCD sqrt (Pi))

.crc:32 = Kontrollsumme für den ganzen Strom

.padding:0.. 7 = richten sich zum ganzen Byte aus

</pre>

Wegen der ersten Stufe RLE Kompression (sieh oben), ist die maximale Länge von plaintext, den einzelne 900 Kilobytes bzip2 Block enthalten können, ungefähr 46 Mb (45,899,235 Bytes). Das kann vorkommen, wenn der ganze plaintext völlig aus wiederholten Werten besteht (die resultierende Datei ist in diesem Fall 46 Bytes lang). Eine noch kleinere Datei von 40 Bytes kann durch das Verwenden eines Eingangs erreicht werden, der völlig Werte von 251, ein offenbares Kompressionsverhältnis 1147480:1 enthält.

Durchführungen

• bzip2: Die ursprüngliche laut einer BSD-Lizenz verfügbare Bezugsdurchführung von Julian Seward.
• 7-Schwirren-: Geschrieben von Igor Pavlov in C ++ enthält das 7-Schwirren-Gefolge einen bzip2 encoder/decoder, der frei lizenziert wird. 7-Schwirren-kommt mit der Nebenläufigkeitsunterstützung.
• micro-bzip2: Eine Version durch Rob Landley hat für die reduzierte kompilierte Codegröße und verfügbar unter dem GNU LGPL entwickelt.
• PBZIP2: Passen Sie mit Sitz in pthreads Durchführung in C ++ durch Jeff Gilchrist (und Windows-Version) an.
• bzip2smp: Eine Modifizierung dazu hat SMP parallelisation durch Konstantin Isakov.
• smpbzip2: Ein anderer geht an der Parallele bzip2 durch Niels Werensteijn.
• pyflate: Eine reine Pythonschlange eigenständiger bzip2 und DEFLATIONIERT (gzip) Decoder durch Paul Sladen. Wahrscheinlich nützlich für die Forschung und prototyping, der unter dem BSD/GPL/LGPL oder jeder anderen DFSG-vereinbaren Lizenz bereitgestellt ist.
• Die BZ2 von Arnaud Bouchez Delphi Durchführung mit C Bibliothek oder optimierten i386 Monteur codieren
• lbzip2: Passen Sie mit Sitz in pthreads bzip2/bunzip2 (bzip2 compressor/decompressor) Filter für den folgenden Zugriffseingang/Produktion durch László Érsek an.
• mpibzip2: Eine MPI-ermöglichte Durchführung, die in der Parallele durch Jeff Gilchrist/dekomprimiert zusammenpresst, der laut einer BSD-artigen Lizenz verfügbar ist.
• Apachen-Unterhaus-Kompresse-Apachen-Unterhaus-Kompresse-Projekt enthält javanische Durchführungen des Bzip2 Kompressors und decompressor.
• jbzip2 Eine javanische Durchführung von unter dem MIT bereitgestelltem bzip2 lizenzieren
• DotNetZip schließt C# Durchführung von bzip2 ein, ist auf die javanische Durchführung in der Apachen-Unterhaus-Kompresse zurückzuführen gewesen. Schließt einen Mehrgewinde-.NET bzip2 encoder/decoder Bibliothek und ein bzip2 Werkzeug der Befehl-Linie im geführten Code ein.

Siehe auch

• Der Vergleich des Archivs formatiert
• Die Liste des Archivs formatiert
• Liste der Datei archivers
• Vergleich der Datei archivers
• Liste von Programmen von Unix
• rzip

Links

• Der bzip2 und libbzip2 Hausseite
• Der Bzip2-Befehl - durch Das Linux Informationsprojekt (LINFO)
• bzip2 für Windows
• Grafischer bzip2 für Windows (WBZip2)
• MacBzip2 (für den Klassiker Mac OS; unter Mac OS X ist der Standard bzip2 an der Befehl-Linie verfügbar)
• Eigenschaft-Vergleich und Abrisspunkte für verschiedene Arten der Parallele bzip2 Durchführungen verfügbarer
• 4 Parallele bzip2 Durchführungen an Den Datenkompressionsnachrichten Blog
• Der ursprüngliche bzip Kompressor - kann durch Patente eingeschränkt werden