Der Aufbau der blocksortierenden Packverfahren hat sich in dreissig Jahren kaum bewegt. Ein Block endete bei ein paar hundert Kilobyte, eine Runde nutzte einen Faden, und Codelaengen mussten ganze Bytes sein. BZip3 oeffnet das alles auf einmal: Bloecke reichen bis 511 MiB, die ganze Verarbeitungskette ist neu, und Parallelitaet kommt fast gratis.

Die Blockgrenze lockern

Verlustfreie Kompression war immer ein offener Tausch. Kleinere Ausgabe kostet meist Zeit und Speicher. BZip3 ist ein Kommandozeilen Packer fuer Text und Quellcode, daneben steht eine in C geschriebene Bibliothek. Der erste Regler ist, wie weit das Programm auf einmal schauen darf: die Blockgroesse laeuft von 1 MiB bis 511 MiB, voreingestellt sind 16 MiB. Ein groesserer Block gibt weit entfernten Wiederholungen eine bessere Chance erkannt zu werden, und die Rate folgt. Der Preis steht in der Dokumentation. Packen und Entpacken brauchen Speicher von etwa dem Sechsfachen der Blockgroesse, und wieviel das Entpacken brauchen wird, steht in dem Moment fest, in dem gepackt wird, also muss der Zielrechner vorher geprueft werden.

Eine Kette aus drei Stufen

Die Kette hat drei Stufen. Am Eingang steht die Vorverarbeitung, durch die Lauflaengencodierung und ein Lempel-Ziv Praediktor je einmal laufen. Der erste raeumt wiederholte Bytes auf, der zweite findet weit entfernte gleiche Stuecke ueber Zeichenkettenabgleich im Stil von LZ77 und schaetzt dann das naechste Byte mit Kontextmodellierung im Stil von PPM. Das geschieht vor der Transformation und entfernt lange Wiederholungen, und je redundanter das Material, desto groesser der Gewinn. Die Mitte ist die blocksortierende Transformation auf Basis eines Suffixarrays, die aehnliche Kontexte auf benachbarte Stellen sammelt, sodass der einfache Praediktor niedriger Ordnung weiter hinten ebenfalls von Statistik hoeherer Ordnung profitiert. Der Ausgang ist die Entropiecodierung: arithmetisches Codieren mit Kontextmischung nullter Ordnung, das mehrere Wahrscheinlichkeitsschaetzungen je Kontext zusammenfuehrt und damit den Verlust ganzer Byte Codelaengen aufhebt.

Die Blockgrenze ist der Punkt, an dem die drei Stufen ins Gleichgewicht kommen. Derselbe Bestand durch verschiedene Blockgroessen geschickt ergibt deutlich andere Raten, und die offizielle Empfehlung lautet, den Block so hoch zu setzen wie der Speicher erlaubt, weil die Geschwindigkeit beim Entpacken von der Blockgroesse kaum abhaengt.

Speicher und Parallelitaet in Nutzerhand

Bloecke haengen nicht voneinander ab, also ist Parallelitaet wirklich fast gratis. Die Kommandozeile nimmt eine Zahl von Arbeitern, jeder Arbeiter betreut einen Block, voreingestellt ist ein einziger und die Obergrenze liegt bei 64. Vier bis acht Arbeiter in einem naechtlichen Sicherungsskript druecken die Packzeit um ein Mehrfaches. Bei der Integritaet wird nicht gespart. Jeder Block traegt eine CRC32 Pruefsumme, und beim Entpacken wird das Ergebnis Byte fuer Byte geprueft. Der feste Aufwand des Formats betraegt 9 Bytes je Datei und 9 bis 17 Bytes je Block, und das Projekt merkt an, dass Zufallsdaten meist unter 0.8 Prozent wachsen, unkomprimierbare Eingabe also nicht stark aufgeblaeht wird.

Die Zahlen im offiziellen Vergleich

Das Projekt veroeffentlicht eine Vergleichsliste, durch die sehr verschiedene Materialien laufen. Die aussagekraeftige Zahl ist das Verhaeltnis von gepackter zu urspruenglicher Groesse. Das mitgelieferte Quellarchiv geht von 501,760 Bytes auf 72,320 Bytes, also auf etwa ein Siebtel. Ein langer chinesischer Text landet bei etwa einem Sechstel. Audiodaten erreichen nur etwa ein Drittel, und ein Abbild einer virtuellen Maschine bleibt bei etwa der Haelfte stehen. Ein Allzweckwerkzeug ist das nicht, und das Projekt sagt es deutlich: besonders gut fuer Text und Quellcode.

Lizenz, Plattformen und Begleitbefehle

Die Lizenz ist LGPLv3, das Urheberrecht am Laufzeitcode liegt bei Kamila Szewczyk. Die Laufzeitbibliothek enthaelt zusaetzlich Teile unter Apache 2.0 und der BSD Lizenz mit zwei Klauseln, die Bauskripte laufen unter GPL drei mit einer Autoconf Ausnahme, und das Projekt beschreibt das Ganze als einlizenziert unter LGPLv3 statt doppelt lizenziert. Die Plattformabdeckung ist breiter als erwartet. Getestet wurden x86, x86_64, armv6, armv7, aarch64, ppc64le, mips, mips64, sparc und s390x, veroeffentlicht werden 32 und 64 Bit Programme fuer Windows plus ein 64 Bit Programm fuer Linux, und unter macOS laesst es sich aus einem Paketmanager holen. Die Optionen folgen bewusst den klassischen Unix Packern: voreingestellt wird gepackt, -b setzt die Blockgroesse, -j die Zahl der Arbeiter, -d entpackt, -t prueft nur, und -B arbeitet einen Stapel ab. Sechs Begleitbefehle kommen mit dem Quellpaket: bunzip3 fuer das Entpacken, bz3cat schreibt auf die Standardausgabe, bz3grep sucht Text direkt im gepackten Archiv, und bz3less mit bz3more und bz3most schieben das Ergebnis in einen Seitenbetrachter. Fassung 1.5.4 erschien am 7. September 2026, und das Archiv wird seit Mai 2022 laufend gepflegt.

BZip3 verspricht kein Wunder bei der Packrate. Es loest mehrere Grenzen, mit denen Leute lange gelebt haben: Bloecke wachsen auf 511 MiB, die Vorverarbeitung bekommt einen Praediktor, die Entropiecodierung wird Kontextmischung, und die Parallelitaet stellt der Nutzer selbst ein. Das passende Feld ist ebenso klar: Quellcode, Protokolle und lange Texte, also Material mit vielen Wiederholungen, das kein Zeichen verlieren darf.