XZ(1) XZ-Dienstprogramme XZ(1) BEZEICHNUNG xz, unxz, xzcat, lzma, unlzma, lzcat - .xz- und .lzma-Dateien komprimieren oder dekomprimieren UBERSICHT xz [Option] [Datei] BEFEHLSALIASE unxz ist gleichbedeutend mit xz --decompress. xzcat ist gleichbedeutend mit xz --decompress --stdout. lzma ist gleichbedeutend mit xz --format=lzma. unlzma ist gleichbedeutend mit xz --format=lzma --decompress. lzcat ist gleichbedeutend mit xz --format=lzma --decompress --stdout. Wenn Sie Skripte schreiben, die Dateien dekomprimieren, sollten Sie stets den Namen xz mit den entsprechenden Argumenten (xz -d oder xz -dc) anstelle der Namen unxz und xzcat verwenden. BESCHREIBUNG xz ist ein Allzweckwerkzeug zur Datenkompression, dessen Befehlszeilensyntax denen von gzip(1) und bzip2(1) ahnelt. Das native Dateiformat ist das .xz-Format, aber das veraltete, von den LZMA-Dienstprogrammen verwendete Format sowie komprimierte Rohdatenstrome ohne Containerformat-Header werden ebenfalls unterstutzt. Ausserdem wird die Dekompression des von lzip verwendeten .lz-Formats unterstutzt. xz komprimiert oder dekomprimiert jede Datei entsprechend des gewahlten Vorgangsmodus. Falls entweder - oder keine Datei angegeben ist, liest xz aus der Standardeingabe und leitet die verarbeiteten Dateien in die Standardausgabe. Wenn die Standardausgabe kein Terminal ist, verweigert xz das Schreiben komprimierter Daten in die Standardausgabe. Dabei wird eine Fehlermeldung angezeigt und die Datei ubersprungen. Ebenso verweigert xz das Lesen komprimierter Daten aus der Standardeingabe, wenn diese ein Terminal ist. Dateien, die nicht als - angegeben sind, werden in eine neue Datei geschrieben, deren Name aus dem Namen der Quell-Datei abgeleitet wird (ausser wenn --stdout angegeben ist): o Bei der Kompression wird das Suffix des Formats der Zieldatei (.xz oder .lzma) an den Namen der Quelldatei angehangt und so der Name der Zieldatei gebildet. o Bei der Dekompression wird das Suffix .xz, .lzma oder .lz vom Dateinamen entfernt und so der Name der Zieldatei gebildet. Ausserdem erkennt xz die Suffixe .txz und .tlz und ersetzt diese durch .tar. Wenn die Zieldatei bereits existiert, wird eine Fehlermeldung angezeigt und die Datei ubersprungen. Ausser beim Schreiben in die Standardausgabe zeigt xz eine Warnung an und uberspringt die Datei, wenn eine der folgenden Bedingungen zutreffend ist: o Die Datei ist keine regulare Datei. Symbolischen Verknupfungen wird nicht gefolgt und diese daher nicht zu den regularen Dateien gezahlt. o Die Datei hat mehr als eine harte Verknupfung. o Fur die Datei ist das >>setuid<<-, >>setgid<<- oder >>sticky<<-Bit gesetzt. o Der Aktionsmodus wird auf Kompression gesetzt und die Datei hat bereits das Suffix des Zieldateiformats (.xz oder .txz beim Komprimieren in das .xz-Format und .lzma oder .tlz beim Komprimieren in das .lzma-Format). o Der Aktionsmodus wird auf Dekompression gesetzt und die Datei hat nicht das Suffix eines der unterstutzten Zieldateiformate (.xz, .txz, .lzma, .tlz oder .lz). Nach erfolgreicher Kompression oder Dekompression der Datei kopiert xz Eigentumer, Gruppe, Zugriffsrechte, Zugriffszeit und Anderungszeit aus der Ursprungs-Datei in die Zieldatei. Sollte das Kopieren der Gruppe fehlschlagen, werden die Zugriffsrechte so angepasst, dass jenen Benutzern der Zugriff auf die Zieldatei verwehrt bleibt, die auch keinen Zugriff auf die Ursprungs-Datei hatten. Das Kopieren anderer Metadaten wie Zugriffssteuerlisten oder erweiterter Attribute wird von xz noch nicht unterstutzt. Sobald die Zieldatei erfolgreich geschlossen wurde, wird die Ursprungs-Datei entfernt. Dies wird durch die Option --keep verhindert. Die Ursprungs-Datei wird niemals entfernt, wenn die Ausgabe in die Standardausgabe geschrieben wird oder falls ein Fehler auftritt. Durch Senden der Signale SIGINFO oder SIGUSR1 an den xz-Prozess werden Fortschrittsinformationen in den Fehlerkanal der Standardausgabe geleitet. Dies ist nur eingeschrankt hilfreich, wenn die Standardfehlerausgabe ein Terminal ist. Mittels --verbose wird ein automatisch aktualisierter Fortschrittsanzeiger angezeigt. Speicherbedarf In Abhangigkeit von den gewahlten Kompressionseinstellungen bewegt sich der Speicherverbrauch zwischen wenigen hundert Kilobyte und mehreren Gigabyte. Die Einstellungen bei der Kompression einer Datei bestimmen dabei den Speicherbedarf bei der Dekompression. Die Dekompression benotigt ublicherweise zwischen 5 % und 20 % des Speichers, der bei der Kompression der Datei erforderlich war. Beispielsweise benotigt die Dekompression einer Datei, die mit xz -9 komprimiert wurde, gegenwartig etwa 65 MiB Speicher. Es ist jedoch auch moglich, dass .xz-Dateien mehrere Gigabyte an Speicher zur Dekompression erfordern. Insbesondere fur Benutzer alterer Systeme wird eventuell ein sehr grosser Speicherbedarf argerlich sein. Um unangenehme Uberraschungen zu vermeiden, verfugt xz uber eine eingebaute Begrenzung des Speicherbedarfs, die allerdings in der Voreinstellung deaktiviert ist. Zwar verfugen einige Betriebssysteme uber eingebaute Moglichkeiten zur prozessabhangigen Speicherbegrenzung, doch diese sind zu unflexibel (zum Beispiel kann ulimit(1) beim Begrenzen des virtuellen Speichers mmap(2) beeintrachtigen). Die Begrenzung des Speicherbedarfs kann mit der Befehlszeilenoption --memlimit=Begrenzung aktiviert werden. Oft ist es jedoch bequemer, die Begrenzung durch Setzen der Umgebungsvariable XZ_DEFAULTS standardmassig zu aktivieren, zum Beispiel XZ_DEFAULTS=--memlimit=150MiB. Die Begrenzungen konnen getrennt fur Kompression und Dekompression mittels --memlimit-compress=Begrenzung und --memlimit-decompress=Begrenzung festgelegt werden. Die Verwendung einer solchen Option ausserhalb der Variable XZ_DEFAULTS ist kaum sinnvoll, da xz in einer einzelnen Aktion nicht gleichzeitig Kompression und Dekompression ausfuhren kann und --memlimit=Begrenzung (oder -M Begrenzung) lasst sich einfacher in der Befehlszeile eingeben. Wenn die angegebene Speicherbegrenzung bei der Dekompression uberschritten wird, schlagt der Vorgang fehl und xz zeigt eine Fehlermeldung an. Wird die Begrenzung bei der Kompression uberschritten, dann versucht xz die Einstellungen entsprechend anzupassen, ausser wenn --format=raw oder --no-adjust angegeben ist. Auf diese Weise schlagt die Aktion nicht fehl, es sei denn, die Begrenzung wurde sehr niedrig angesetzt. Die Anpassung der Einstellungen wird schrittweise vorgenommen, allerdings entsprechen die Schritte nicht den Voreinstellungen der Kompressionsstufen. Das bedeutet, wenn beispielsweise die Begrenzung nur geringfugig unter den Anforderungen fur xz -9 liegt, werden auch die Einstellungen nur wenig angepasst und nicht vollstandig herunter zu den Werten fur xz -8 Verkettung und Auffullung von .xz-Dateien Es ist moglich, .xz-Dateien direkt zu verketten. Solche Dateien werden von xz genauso dekomprimiert wie eine einzelne .xz-Datei. Es ist weiterhin moglich, eine Auffullung zwischen den verketteten Teilen oder nach dem letzten Teil einzufugen. Die Auffullung muss aus Null-Bytes bestehen und deren Grosse muss ein Vielfaches von vier Byte sein. Dies kann zum Beispiel dann vorteilhaft sein, wenn die .xz-Datei auf einem Datentrager gespeichert wird, dessen Dateisystem die Dateigrossen in 512-Byte-Blocken speichert. Verkettung und Auffullung sind fur .lzma-Dateien oder Rohdatenstrome nicht erlaubt. OPTIONEN Ganzzahlige Suffixe und spezielle Werte An den meisten Stellen, wo ein ganzzahliges Argument akzeptiert wird, kann ein optionales Suffix grosse Ganzzahlwerte einfacher darstellen. Zwischen Ganzzahl und dem Suffix durfen sich keine Leerzeichen befinden. KiB multipliziert die Ganzzahl mit 1.024 (2^10). Ki, k, kB, K und KB werden als Synonyme fur KiB akzeptiert. MiB multipliziert die Ganzzahl mit 1.048.576 (2^20). Mi, m, M und MB werden als Synonyme fur MiB akzeptiert. GiB multipliziert die Ganzzahl mit 1.073.741.824 (2^30). Gi, g, G und GB werden als Synonyme fur GiB akzeptiert. Der spezielle Wert max kann dazu verwendet werden, um den von der jeweiligen Option akzeptierten maximalen Ganzzahlwert anzugeben. Aktionsmodus Falls mehrere Aktionsmodi angegeben sind, wird der zuletzt angegebene verwendet. -z, --compress Kompression. Dies ist der voreingestellte Aktionsmodus, sofern keiner angegeben ist und auch kein bestimmter Modus aus dem Befehlsnamen abgeleitet werden kann (der Befehl unxz impliziert zum Beispiel --decompress). -d, --decompress, --uncompress dekomprimpiert. -t, --test pruft die Integritat der komprimierten Dateien. Diese Option ist gleichbedeutend mit --decompress --stdout, ausser dass die dekomprimierten Daten verworfen werden, anstatt sie in die Standardausgabe zu leiten. Es werden keine Dateien erstellt oder entfernt. -l, --list gibt Informationen zu den komprimierten Dateien aus. Es werden keine unkomprimierten Dateien ausgegeben und keine Dateien angelegt oder entfernt. Im Listenmodus kann das Programm keine komprimierten Daten aus der Standardeingabe oder anderen nicht durchsuchbaren Quellen lesen. Die Liste zeigt in der Standardeinstellung grundlegende Informationen zu den Dateien an, zeilenweise pro Datei. Detailliertere Informationen erhalten Sie mit der Option --verbose. Wenn Sie diese Option zweimal angeben, werden noch ausfuhrlichere Informationen ausgegeben. Das kann den Vorgang allerdings deutlich verlangsamen, da die Ermittlung der zusatzlichen Informationen zahlreiche Suchvorgange erfordert. Die Breite der ausfuhrlichen Ausgabe ubersteigt 80 Zeichen, daher konnte die Weiterleitung in beispielsweise less -S sinnvoll sein, falls das Terminal nicht breit genug ist. Die exakte Ausgabe kann in verschiedenen xz-Versionen und Spracheinstellungen unterschiedlich sein. Wenn eine maschinell auswertbare Ausgabe gewunscht ist, dann sollten Sie --robot --list verwenden. Aktionsattribute -k, --keep verhindert das Loschen der Eingabedateien. Seit der xz-Version 5.2.6 wird die Kompression oder Dekompression auch dann ausgefuhrt, wenn die Eingabe ein symbolischer Link zu einer regularen Datei ist, mehr als einen harten Link hat oder das >>setuid<<-, >>setgid<<- oder >>sticky<<-Bit gesetzt ist. Die genannten Bits werden nicht in die Zieldatei kopiert. In fruheren Versionen geschah dies nur mit --force. -f, --force Diese Option hat verschiedene Auswirkungen: o Wenn die Zieldatei bereits existiert, wird diese vor der Kompression oder Dekompression geloscht. o Die Kompression oder Dekompression wird auch dann ausgefuhrt, wenn die Eingabe ein symbolischer Link zu einer regularen Datei ist, mehr als einen harten Link hat oder das >>setuid<<-, >>setgid<<- oder >>sticky<<-Bit gesetzt ist. Die genannten Bits werden nicht in die Zieldatei kopiert. o Wenn es zusammen mit --decompress und --stdout verwendet wird und xz den Typ der Quelldatei nicht ermitteln kann, wird die Quelldatei unverandert in die Standardausgabe kopiert. Dadurch kann xzcat --force fur Dateien, die nicht mit xz komprimiert wurden, wie cat(1) verwendet werden. Zukunftig konnte xz neue Dateikompressionsformate unterstutzen, wodurch xz mehr Dateitypen dekomprimieren kann, anstatt sie unverandert in die Standardausgabe zu kopieren. Mit der Option --format=Format konnen Sie xz anweisen, nur ein einzelnes Dateiformat zu dekomprimieren. -c, --stdout, --to-stdout schreibt die komprimierten oder dekomprimierten Daten in die Standardausgabe anstatt in eine Datei. Dies impliziert --keep. --single-stream dekomprimiert nur den ersten .xz-Datenstrom und ignoriert stillschweigend weitere Eingabedaten, die moglicherweise dem Datenstrom folgen. Normalerweise fuhrt solcher anhangender Datenmull dazu, dass xz eine Fehlermeldung ausgibt. xz dekomprimiert niemals mehr als einen Datenstrom aus .lzma-Dateien oder Rohdatenstromen, aber dennoch wird durch diese Option moglicherweise vorhandener Datenmull nach der .lzma-Datei oder dem Rohdatenstrom ignoriert. Diese Option ist wirkungslos, wenn der Aktionsmodus nicht --decompress oder --test ist. --no-sparse verhindert die Erzeugung von Sparse-Dateien. In der Voreinstellung versucht xz, bei der Dekompression in eine regulare Datei eine Sparse-Datei zu erzeugen, wenn die dekomprimierten Daten lange Abfolgen von binaren Nullen enthalten. Dies funktioniert auch beim Schreiben in die Standardausgabe, sofern diese in eine regulare Datei weitergeleitet wird und bestimmte Zusatzbedingungen erfullt sind, die die Aktion absichern. Die Erzeugung von Sparse-Dateien kann Plattenplatz sparen und beschleunigt die Dekompression durch Verringerung der Ein-/Ausgaben der Platte. -S .suf, --suffix=.suf verwendet .suf bei der Dekompression anstelle von .xz oder .lzma als Suffix fur die Zieldatei. Falls nicht in die Standardausgabe geschrieben wird und die Quelldatei bereits das Suffix .suf hat, wird eine Warnung angezeigt und die Datei ubersprungen. berucksichtigt bei der Dekompression zusatzlich zu Dateien mit den Suffixen .xz, .txz, .lzma, .tlz oder .lz auch jene mit dem Suffix .suf. Falls die Quelldatei das Suffix .suf hat, wird dieses entfernt und so der Name der Zieldatei abgeleitet. Beim Komprimieren oder Dekomprimieren von Rohdatenstromen mit --format=raw muss das Suffix stets angegeben werden, ausser wenn die Ausgabe in die Standardausgabe erfolgt. Der Grund dafur ist, dass es kein vorgegebenes Suffix fur Rohdatenstrome gibt. --files[=Datei] liest die zu verarbeitenden Dateinamen aus Datei. Falls keine Datei angegeben ist, werden die Dateinamen aus der Standardeingabe gelesen. Dateinamen mussen mit einem Zeilenumbruch beendet werden. Ein Bindestrich (-) wird als regularer Dateiname angesehen und nicht als Standardeingabe interpretiert. Falls Dateinamen ausserdem als Befehlszeilenargumente angegeben sind, werden diese vor den Dateinamen aus der Datei verarbeitet. --files0[=Datei] Dies ist gleichbedeutend mit --files[=Datei], ausser dass jeder Dateiname mit einem Null-Zeichen abgeschlossen werden muss. Grundlegende Dateiformat- und Kompressionsoptionen -F Format, --format=Format gibt das Format der zu komprimierenden oder dekomprimierenden Datei an: auto Dies ist die Voreinstellung. Bei der Kompression ist auto gleichbedeutend mit xz. Bei der Dekompression wird das Format der Eingabedatei automatisch erkannt. Beachten Sie, dass Rohdatenstrome, wie sie mit --format=raw erzeugt werden, nicht automatisch erkannt werden konnen. xz Die Kompression erfolgt in das .xz-Dateiformat oder akzeptiert nur .xz-Dateien bei der Dekompression. lzma, alone Die Kompression erfolgt in das veraltete .lzma-Dateiformat oder akzeptiert nur .lzma-Dateien bei der Dekompression. Der alternative Name alone dient der Abwartskompatibilitat zu den LZMA-Dienstprogrammen. lzip Akzeptiert nur .lz-Dateien bei der Dekompression. Kompression wird nicht unterstutzt. Das .lz-Format wird in Version 0 und der unerweiterten Version 1 unterstutzt. Dateien der Version 0 wurden von lzip 1.3 und alter erstellt. Solche Dateien sind nicht sehr weit verbreitet, konnen aber in Dateiarchiven gefunden werden, da einige Quellpakete in diesem Format veroffentlicht wurden. Es ist auch moglich, dass Benutzer alte personliche Dateien in diesem Format haben. Die Dekompressionsunterstutzung fur das Format der Version 0 wurde mit der Version 1.18 aus lzip entfernt. lzip-Versionen ab 1.4 erstellen Dateien im Format der Version 0. Die Erweiterung >>Sync Flush Marker<< zur Formatversion 1 wurde in lzip 1.6 hinzugefugt. Diese Erweiterung wird sehr selten verwendet und wird von xz nicht unterstutzt (die Eingabe wird als beschadigt erkannt). raw Komprimiert oder dekomprimiert einen Rohdatenstrom (ohne Header). Diese Option ist nur fur fortgeschrittene Benutzer bestimmt. Zum Dekodieren von Rohdatenstromen mussen Sie die Option --format=raw verwenden und die Filterkette ausdrucklich angeben, die normalerweise in den (hier fehlenden) Container-Headern gespeichert worden ware. -C Prufung, --check=Prufung gibt den Typ der Integritatsprufung an. Die Prufsumme wird aus den unkomprimierten Daten berechnet und in der .xz-Datei gespeichert. Diese Option wird nur bei der Kompression in das .xz-Format angewendet, da das .lzma-Format keine Integritatsprufungen unterstutzt. Die eigentliche Integritatsprufung erfolgt (falls moglich), wenn die .xz-Datei dekomprimiert wird. Folgende Typen von Prufungen werden unterstutzt: none fuhrt keine Integritatsprufung aus. Dies ist eine eher schlechte Idee. Dennoch kann es nutzlich sein, wenn die Integritat der Daten auf andere Weise sichergestellt werden kann. crc32 berechnet die CRC32-Prufsumme anhand des Polynoms aus IEEE-802.3 (Ethernet). crc64 berechnet die CRC64-Prufsumme anhand des Polynoms aus ECMA-182. Dies ist die Voreinstellung, da beschadigte Dateien etwas besser als mit CRC32 erkannt werden und die Geschwindigkeitsdifferenz unerheblich ist. sha256 berechnet die SHA-256-Prufsumme. Dies ist etwas langsamer als CRC32 und CRC64. Die Integritat der .xz-Header wird immer mit CRC32 gepruft. Es ist nicht moglich, dies zu andern oder zu deaktivieren. --ignore-check verifiziert die Integritatsprufsumme der komprimierten Daten bei der Dekompression nicht. Die CRC32-Werte in den .xz-Headern werden weiterhin normal verifiziert. Verwenden Sie diese Option nicht, ausser Sie wissen, was Sie tun. Mogliche Grunde, diese Option zu verwenden: o Versuchen, Daten aus einer beschadigten .xz-Datei wiederherzustellen. o Erhohung der Geschwindigkeit bei der Dekompression. Dies macht sich meist mit SHA-256 bemerkbar, oder mit Dateien, die extrem stark komprimiert sind. Wir empfehlen, diese Option nicht fur diesen Zweck zu verwenden, es sei denn, die Integritat der Datei wird extern auf andere Weise uberpruft. -0 -9 wahlt eine der voreingestellten Kompressionsstufen, standardmassig -6. Wenn mehrere Voreinstellungsstufen angegeben sind, ist nur die zuletzt angegebene wirksam. Falls bereits eine benutzerdefinierte Filterkette angegeben wurde, wird diese durch die Festlegung der Voreinstellung geleert. Die Unterschiede zwischen den Voreinstellungsstufen sind deutlicher als bei gzip(1) und bzip2(1). Die gewahlten Kompressionseinstellungen bestimmen den Speicherbedarf bei der Dekompression, daher ist es auf alteren Systemen mit wenig Speicher bei einer zu hoch gewahlten Voreinstellung schwer, eine Datei zu dekomprimieren. Insbesondere ist es keine gute Idee, blindlings -9 fur alles zu verwenden, wie dies haufig mit gzip(1) und bzip2(1) gehandhabt wird. -0 -3 Diese Voreinstellungen sind recht schnell. -0 ist manchmal schneller als gzip -9, wobei aber die Kompression wesentlich besser ist. Die schnelleren Voreinstellungen sind im Hinblick auf die Geschwindigkeit mit bzip2(1) vergleichbar , mit einem ahnlichen oder besseren Kompressionsverhaltnis, wobei das Ergebnis aber stark vom Typ der zu komprimierenden Daten abhangig ist. -4 -6 Gute bis sehr gute Kompression, wobei der Speicherbedarf fur die Dekompression selbst auf alten Systemen akzeptabel ist. -6 ist die Voreinstellung, welche ublicherweise eine gute Wahl fur die Verteilung von Dateien ist, die selbst noch auf Systemen mit nur 16 MiB Arbeitsspeicher dekomprimiert werden mussen (-5e oder -6e sind ebenfalls eine Uberlegung wert. Siehe --extreme). -7 -9 Ahnlich wie -6, aber mit einem hoheren Speicherbedarf fur die Kompression und Dekompression. Sie sind nur nutzlich, wenn Dateien komprimiert werden sollen, die grosser als 8 MiB, 16 MiB beziehungsweise 32 MiB sind. Auf der gleichen Hardware ist die Dekompressionsgeschwindigkeit ein nahezu konstanter Wert in Bytes komprimierter Daten pro Sekunde. Anders ausgedruckt: Je besser die Kompression, umso schneller wird ublicherweise die Dekompression sein. Das bedeutet auch, dass die Menge der pro Sekunde ausgegebenen unkomprimierten Daten stark variieren kann. Die folgende Tabelle fasst die Eigenschaften der Voreinstellungen zusammen: Voreinst. Wortb.Gr KomprCPU KompSpeich DekompSpeich -0 256 KiB 0 3 MiB 1 MiB -1 1 MiB 1 9 MiB 2 MiB -2 2 MiB 2 17 MiB 3 MiB -3 4 MiB 3 32 MiB 5 MiB -4 4 MiB 4 48 MiB 5 MiB -5 8 MiB 5 94 MiB 9 MiB -6 8 MiB 6 94 MiB 9 MiB -7 16 MiB 6 186 MiB 17 MiB -8 32 MiB 6 370 MiB 33 MiB -9 64 MiB 6 674 MiB 65 MiB Spaltenbeschreibungen: o Wortb.Grosse ist die Grosse des LZMA2-Worterbuchs. Es ist Speicherverschwendung, ein Worterbuch zu verwenden, das grosser als die unkomprimierte Datei ist. Daher ist es besser, die Voreinstellungen -7 -9 zu vermeiden, falls es keinen wirklichen Bedarf dafur gibt. Mit -6 und weniger wird ublicherweise so wenig Speicher verschwendet, dass dies nicht ins Gewicht fallt. o KomprCPU ist eine vereinfachte Reprasentation der LZMA2-Einstellungen, welche die Kompressionsgeschwindigkeit beeinflussen. Die Worterbuchgrosse wirkt sich ebenfalls auf die Geschwindigkeit aus. Wahrend KompCPU fur die Stufen -6 bis -9 gleich ist, tendieren hohere Stufen dazu, etwas langsamer zu sein. Um eine noch langsamere, aber moglicherweise bessere Kompression zu erhalten, siehe --extreme. o KompSpeich enthalt den Speicherbedarf des Kompressors im Einzel-Thread-Modus. Dieser kann zwischen den xz-Versionen leicht variieren. o DekompSpeich enthalt den Speicherbedarf fur die Dekompression. Das bedeutet, dass die Kompressionseinstellungen den Speicherbedarf bei der Dekompression bestimmen. Der exakte Speicherbedarf bei der Dekompression ist geringfugig grosser als die Grosse des LZMA2-Worterbuchs, aber die Werte in der Tabelle wurden auf ganze MiB aufgerundet. Der Speicherbedarf einiger der zukunftigen Multithread-Modi kann dramatisch hoher sein als im Einzel-Thread-Modus. Mit dem Standardwert von --block-size benotigt jeder Thread 3*3*Wortb.Gr plus KompSpeich oder DekompSpeich. Beispielsweise benotigen vier Threads mit der Voreinstellung -6 etwa 660 bis 670 MiB Speicher. -e, --extreme verwendet eine langsamere Variante der gewahlten Kompressions-Voreinstellungsstufe (-0 -9), um hoffentlich ein etwas besseres Kompressionsverhaltnis zu erreichen, das aber in ungunstigen Fallen auch schlechter werden kann. Der Speicherverbrauch bei der Dekompression wird dabei nicht beeinflusst, aber der Speicherverbrauch der Kompression steigt in den Voreinstellungsstufen -0 bis -3 geringfugig an. Da es zwei Voreinstellungen mit den Worterbuchgrossen 4 MiB und 8 MiB gibt, verwenden die Voreinstellungsstufen -3e und -5e etwas schnellere Einstellungen (niedrigere KompCPU) als -4e beziehungsweise -6e. Auf diese Weise sind zwei Voreinstellungen nie identisch. Voreinst. Wortb.Gr KomprCPU KompSpeich DekompSpeich -0e 256 KiB 8 4 MiB 1 MiB -1e 1 MiB 8 13 MiB 2 MiB -2e 2 MiB 8 25 MiB 3 MiB -3e 4 MiB 7 48 MiB 5 MiB -4e 4 MiB 8 48 MiB 5 MiB -5e 8 MiB 7 94 MiB 9 MiB -6e 8 MiB 8 94 MiB 9 MiB -7e 16 MiB 8 186 MiB 17 MiB -8e 32 MiB 8 370 MiB 33 MiB -9e 64 MiB 8 674 MiB 65 MiB Zum Beispiel gibt es insgesamt vier Voreinstellungen, die ein 8 MiB grosses Worterbuch verwenden, deren Reihenfolge von der schnellsten zur langsamsten -5, -6, -5e und -6e ist. --fast --best sind etwas irrefuhrende Aliase fur -0 beziehungsweise -9. Sie werden nur zwecks Abwartskompatibilitat zu den LZMA-Dienstprogrammen bereitgestellt. Sie sollten diese Optionen besser nicht verwenden. --block-size=Grosse teilt beim Komprimieren in das .xz-Format die Eingabedaten in Blocke der angegebenen Grosse in Byte. Die Blocke werden unabhangig voneinander komprimiert, was dem Multi-Threading entgegen kommt und Zufallszugriffe bei der Dekompression begrenzt. Diese Option wird typischerweise eingesetzt, um die vorgegebene Blockgrosse im Multi-Thread-Modus ausser Kraft zu setzen, aber sie kann auch im Einzel-Thread-Modus angewendet werden. Im Multi-Thread-Modus wird etwa die dreifache Grosse in jedem Thread zur Pufferung der Ein- und Ausgabe belegt. Die vorgegebene Grosse ist das Dreifache der Grosse des LZMA2-Worterbuchs oder 1 MiB, je nachdem, was mehr ist. Typischerweise ist das Zwei- bis Vierfache der Grosse des LZMA2-Worterbuchs oder wenigstens 1 MB ein guter Wert. Eine Grosse, die geringer ist als die des LZMA2-Worterbuchs, ist Speicherverschwendung, weil dann der LZMA2-Worterbuchpuffer niemals vollstandig genutzt werden wurde. Im Multi-Thread-Modus wird die Grosse der Blocke wird in den Block-Headern gespeichert. Die Grosseninformation wird fur eine Multi-Thread-Dekompression genutzt. Im Einzel-Thread-Modus werden die Blocke standardmassig nicht geteilt. Das Setzen dieser Option wirkt sich nicht auf den Speicherbedarf aus. In den Block-Headern werden keine Grosseninformationen gespeichert, daher werden im Einzel-Thread-Modus erzeugte Dateien nicht zu den im Multi-Thread-Modus erzeugten Dateien identisch sein. Das Fehlen der Grosseninformation bedingt auch, dass xz nicht in der Lage sein wird, die Dateien im Multi-Thread-Modus zu dekomprimieren. --block-list=Blocke beginnt bei der Kompression in das .xz-Format nach den angegebenen Intervallen unkomprimierter Daten einen neuen Block, optional mit einer benutzerdefinierten Filterkette. Die Blocke werden in einer durch Kommata getrennten Liste angegeben. Jeder Block besteht aus einer optionalen Filterkettennummer zwischen 0 und 9, gefolgt von einem Doppelpunkt (:) und der Grosse der unkomprimierten Daten (diese Angabe ist erforderlich). Uberspringen eines Blocks (zwei oder mehr aufeinander folgende Kommata) ist ein Kurzel dafur, die Grosse und die Filter des vorherigen Blocks zu verwenden. Falls die Eingabedatei grosser ist als die Summe der Blocke, dann wird der letzte in VBlocke angegebene Wert bis zum Ende der Datei wiederholt. Mit dem speziellen Wert 0 konnen Sie angeben, dass der Rest der Datei als einzelner Block kodiert werden soll. Eine alternative Filterkette fur jeden Block kann in Kombination mit den Optionen --filters1=Filter --filters9=Filter angegeben werden. Diese Optionen definieren Filterketten mit einem Bezeichner zwischen 1 und 9. Die Filterkette 0 bezeichnet hierbei die voreingestellte Filterkette, was dem Nichtangeben einer Filterkette gleichkommt. Der Filterkettenbezeichner kann vor der unkomprimierten Grosse verwendet werden, gefolgt von einem Doppelpunkt (:). Falls Sie beispielsweise --block-list=1:2MiB,3:2MiB,2:4MiB,,2MiB,0:4MiB angeben, werden die Blocke folgendermassen erstellt: o Die durch --filters1 angegebene Filterkette und 2 MiB Eingabe o Die durch --filters3 angegebene Filterkette und 2 MiB Eingabe o Die durch --filters2 angegebene Filterkette und 4 MiB Eingabe o Die durch --filters2 angegebene Filterkette und 4 MiB Eingabe o Die vorgegebene Filterkette und 2 MiB Eingabe o Die vorgegebene Filterkette und 4 MiB Eingabe fur jeden Block bis zum Ende der Eingabe. Falls Sie eine Grosse angeben, welche die Blockgrosse des Encoders ubersteigen (entweder den Vorgabewert im Thread-Modus oder den mit --block-size=Grosse angegebenen Wert), wird der Encoder zusatzliche Blocke erzeugen, wobei die in den Blocke angegebenen Grenzen eingehalten werden. Wenn Sie zum Beispiel --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB angeben und die Eingabedatei 80 MiB gross ist, erhalten Sie 11 Blocke: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 und 1 MiB. Im Multi-Thread-Modus werden die Blockgrossen in den Block-Headern gespeichert. Dies geschieht im Einzel-Thread-Modus nicht, daher wird die kodierte Ausgabe zu der im Multi-Thread-Modus nicht identisch sein. --flush-timeout=Zeit loscht bei der Kompression die ausstehenden Daten aus dem Encoder und macht sie im Ausgabedatenstrom verfugbar, wenn mehr als die angegebene Zeit in Millisekunden (als positive Ganzzahl) seit dem vorherigen Loschen vergangen ist und das Lesen weiterer Eingaben blockieren wurde. Dies kann nutzlich sein, wenn xz zum Komprimieren von uber das Netzwerk eingehenden Daten verwendet wird. Kleine Zeit-Werte machen die Daten unmittelbar nach dem Empfang nach einer kurzen Verzogerung verfugbar, wahrend grosse Zeit-Werte ein besseres Kompressionsverhaltnis bewirken. Dieses Funktionsmerkmal ist standardmassig deaktiviert. Wenn diese Option mehrfach angegeben wird, ist die zuletzt angegebene wirksam. Fur die Angabe der Zeit kann der spezielle Wert 0 verwendet werden, um dieses Funktionsmerkmal explizit zu deaktivieren. Dieses Funktionsmerkmal ist ausserhalb von POSIX-Systemen nicht verfugbar. Dieses Funktionsmerkmal ist noch experimentell. Gegenwartig ist xz aufgrund der Art und Weise, wie xz puffert, fur Dekompression in Echtzeit ungeeignet. --memlimit-compress=Grenze legt eine Grenze fur die Speichernutzung bei der Kompression fest. Wenn diese Option mehrmals angegeben wird, ist die zuletzt angegebene wirksam. Falls die Kompressionseinstellungen die Grenze uberschreiten, versucht xz, die Einstellungen nach unten anzupassen, so dass die Grenze nicht mehr uberschritten wird und zeigt einen Hinweis an, dass eine automatische Anpassung vorgenommen wurde. Die Anpassungen werden in folgender Reihenfolge angewendet: Reduzierung der Anzahl der Threads, Wechsel in den Einzelthread-Modus, falls sogar ein einziger Thread im Multithread-Modus die Grenze uberschreitet, und schlussendlich die Reduzierung der Grosse des LZMA2-Worterbuchs. Beim Komprimieren mit --format=raw oder falls --no-adjust angegeben wurde, wird nur die Anzahl der Threads reduziert, da nur so die komprimierte Ausgabe nicht beeinflusst wird. Falls die Grenze nicht anhand der vorstehend beschriebenen Anpassungen gesetzt werden kann, wird ein Fehler angezeigt und xz wird mit dem Exit-Status 1 beendet. Die Grenze kann auf verschiedene Arten angegeben werden: o Die Grenze kann ein absoluter Wert in Byte sein. Ein Suffix wie MiB kann dabei hilfreich sein. Beispiel: --memlimit-compress=80MiB. o Die Grenze kann als Prozentsatz des physischen Gesamtspeichers (RAM) angegeben werden. Dies ist insbesondere nutzlich, wenn in einem Shell-Initialisierungsskript, das mehrere unterschiedliche Rechner gemeinsam verwenden, die Umgebungsvariable XZ_DEFAULTS gesetzt ist. Auf diese Weise ist die Grenze auf Systemen mit mehr Speicher hoher. Beispiel: --memlimit-compress=70% o Mit 0 kann die Grenze auf den Standardwert zuruckgesetzt werden. Dies ist gegenwartig gleichbedeutend mit dem Setzen der Grenze auf max (keine Speicherbegrenzung). Fur die 32-Bit-Version von xz gibt es einen Spezialfall: Falls die Grenze uber 4020 MiB liegt, wird die Grenze auf 4020 MiB gesetzt. Auf MIPS32 wird stattdessen 2000 MB verwendet (die Werte 0 und max werden hiervon nicht beeinflusst; fur die Dekompression gibt es keine vergleichbare Funktion). Dies kann hilfreich sein, wenn ein 32-Bit-Executable auf einen 4 GiB grossen Adressraum (2 GiB auf MIPS32) zugreifen kann, wobei wir hoffen wollen, dass es in anderen Situationen keine negativen Effekte hat. Siehe auch den Abschnitt Speicherbedarf. --memlimit-decompress=Grenze legt eine Begrenzung des Speicherverbrauchs fur die Dekompression fest. Dies beeinflusst auch den Modus --list. Falls die Aktion nicht ausfuhrbar ist, ohne die Grenze zu uberschreiten, gibt xz eine Fehlermeldung aus und die Dekompression wird fehlschlagen. Siehe --memlimit-compress=Grenze zu moglichen Wegen, die Grenze anzugeben. --memlimit-mt-decompress=Grenze legt eine Begrenzung des Speicherverbrauchs fur Multithread-Dekompression fest. Dies beeinflusst lediglich die Anzahl der Threads; xz wird dadurch niemals die Dekompression einer Datei verweigern. Falls die Grenze fur jegliches Multithreading zu niedrig ist, wird sie ignoriert und xz setzt im Einzelthread-modus fort. Beachten Sie auch, dass bei der Verwendung von --memlimit-decompress dies stets sowohl auf den Einzelthread-als auch auf den Multithread-Modus angewendet wird und so die effektive Grenze fur den Multithread-Modus niemals hoher sein wird als die mit --memlimit-decompress gesetzte Grenze. Im Gegensatz zu anderen Optionen zur Begrenzung des Speicherverbrauchs hat --memlimit-mt-decompress=Grenze eine systemspezifisch vorgegebene Grenze. Mit xz --info-memory konnen Sie deren aktuellen Wert anzeigen lassen. Diese Option und ihr Standardwert existieren, weil die unbegrenzte threadbezogene Dekompression bei einigen Eingabedateien zu unglaublich grossem Speicherverbrauch fuhren wurde. Falls die vorgegebene Grenze auf Ihrem System zu niedrig ist, konnen Sie die Grenze durchaus erhohen, aber setzen Sie sie niemals auf einen Wert grosser als die Menge des nutzbaren Speichers, da xz bei entsprechenden Eingabedateien versuchen wird, diese Menge an Speicher auch bei einer geringen Anzahl von Threads zu verwnden. Speichermangel oder Auslagerung verbessern die Dekomprimierungsleistung nicht. Siehe --memlimit-compress=Grenze fur mogliche Wege zur Angabe der Grenze. Sezen der Grenze auf 0 setzt die Grenze auf den vorgegebenen systemspezifischen Wert zuruck. -M Grenze, --memlimit=Grenze, --memory=Grenze Dies ist gleichbedeutend mit --memlimit-compress=Grenze --memlimit-decompress=Grenze --memlimit-mt-decompress=Grenze. --no-adjust zeigt einen Fehler an und beendet, falls die Grenze der Speichernutzung nicht ohne Anderung der Einstellungen, welche die komprimierte Ausgabe beeinflussen, berucksichtigt werden kann. Das bedeutet, dass xz daran gehindert wird, den Encoder vom Multithread-Modus in den Einzelthread-Modus zu versetzen und die Grosse des LZMA2-Worterbuchs zu reduzieren. Allerdings kann bei Verwendung dieser Option dennoch die Anzahl der Threads reduziert werden, um die Grenze der Speichernutzung zu halten, sofern dies die komprimierte Ausgabe nicht beeinflusst. Die automatische Anpassung ist beim Erzeugen von Rohdatenstromen (--format=raw) immer deaktiviert. -T Threads, --threads=Threads gibt die Anzahl der zu verwendenden Arbeits-Threads an. Wenn Sie Threads auf einen speziellen Wert 0 setzen, verwendet xz maximal so viele Threads, wie der/die Prozessor(en) im System untestutzen. Die tatsachliche Anzahl kann geringer sein als die angegebenen Threads, wenn die Eingabedatei nicht gross genug fur Threading mit den gegebenen Einstellungen ist oder wenn mehr Threads die Speicherbegrenzung ubersteigen wurden. Die Multithread- bzw. Einzelthread-Kompressoren erzeugen unterschiedliche Ausgaben. Der Einzelthread-Kompressor erzeugt die geringste Dateigrosse, aber nur die Ausgabe des Multithread-Kompressors kann mit mehreren Threads wieder dekomprimiert werden. Das Setzen der Anzahl der Threads auf 1 wird den Einzelthread-Modus verwenden. Das Setzen der Anzahl der Threads auf einen anderen Wert einschliesslich 0 verwendet den Multithread-Kompressor, und zwar sogar dann, wenn das System nur einen einzigen Hardware-Thread unterstutzt (xz 5.2.x verwendete in diesem Fall noch den Einzelthread-Modus). Um den Multithread-Modus mit nur einem einzigen Thread zu verwenden, setzen Sie die Anzahl der Threads auf +1. Das Prafix + hat mit Werten verschieden von 1 keinen Effekt. Eine Begrenzung des Speicherverbrauchs kann xz dennoch veranlassen, den Einzelthread-Modus zu verwenden, ausser wenn --no-adjust verwendet wird. Die Unterstutzung fur das Prafix + wurde in xz 5.4.0 hinzugefugt. Falls das automatische Setzen der Anzahl der Threads angefordert und keine Speicherbegrenzung angegeben wurde, dann wird eine systemspezifisch vorgegebene weiche Grenze verwendet, um eventuell die Anzahl der Threads zu begrenzen. Es ist eine weiche Grenze im Sinne davon, dass sie ignoriert wird, falls die Anzahl der Threads 1 ist; daher wird eine weiche Grenze xz niemals an der Kompression oder Dekompression hindern. Diese vorgegebene weiche Grenze veranlasst xz nicht, vom Multithread-Modus in den Einzelthread-Modus zu wechseln. Die aktiven Grenzen konnen Sie mit dem Befehl xz --info-memory anzeigen lassen. Die gegenwartig einzige Threading-Methode teilt die Eingabe in Blocke und komprimiert diese unabhangig voneinander. Die vorgegebene Blockgrosse ist von der Kompressionsstufe abhangig und kann mit der Option --block-size=Grosse ausser Kraft gesetzt werden. Eine thread-basierte Dekompression wird nur bei Dateien funktionieren, die mehrere Blocke mit Grosseninformationen in deren Headern enthalten. Alle im Multi-Thread-Modus komprimierten Dateien, die gross genug sind, erfullen diese Bedingung, im Einzel-Thread-Modus komprimierte Dateien dagegen nicht, selbst wenn --block-size=Grosse verwendet wurde. Der Vorgabewert fur Threads is 0. In xz 5.4.x und alteren Versionen ist der Vorgabewert 1. Benutzerdefinierte Filterketten fur die Kompression Eine benutzerdefinierte Filterkette ermoglicht die Angabe detaillierter Kompressionseinstellungen, anstatt von den Voreinstellungen auszugehen. Wenn eine benutzerdefinierte Filterkette angegeben wird, werden die vorher in der Befehlszeile angegebenen Voreinstellungsoptionen (-0 -9 und --extreme) ausser Kraft gesetzt. Wenn eine Voreinstellungsoption nach einer oder mehreren benutzerdefinierten Filterkettenoptionen angegeben wird, dann wird die neue Voreinstellung wirksam und die zuvor angegebenen Filterkettenoptionen werden ausser Kraft gesetzt. Eine Filterkette ist mit dem Piping (der Weiterleitung) in der Befehlszeile vergleichbar. Bei der Kompression gelangt die unkomprimierte Eingabe in den ersten Filter, dessen Ausgabe wiederum in den zweiten Filter geleitet wird (sofern ein solcher vorhanden ist). Die Ausgabe des letzten Filters wird in die komprimierte Datei geschrieben. In einer Filterkette sind maximal vier Filter zulassig, aber typischerweise besteht eine Filterkette nur aus einem oder zwei Filtern. Bei vielen Filtern ist die Positionierung in der Filterkette eingeschrankt: Einige Filter sind nur als letzte in der Kette verwendbar, einige konnen nicht als letzte Filter gesetzt werden, und andere funktionieren an beliebiger Stelle. Abhangig von dem Filter ist diese Beschrankung entweder auf das Design des Filters selbst zuruckzufuhren oder ist aus Sicherheitsgrunden vorhanden. Eine benutzerdefinierte Filterkette kann auf zwei verschiedene Arten angegeben werden. Die Optionen --filters=Filter und --filters1=Filter --filters9=Filter ermoglichen die Angabe einer ganzen Filterkette in einer einzelnen Option gemass der Liblzma-Filterzeichenkettensyntax. Alternativ konnen Sie eine Filterkette mit einer oder mehreren individuellen Filteroptionen in der Reihenfolge angeben, in der sie in der Filterkette verwendet werden sollen. Daher ist die Reihenfolge der individuellen Filteroptionen wichtig! Beim Dekodieren von Rohdatenstromen (--format=raw) muss die Filterkette in der gleichen Reihenfolge wie bei der Komprimierung angegeben werden. Alle individuellen Filter- oder Voreinstellungsoptionen, die vor der vollen Filterkettenoption (--filters=Filter) angegeben werden, werden verworfen. Individuelle Filter, die nach der vollen Filterkettenoption angegeben werden, setzen die Filterkette zuruck Sowohl vollstandige als auch individuelle Filteroptionen akzeptieren filterspezifische Optionen in einer durch Kommata getrennten Liste. Zusatzliche Kommata in den Optionen werden ignoriert. Jede Option hat einen Standardwert, daher brauchen Sie nur jene anzugeben, die Sie andern wollen. Um die gesamte Filterkette und die Optionen anzuzeigen, rufen Sie xz -vv auf (was gleichbedeutend mit der zweimaligen Angabe von --verbose ist). Dies funktioniert auch zum Betrachten der von den Voreinstellungen verwendeten Filterkettenoptionen. --filters=Filter gibt die vollstandige Filterkette oder eine Voreinstellung in einer einzelnen Option an. Mehrere Filter konnen durch Leerzeichen oder zwei Minuszeichen (--) voneinander getrennt werden. Es kann notwendig sein, die Filter in der Shell-Befehlszeile zu maskieren, so dass diese als einzelne Option ausgewertet werden. Um Optionen Werte zuzuordnen, verwenden Sie : oder =. Einer Voreinstellung kann ein - vorangestellt werden, dem keiner oder mehrere Schalter folgen. Der einzige unterstutzte Schalter ist e zum Anwenden der gleichen Optionen wie --extreme. --filters1=Filter --filters9=Filter gibt bis zu neun optionale Filterketten an, die mit --block-list verwendet werden konnen. Wenn Sie beispielsweise ein Archiv mit ausfuhrbaren Dateien gefolgt von Textdateien komprimieren, konnte der Teil mit den ausfuhrbaren Dateien eine Filterkette mit einem BCJ-Filter und der Textdateiteil lediglich den LZMA2-Filter verwenden. --filters-help zeigt eine Hilfemeldung an, welche beschreibt, wie Voreinstellungen und benutzerdefinierte Filterketten in den Optionen --filters und --filters1=Filter --filters9=Filter angegeben werden und beendet das Programm. --lzma1[=Optionen] --lzma2[=Optionen] fugt LZMA1- oder LZMA2-Filter zur Filterkette hinzu. Diese Filter konnen nur als letzte Filter in der Kette verwendet werden. LZMA1 ist ein veralteter Filter, welcher nur wegen des veralteten .lzma-Dateiformats unterstutzt wird, welches nur LZMA1 unterstutzt. LZMA2 ist eine aktualisierte Version von LZMA1, welche einige praktische Probleme von LZMA1 behebt. Das .xz-Format verwendet LZMA2 und unterstutzt LZMA1 gar nicht. Kompressionsgeschwindigkeit und -verhaltnis sind bei LZMA1 und LZMA2 praktisch gleich. LZMA1 und LZMA2 haben die gleichen Optionen: preset=Voreinstellung setzt alle LZMA1- oder LZMA2-Optionen auf die Voreinstellung zuruck. Diese Voreinstellung wird in Form einer Ganzzahl angegeben, der ein aus einem einzelnen Buchstaben bestehender Voreinstellungsmodifikator folgen kann. Die Ganzzahl kann 0 bis 9 sein, entsprechend den Befehlszeilenoptionen -0 -9. Gegenwartig ist e der einzige unterstutzte Modifikator, was --extreme entspricht. Wenn keine Voreinstellung angegeben ist, werden die Standardwerte der LZMA1- oder LZMA2-Optionen der Voreinstellung 6 entnommen. dict=Grosse Die Grosse des Worterbuchs (Chronikpuffers) gibt an, wie viel Byte der kurzlich verarbeiteten unkomprimierten Daten im Speicher behalten werden sollen. Der Algorithmus versucht, sich wiederholende Byte-Abfolgen (Ubereinstimmungen) in den unkomprimierten Daten zu finden und diese durch Referenzen zu den Daten zu ersetzen, die sich gegenwartig im Worterbuch befinden. Je grosser das Worterbuch, umso grosser ist die Chance, eine Ubereinstimmung zu finden. Daher bewirkt eine Erhohung der Grosse des Worterbuchs ublicherweise ein besseres Kompressionsverhaltnis, aber ein Worterbuch, das grosser ist als die unkomprimierte Datei, ware Speicherverschwendung. Typische Worterbuch-Grossen liegen im Bereich von 64 KiB bis 64 MiB. Das Minimum ist 4 KiB. Das Maximum fur die Kompression ist gegenwartig 1.5 GiB (1536 MiB). Bei der Dekompression wird bereits eine Worterbuchgrosse bis zu 4 GiB minus 1 Byte unterstutzt, welche das Maximum fur die LZMA1- und LZMA2-Datenstromformate ist. Die Grosse des Worterbuchs und der Ubereinstimmungsfinder (Uf) bestimmen zusammen den Speicherverbrauch des LZMA1- oder LZMA2-Kodierers. Bei der Dekompression ist ein Worterbuch der gleichen Grosse (oder ein noch grosseres) wie bei der Kompression erforderlich, daher wird der Speicherverbrauch des Dekoders durch die Grosse des bei der Kompression verwendeten Worterbuchs bestimmt. Die .xz-Header speichern die Grosse des Worterbuchs entweder als 2^n oder 2^n + 2^(n-1), so dass diese Grossen fur die Kompression etwas bevorzugt werden. Andere Grossen werden beim Speichern in den .xz-Headern aufgerundet. lc=lc gibt die Anzahl der literalen Kontextbits an. Das Minimum ist 0 und das Maximum 4; der Standardwert ist 3. Ausserdem darf die Summe von lc und lp nicht grosser als 4 sein. Alle Bytes, die nicht als Ubereinstimmungen kodiert werden konnen, werden als Literale kodiert. Solche Literale sind einfache 8-bit-Bytes, die jeweils fur sich kodiert werden. Bei der Literalkodierung wird angenommen, dass die hochsten lc-Bits des zuvor unkomprimierten Bytes mit dem nachsten Byte in Beziehung stehen. Zum Beispiel folgt in typischen englischsprachigen Texten auf einen Grossbuchstaben ein Kleinbuchstabe und auf einen Kleinbuchstaben ublicherweise wieder ein Kleinbuchstabe. Im US-ASCII-Zeichensatz sind die hochsten drei Bits 010 fur Grossbuchstaben und 011 fur Kleinbuchstaben. Wenn lc mindestens 3 ist, kann die literale Kodierung diese Eigenschaft der unkomprimierten Daten ausnutzen. Der Vorgabewert (3) ist ublicherweise gut. Wenn Sie die maximale Kompression erreichen wollen, versuchen Sie lc=4. Manchmal hilft es ein wenig, doch manchmal verschlechtert es die Kompression. Im letzteren Fall versuchen Sie zum Beispiel auch lc=2. lp=lp gibt die Anzahl der literalen Positionsbits an. Das Minimum ist 0 und das Maximum 4; die Vorgabe ist 0. Lp beeinflusst, welche Art der Ausrichtung der unkomprimierten Daten beim Kodieren von Literalen angenommen wird. Siehe pb weiter unten fur weitere Informationen zur Ausrichtung. pb=Anzahl legt die Anzahl der Positions-Bits fest. Das Minimum ist 0 und das Maximum 4; Standard ist 2. Pb beeinflusst, welche Art der Ausrichtung der unkomprimierten Daten generell angenommen wird. Standardmassig wird eine Vier-Byte-Ausrichtung angenommen (2^pb=2^2=4), was oft eine gute Wahl ist, wenn es keine bessere Schatzung gibt. Wenn die Ausrichtung bekannt ist, kann das entsprechende Setzen von pb die Dateigrosse ein wenig verringern. Wenn Textdateien zum Beispiel eine Ein-Byte-Ausrichtung haben (US-ASCII, ISO-8859-*, UTF-8), kann das Setzen von pb=0 die Kompression etwas verbessern. Fur UTF-16-Text ist pb=1 eine gute Wahl. Wenn die Ausrichtung eine ungerade Zahl wie beispielsweise 3 Byte ist, konnte pb=0 die beste Wahl sein. Obwohl die angenommene Ausrichtung mit pb und lp angepasst werden kann, bevorzugen LZMA1 und LZMA2 noch etwas die 16-Byte-Ausrichtung. Das sollten Sie vielleicht beim Design von Dateiformaten berucksichtigen, die wahrscheinlich oft mit LZMA1 oder LZMA2 komprimiert werden. mf=Uf Der Ubereinstimmungsfinder hat einen grossen Einfluss auf die Geschwindigkeit des Kodierers, den Speicherbedarf und das Kompressionsverhaltnis. Ublicherweise sind auf Hash-Ketten basierende Ubereinstimmungsfinder schneller als jene, die mit Binarbaumen arbeiten. Die Vorgabe hangt von der Voreinstellungsstufe ab: 0 verwendet hc3, 1-3 verwenden hc4 und der Rest verwendet bt4. Die folgenden Ubereinstimmungsfinder werden unterstutzt. Die Formeln zur Ermittlung des Speicherverbrauchs sind grobe Schatzungen, die der Realitat am nachsten kommen, wenn Worterbuch eine Zweierpotenz ist. hc3 Hash-Kette mit 2- und 3-Byte-Hashing Minimalwert fur nice: 3 Speicherbedarf: dict * 7,5 (falls dict <= 16 MiB); dict * 5,5 + 64 MiB (falls dict > 16 MiB) hc4 Hash-Kette mit 2-, 3- und 4-Byte-Hashing Minimaler Wert fur nice: 4 Speicherbedarf: dict * 7,5 (falls dict <= 32 MiB ist); dict * 6,5 (falls dict > 32 MiB ist) bt2 Binarbaum mit 2-Byte-Hashing Minimaler Wert fur nice: 2 Speicherverbrauch: dict * 9.5 bt3 Binarbaum mit 2- und 3-Byte-Hashing Minimalwert fur nice: 3 Speicherbedarf: dict * 11,5 (falls dict <= 16 MiB ist); dict * 9,5 + 64 MiB (falls dict > 16 MiB ist) bt4 Binarbaum mit 2-, 3- und 4-Byte-Hashing Minimaler Wert fur nice: 4 Speicherbedarf: dict * 11,5 (falls dict <= 32 MiB ist); dict * 10,5 (falls dict > 32 MiB ist) mode=Modus gibt die Methode zum Analysieren der vom Ubereinstimmungsfinder gelieferten Daten an. Als Modi werden fast und normal unterstutzt. Die Vorgabe ist fast fur die Voreinstellungsstufen 0-3 und normal fur die Voreinstellungsstufen 4-9. Ublicherweise wird fast mit Hashketten-basierten Ubereinstimmungsfindern und normal mit Binarbaum-basierten Ubereinstimmungsfindern verwendet. So machen es auch die Voreinstellungsstufen. nice=nice gibt an, was als annehmbarer Wert fur eine Ubereinstimmung angesehen werden kann. Wenn eine Ubereinstimmung gefunden wird, die mindestens diesen nice-Wert hat, sucht der Algorithmus nicht weiter nach besseren Ubereinstimmungen. Der nice-Wert kann 2-273 Byte sein. Hohere Werte tendieren zu einem besseren Kompressionsverhaltnis, aber auf Kosten der Geschwindigkeit. Die Vorgabe hangt von der Voreinstellungsstufe ab. depth=Tiefe legt die maximale Suchtiefe im Ubereinstimmungsfinder fest. Vorgegeben ist der spezielle Wert 0, der den Kompressor veranlasst, einen annehmbaren Wert fur Tiefe aus Uf und nice-Wert zu bestimmen. Die angemessene Tiefe fur Hash-Ketten ist 4-100 und 16-1000 fur Binarbaume. Hohe Werte fur die Tiefe konnen den Kodierer bei einigen Dateien extrem verlangsamen. Vermeiden Sie es, die Tiefe uber einen Wert von 100 zu setzen, oder stellen Sie sich darauf ein, die Kompression abzubrechen, wenn sie zu lange dauert. Beim Dekodieren von Rohdatenstromen (--format=raw) benotigt LZMA2 nur die Worterbuch-Grosse. LZMA1 benotigt ausserdem lc, lp und pb. --x86[=Optionen] --arm[=Optionen] --armthumb[=Optionen] --arm64[=Optionen] --powerpc[=Optionen] --ia64[=Optionen] --sparc[=Optionen] --riscv[=Optionen] fugt ein >>Branch/Call/Jump<<-(BCJ-)Filter zur Filterkette hinzu. Diese Filter konnen nicht als letzter Filter in der Filterkette verwendet werden. Ein BCJ-Filter wandelt relative Adressen im Maschinencode in deren absolute Gegenstucke um. Die Datengrosse wird dadurch nicht geandert, aber die Redundanz erhoht, was LZMA2 dabei helfen kann, eine um 10 bis 15% kleinere .xz-Datei zu erstellen. Die BCJ-Filter sind immer reversibel, daher verursacht die Anwendung eines BCJ-Filters auf den falschen Datentyp keinen Datenverlust, wobei aber das Kompressionsverhaltnis etwas schlechter werden konnte. Die BCJ-Filter sind sehr schnell und verbrauchen nur wenig mehr Speicher. Diese BCJ-Filter haben bekannte Probleme mit dem Kompressionsverhaltnis: o In einigen Dateitypen, die ausfuhrbaren Code enthalten (zum Beispiel Objektdateien, statische Bibliotheken und Linux-Kernelmodule), sind die Adressen in den Anweisungen mit Fullwerten gefullt. Diese BCJ-Filter fuhren dennoch die Adressumwandlung aus, wodurch die Kompression bei diesen Dateien schlechter wird. o Falls ein BCJ-Filter auf ein Archiv angewendet wird, ist es moglich, dass das Kompressionsverhaltnis schlechter als ohne Filter wird. Falls es beispielsweise ahnliche oder sogar identische ausfuhrbare Dateien gibt, dann werden diese durch die Filterung wahrscheinlich >>unahnlicher<< und verschlechtern dadurch das Kompressionsverhaltnis. Der Inhalt nicht-ausfuhrbarer Dateien im gleichen Archiv kann sich ebenfalls darauf auswirken. In der Praxis werden Sie durch Versuche mit oder ohne BCJ-Filter selbst herausfinden mussen, was situationsbezogen besser ist. Verschiedene Befehlssatze haben unterschiedliche Ausrichtungen: Die ausfuhrbare Datei muss in den Eingabedateien einem Vielfachen dieses Wertes entsprechen, damit dieser Filter funktioniert. Filter Ausrichtung Hinweise x86 1 32-Bit oder 64-Bit x86 ARM 4 ARM-Thumb 2 ARM64 4 4096-Byte-Ausrichtung ist optimal PowerPC 4 Nur Big Endian IA-64 16 Itanium SPARC 4 RISC-V 2 Da die BCJ-gefilterten Daten ublicherweise mit LZMA2 komprimiert sind, kann das Kompressionsverhaltnis dadurch etwas verbessert werden, dass die LZMA2-Optionen so gesetzt werden, dass sie der Ausrichtung des gewahlten BCJ-Filters entsprechen. Beispiele: o Der IA-64-Filter hat eine 16-Byte-Ausrichtung, daher ist pb=4,lp=4,lc=0 fur LZMA2 passend (2^4=16). o RISC-V-Code hat eine 2-Byte- oder 4-Byte-Ausrichtung, abhangig davon, ob die Datei 16-bit-komprimierte Instruktionen enthalt (die C-Erweiterung). Wenn 16-bit-Instruktionen verwendet werden, ist pb=2,lp=1,lc=3 oder pb=1,lp=1,lc=3 passend. Wenn keine 16-bit-Instruktionen vorhanden sind, ist pb=2,lp=2,lc=2 am besten. Mit readelf -h konnen Sie uberprufen, ob >>RVC<< in der >>Flags<<-Zeile auftritt. o ARM64 hat stets eine 4-Byte-Ausrichtung, daher ist pb=2,lp=2,lc=2 am besten. o Der x86-Filter stellt eine Ausnahme dar. Es ist ublicherweise eine gute Wahl, bei den Voreinstellungen von LZMA2 (pb=2,lp=0,lc=3) zu bleiben, wenn Sie ausfuhrbare x86-Dateien komprimieren Alle BCJ-Filter unterstutzen die gleichen Optionen: start=Versatz gibt den Start-Versatz an, der bei der Umwandlung zwischen relativen und absoluten Adressen verwendet wird. Der Versatz muss ein Vielfaches der Filterausrichtung sein (siehe die Tabelle oben). Der Standardwert ist 0. In der Praxis ist dieser Standardwert gut; die Angabe eines benutzerdefinierten Versatzes ist fast immer unnutz. --delta[=Optionen] fugt den Delta-Filter zur Filterkette hinzu. Der Delta-Filter kann nicht als letzter Filter in der Filterkette verwendet werden. Gegenwartig wird nur eine einfache, Byte-bezogene Delta-Berechnung unterstutzt. Beim Komprimieren von zum Beispiel unkomprimierten Bitmap-Bildern oder unkomprimierten PCM-Audiodaten kann es jedoch sinnvoll sein. Dennoch konnen fur spezielle Zwecke entworfene Algorithmen deutlich bessere Ergebnisse als Delta und LZMA2 liefern. Dies trifft insbesondere auf Audiodaten zu, die sich zum Beispiel mit flac(1) schneller und besser komprimieren lassen. Unterstutzte Optionen: dist=Abstand gibt den Abstand der Delta-Berechnung in Byte an. Zulassige Werte fur den Abstand sind 1 bis 256. Der Vorgabewert ist 1. Zum Beispiel wird mit dist=2 und der 8-Byte-Eingabe A1 B1 A2 B3 A3 B5 A4 B7 die Ausgabe A1 B1 01 02 01 02 01 02 sein. Andere Optionen -q, --quiet unterdruckt Warnungen und Hinweise. Geben Sie dies zweimal an, um auch Fehlermeldungen zu unterdrucken. Diese Option wirkt sich nicht auf den Exit-Status aus. Das bedeutet, das selbst bei einer unterdruckten Warnung der Exit-Status zur Anzeige einer Warnung dennoch verwendet wird. -v, --verbose bewirkt ausfuhrliche Ausgaben. Wenn die Standardfehlerausgabe mit einem Terminal verbunden ist, zeigt xz den Fortschritt an. Durch zweimalige Angabe von --verbose wird die Ausgabe noch ausfuhrlicher. Der Fortschrittsanzeiger stellt die folgenden Informationen dar: o Der Prozentsatz des Fortschritts wird angezeigt, wenn die Grosse der Eingabedatei bekannt ist. Das bedeutet, dass der Prozentsatz in Weiterleitungen (Pipes) nicht angezeigt werden kann. o Menge der erzeugten komprimierten Daten (bei der Kompression) oder der verarbeiteten Daten (bei der Dekompression). o Menge der verarbeiteten unkomprimierten Daten (bei der Kompression) oder der erzeugten Daten (bei der Dekompression). o Kompressionsverhaltnis, das mittels Dividieren der Menge der bisher komprimierten Daten durch die Menge der bisher verarbeiteten unkomprimierten Daten ermittelt wird. o Kompressions- oder Dekompressionsgeschwindigkeit. Diese wird anhand der Menge der unkomprimierten verarbeiteten Daten (bei der Kompression) oder der Menge der erzeugten Daten (bei der Dekompression) pro Sekunde gemessen. Die Anzeige startet einige Sekunden nachdem xz mit der Verarbeitung der Datei begonnen hat. o Die vergangene Zeit im Format M:SS oder H:MM:SS. o Die geschatzte verbleibende Zeit wird nur angezeigt, wenn die Grosse der Eingabedatei bekannt ist und bereits einige Sekunden vergangen sind, nachdem xz mit der Verarbeitung der Datei begonnen hat. Die Zeit wird in einem weniger prazisen Format ohne Doppelpunkte angezeigt, zum Beispiel 2 min 30 s. Wenn die Standardfehlerausgabe kein Terminal ist, schreibt xz mit --verbose nach dem Komprimieren oder Dekomprimieren der Datei in einer einzelnen Zeile den Dateinamen, die komprimierte Grosse, die unkomprimierte Grosse, das Kompressionsverhaltnis und eventuell auch die Geschwindigkeit und die vergangene Zeit in die Standardfehlerausgabe. Die Geschwindigkeit und die vergangene Zeit werden nur angezeigt, wenn der Vorgang mindestens ein paar Sekunden gedauert hat. Wurde der Vorgang nicht beendet, zum Beispiel weil ihn der Benutzer abgebrochen hat, wird ausserdem der Prozentsatz des erreichten Verarbeitungsfortschritts aufgenommen, sofern die Grosse der Eingabedatei bekannt ist. -Q, --no-warn setzt den Exit-Status nicht auf 2, selbst wenn eine Bedingung erfullt ist, die eine Warnung gerechtfertigt hatte. Diese Option wirkt sich nicht auf die Ausfuhrlichkeitsstufe aus, daher mussen sowohl --quiet als auch --no-warn angegeben werden, um einerseits keine Warnungen anzuzeigen und andererseits auch den Exit-Status nicht zu andern. --robot gibt Meldungen in einem maschinenlesbaren Format aus. Dadurch soll das Schreiben von Frontends erleichtert werden, die xz anstelle von Liblzma verwenden wollen, was in verschiedenen Skripten der Fall sein kann. Die Ausgabe mit dieser aktivierten Option sollte uber mehrere xz-Veroffentlichungen stabil sein. Details hierzu finden Sie im Abschnitt ROBOTER-MODUS. --info-memory zeigt in einem menschenlesbaren Format an, wieviel physischen Speicher (RAM) und wie viele Prozessor-Threads das System nach Annahme von xz hat, sowie die Speicherbedarfsbegrenzung fur Kompression und Dekompression, und beendet das Programm erfolgreich. -h, --help zeigt eine Hilfemeldung mit den am haufigsten genutzten Optionen an und beendet das Programm erfolgreich. -H, --long-help zeigt eine Hilfemeldung an, die alle Funktionsmerkmale von xz beschreibt und beendet das Programm erfolgreich. -V, --version zeigt die Versionsnummer von xz und Liblzma in einem menschenlesbaren Format an. Um eine maschinell auswertbare Ausgabe zu erhalten, geben Sie --robot vor --version an. ROBOTER-MODUS Der Roboter-Modus wird mit der Option --robot aktiviert. Er bewirkt, dass die Ausgabe von xz leichter von anderen Programmen ausgewertet werden kann. Gegenwartig wird --robot nur zusammen mit --list, --filters-help, --info-memory und --version unterstutzt. In der Zukunft wird dieser Modus auch fur Kompression und Dekompression unterstutzt. Listenmodus xz --robot --list verwendet eine durch Tabulatoren getrennte Ausgabe. In der ersten Spalte jeder Zeile bezeichnet eine Zeichenkette den Typ der Information, die in dieser Zeile enthalten ist: name Dies ist stets die erste Zeile, wenn eine Datei aufgelistet wird. Die zweite Spalte in der Zeile enthalt den Dateinamen. file Diese Zeile enthalt allgemeine Informationen zur .xz-Datei. Diese Zeile wird stets nach der name-Zeile ausgegeben. stream Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt genau so viele stream-Zeilen, wie Datenstrome in der .xz-Datei enthalten sind. block Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt so viele block-Zeilen, wie Blocke in der .xz-Datei. Die block-Zeilen werden nach allen stream-Zeilen angezeigt; verschiedene Zeilentypen werden nicht verschachtelt. summary Dieser Zeilentyp wird nur verwendet, wenn --verbose zwei Mal angegeben wurde. Diese Zeile wird nach allen block-Zeilen ausgegeben. Wie die file-Zeile enthalt die summary-Zeile allgemeine Informationen zur .xz-Datei. totals Diese Zeile ist immer die letzte der Listenausgabe. Sie zeigt die Gesamtanzahlen und -grossen an. Die Spalten der file-Zeilen: 2. Anzahl der Datenstrome in der Datei 3. Gesamtanzahl der Blocke in den Datenstromen 4. Komprimierte Grosse der Datei 5. Unkomprimierte Grosse der Datei 6. Das Kompressionsverhaltnis, zum Beispiel 0.123. Wenn das Verhaltnis uber 9.999 liegt, werden drei Minuszeichen (---) anstelle des Kompressionsverhaltnisses angezeigt. 7. Durch Kommata getrennte Liste der Namen der Integritatsprufungen. Fur die bekannten Uberprufungstypen werden folgende Zeichenketten verwendet: None, CRC32, CRC64 und SHA-256. Unbek.N wird verwendet, wobei N die Kennung der Uberprufung als Dezimalzahl angibt (ein- oder zweistellig). 8. Gesamtgrosse der Datenstromauffullung in der Datei Die Spalten der stream-Zeilen: 2. Datenstromnummer (der erste Datenstrom ist 1) 3. Anzahl der Blocke im Datenstrom 4. Komprimierte Startposition 5. Unkomprimierte Startposition 6. Komprimierte Grosse (schliesst die Datenstromauffullung nicht mit ein) 7. Unkomprimierte Grosse 8. Kompressionsverhaltnis 9. Name der Integritatsprufung 10. Grosse der Datenstromauffullung Die Spalten der block-Zeilen: 2. Anzahl der in diesem Block enthaltenen Datenstrome 3. Blocknummer relativ zum Anfang des Datenstroms (der erste Block ist 1) 4. Blocknummer relativ zum Anfang der Datei 5. Komprimierter Startversatz relativ zum Beginn der Datei 6. Unkomprimierter Startversatz relativ zum Beginn der Datei 7. Komprimierte Gesamtgrosse des Blocks (einschliesslich Header) 8. Unkomprimierte Grosse 9. Kompressionsverhaltnis 10. Name der Integritatsprufung Wenn --verbose zwei Mal angegeben wurde, werden zusatzliche Spalten in die block-Zeilen eingefugt. Diese werden mit einem einfachen --verbose nicht angezeigt, da das Ermitteln dieser Informationen viele Suchvorgange erfordert und daher recht langsam sein kann: 11. Wert der Integritatsprufung in hexadezimaler Notation 12. Block-Header-Grosse 13. Block-Schalter: c gibt an, dass die komprimierte Grosse verfugbar ist, und u gibt an, dass die unkomprimierte Grosse verfugbar ist. Falls der Schalter nicht gesetzt ist, wird stattdessen ein Bindestrich (-) angezeigt, um die Lange der Zeichenkette beizubehalten. In Zukunft konnten neue Schalter am Ende der Zeichenkette hinzugefugt werden. 14. Grosse der tatsachlichen komprimierten Daten im Block. Ausgeschlossen sind hierbei die Block-Header, die Blockauffullung und die Pruffelder. 15. Grosse des Speichers (in Byte), der zum Dekomprimieren dieses Blocks mit dieser xz-Version benotigt wird. 16. Filterkette. Beachten Sie, dass die meisten der bei der Kompression verwendeten Optionen nicht bekannt sein konnen, da in den .xz-Headern nur die fur die Dekompression erforderlichen Optionen gespeichert sind. Die Spalten der summary-Zeilen: 2. Grosse des Speichers (in Byte), der zum Dekomprimieren dieser Datei mit dieser xz-Version benotigt wird. 3. yes oder no geben an, ob in allen Block-Headern sowohl die komprimierte als auch die unkomprimierte Grosse gespeichert ist. Seit xz 5.1.2alpha: 4. Minimale xz-Version, die zur Dekompression der Datei erforderlich ist Die Spalten der totals-Zeile: 2. Anzahl der Datenstrome 3. Anzahl der Blocke 4. Komprimierte Grosse 5. Unkomprimierte Grosse 6. Durchschnittliches Kompressionsverhaltnis 7. Durch Kommata getrennte Liste der Namen der Integritatsprufungen, die in den Dateien prasent waren. 8. Grosse der Datenstromauffullung 9. Anzahl der Dateien. Dies dient dazu, die Reihenfolge der vorigen Spalten an die in den file-Zeilen anzugleichen. Wenn --verbose zwei Mal angegeben wird, werden zusatzliche Spalten in die totals-Zeile eingefugt: 10. Maximale Grosse des Speichers (in Byte), der zum Dekomprimieren der Dateien mit dieser xz-Version benotigt wird. 11. yes oder no geben an, ob in allen Block-Headern sowohl die komprimierte als auch die unkomprimierte Grosse gespeichert ist. Seit xz 5.1.2alpha: 12. Minimale xz-Version, die zur Dekompression der Datei erforderlich ist Zukunftige Versionen konnten neue Zeilentypen hinzufugen, weiterhin konnten auch in den vorhandenen Zeilentypen weitere Spalten hinzugefugt werden, aber die existierenden Spalten werden nicht geandert. Filterhilfe xz --robot --filters-help gibt die unterstutzten Filter im folgenden Format aus: Filter:Option=,Option= Filter Name des Filters Option Name der filterspezifischen Option Wert Der numerische Wert erscheint als Bereich . Die Auswahl des Zeichenketten-Werts wird in < > eingeschlossen und durch | getrennt. Jeder Filter wird in einer separaten Zeile ausgegeben. Informationen zur Speicherbedarfsbegrenzung xz --robot --info-memory gibt eine einzelne Zeile mit mehreren durch Tabulatoren getrennten Spalten aus: 1. Gesamter physischer Speicher (RAM) in Byte. 2. Speicherbedarfsbegrenzung fur die Kompression in Byte (--memlimit-compress). Ein spezieller Wert von 0 bezeichnet die Standardeinstellung, die im Einzelthread-Modus bedeutet, dass keine Begrenzung vorhanden ist. 3. Speicherbedarfsbegrenzung fur die Dekompression in Byte (--memlimit-decompress). Ein spezieller Wert von 0 bezeichnet die Standardeinstellung, die im Einzelthread-Modus bedeutet, dass keine Begrenzung vorhanden ist. 4. Seit xz 5.3.4alpha: Die Speichernutzung fur Multithread-Dekompression in Byte (--memlimit-mt-decompress). Dies ist niemals 0, da ein systemspezifischer Vorgabewert (gezeigt in Spalte 5) verwendet wird, falls keine Grenze ausdrucklich angegeben wurde. Dies ist ausserdem niemals grosser als der Wert in in Spalte 3, selbst wenn mit --memlimit-mt-decompress ein grosserer Wert angegeben wurde. 5. Seit xz 5.3.4alpha: Eine systemspezifisch vorgegebene Begrenzung des Speicherverbrauchs, die zur Begrenzung der Anzahl der Threads beim Komprimieren mit automatischer Anzahl der Threads (--threads=0) und wenn keine Speicherbedarfsbegrenzung angegeben wurde (--memlimit-compress) verwendet wird. Dies wird auch als Standardwert fur --memlimit-mt-decompress verwendet. 6. Seit xz 5.3.4alpha: Anzahl der verfugbaren Prozessorthreads. In der Zukunft konnte die Ausgabe von xz --robot --info-memory weitere Spalten enthalten, aber niemals mehr als eine einzelne Zeile. Version xz --robot --version gibt die Versionsnummern von xz und Liblzma im folgenden Format aus: XZ_VERSION=XYYYZZZS LIBLZMA_VERSION=XYYYZZZS X Hauptversion. YYY Unterversion. Gerade Zahlen bezeichnen eine stabile Version. Ungerade Zahlen bezeichnen Alpha- oder Betaversionen. ZZZ Patch-Stufe fur stabile Veroffentlichungen oder einfach nur ein Zahler fur Entwicklungsversionen. S Stabilitat. 0 ist Alpha, 1 ist Beta und 2 ist stabil. S sollte immer 2 sein, wenn YYY eine gerade Zahl ist. XYYYZZZS sind in beiden Zeilen gleich, sofern xz und Liblzma aus der gleichen Veroffentlichung der XZ-Utils stammen. Beispiele: 4.999.9beta ist 49990091 und 5.0.0 is 50000002. EXIT-STATUS 0 Alles ist in Ordnung. 1 Ein Fehler ist aufgetreten. 2 Es ist etwas passiert, das eine Warnung rechtfertigt, aber es sind keine tatsachlichen Fehler aufgetreten. In die Standardausgabe geschriebene Hinweise (keine Warnungen oder Fehler), welche den Exit-Status nicht beeinflussen. UMGEBUNGSVARIABLEN xz wertet eine durch Leerzeichen getrennte Liste von Optionen in den Umgebungsvariablen XZ_DEFAULTS und XZ_OPT aus (in dieser Reihenfolge), bevor die Optionen aus der Befehlszeile ausgewertet werden. Beachten Sie, dass beim Auswerten der Umgebungsvariablen nur Optionen berucksichtigt werden; alle Eintrage, die keine Optionen sind, werden stillschweigend ignoriert. Die Auswertung erfolgt mit getopt_long(3), welches auch fur die Befehlszeilenargumente verwendet wird. XZ_DEFAULTS Benutzerspezifische oder systemweite Standardoptionen. Typischerweise werden diese in einem Shell-Initialisierungsskript gesetzt, um die Speicherbedarfsbegrenzung von xz standardmassig zu aktivieren. Ausser bei Shell-Initialisierungsskripten und in ahnlichen Spezialfallen darf die Variable XZ_DEFAULTS in Skripten niemals gesetzt oder ausser Kraft gesetzt werden. XZ_OPT Dies dient der Ubergabe von Optionen an xz, wenn es nicht moglich ist, die Optionen direkt in der Befehlszeile von xz zu ubergeben. Dies ist der Fall, wenn xz von einem Skript oder Dienstprogramm ausgefuhrt wird, zum Beispiel GNU tar(1): XZ_OPT=-2v tar caf foo.tar.xz foo Skripte konnen XZ_OPT zum Beispiel zum Setzen skriptspezifischer Standard-Kompressionsoptionen verwenden. Es ist weiterhin empfehlenswert, Benutzern die Ausserkraftsetzung von XZ_OPT zu erlauben, falls dies angemessen ist. Zum Beispiel konnte in sh(1)-Skripten Folgendes stehen: XZ_OPT=${XZ_OPT-"-7e"} export XZ_OPT KOMPATIBILITAT ZU DEN LZMA-UTILS Die Befehlszeilensyntax von xz ist praktisch eine Obermenge der von lzma, unlzma und lzcat in den LZMA-Utils der Versionen 4.32.x. In den meisten Fallen sollte es moglich sein, die LZMA-Utils durch die XZ-Utils zu ersetzen, ohne vorhandene Skripte andern zu mussen. Dennoch gibt es einige Inkompatibilitaten, die manchmal Probleme verursachen konnen. Voreinstellungsstufen zur Kompression Die Nummerierung der Voreinstellungsstufen der Kompression ist in xz und den LZMA-Utils unterschiedlich. Der wichtigste Unterschied ist die Zuweisung der Worterbuchgrossen zu den verschiedenen Voreinstellungsstufen. Die Worterbuchgrosse ist etwa gleich dem Speicherbedarf bei der Dekompression. Stufe xz LZMA-Utils -0 256 KiB nicht verfugbar -1 1 MiB 64 KiB -2 2 MiB 1 MiB -3 4 MiB 512 KiB -4 4 MiB 1 MiB -5 8 MiB 2 MiB -6 8 MiB 4 MiB -7 16 MiB 8 MiB -8 32 MiB 16 MiB -9 64 MiB 32 MiB Die Unterschiede in der Worterbuchgrosse beeinflussen auch den Speicherbedarf bei der Kompression, aber es gibt noch einige andere Unterschiede zwischen den LZMA-Utils und den XZ-Utils, die die Kluft noch vergrossern: Stufe xz LZMA-Utils 4.32.x -0 3 MiB nicht verfugbar -1 9 MiB 2 MiB -2 17 MiB 12 MiB -3 32 MiB 12 MiB -4 48 MiB 16 MiB -5 94 MiB 26 MiB -6 94 MiB 45 MiB -7 186 MiB 83 MiB -8 370 MiB 159 MiB -9 674 MiB 311 MiB Die standardmassige Voreinstellungsstufe in den LZMA-Utils ist -7, wahrend diese in den XZ-Utils -6 ist, daher verwenden beide standardmassig ein 8 MiB grosses Worterbuch. Vor- und Nachteile von .lzma-Dateien als Datenstrome Die unkomprimierte Grosse der Datei kann in den .lzma-Headern gespeichert werden. Die LZMA-Utils tun das beim Komprimieren gewohnlicher Dateien. Als Alternative kann die unkomprimierte Grosse als unbekannt markiert und eine Nutzdatenende-Markierung (end-of-payload) verwendet werden, um anzugeben, wo der Dekompressor stoppen soll. Die LZMA-Utils verwenden diese Methode, wenn die unkomprimierte Grosse unbekannt ist, was beispielsweise in Pipes (Befehlsverkettungen) der Fall ist. xz unterstutzt die Dekompression von .lzma-Dateien mit oder ohne Nutzdatenende-Markierung, aber alle von xz erstellten .lzma-Dateien verwenden diesen Nutzdatenende-Markierung, wobei die unkomprimierte Grosse in den .lzma-Headern als unbekannt markiert wird. Das konnte in einigen unublichen Situationen ein Problem sein. Zum Beispiel konnte ein .lzma-Dekompressor in einem Gerat mit eingebettetem System nur mit Dateien funktionieren, deren unkomprimierte Grosse bekannt ist. Falls Sie auf dieses Problem stossen, mussen Sie die LZMA-Utils oder das LZMA-SDK verwenden, um .lzma-Dateien mit bekannter unkomprimierter Grosse zu erzeugen. Nicht unterstutzte .lzma-Dateien Das .lzma-Format erlaubt lc-Werte bis zu 8 und lp-Werte bis zu 4. Die LZMA-Utils konnen Dateien mit beliebigem lc und lp dekomprimieren, aber erzeugen immer Dateien mit lc=3 und lp=0. Das Erzeugen von Dateien mit anderem lc und lp ist mit xz und mit dem LZMA-SDK moglich. Die Implementation des LZMA-Filters in liblzma setzt voraus, dass die Summe von lc und lp nicht grosser als 4 ist. Daher konnen .lzma-Dateien, welche diese Begrenzung uberschreiten, mit xz nicht dekomprimiert werden. Die LZMA-Utils erzeugen nur .lzma-Dateien mit einer Worterbuchgrosse von 2^n (einer Zweierpotenz), aber akzeptieren Dateien mit einer beliebigen Worterbuchgrosse. Liblzma akzeptiert nur .lzma-Dateien mit einer Worterbuchgrosse von 2^n oder 2^n + 2^(n-1). Dies dient zum Verringern von Fehlalarmen beim Erkennen von .lzma-Dateien. Diese Einschrankungen sollten in der Praxis kein Problem sein, da praktisch alle .lzma-Dateien mit Einstellungen komprimiert wurden, die Liblzma akzeptieren wird. Angehangter Datenmull Bei der Dekompression ignorieren die LZMA-Utils stillschweigend alles nach dem ersten .lzma-Datenstrom. In den meisten Situationen ist das ein Fehler. Das bedeutet auch, dass die LZMA-Utils die Dekompression verketteter .lzma-Dateien nicht unterstutzen. Wenn nach dem ersten .lzma-Datenstrom Daten verbleiben, erachtet xz die Datei als beschadigt, es sei denn, die Option --single-stream wurde verwendet. Dies konnte die Ausfuhrung von Skripten beeinflussen, die davon ausgehen, dass angehangter Datenmull ignoriert wird. ANMERKUNGEN Die komprimierte Ausgabe kann variieren Die exakte komprimierte Ausgabe, die aus der gleichen unkomprimierten Eingabedatei erzeugt wird, kann zwischen den Versionen der XZ-Utils unterschiedlich sein, selbst wenn die Kompressionsoptionen identisch sind. Das kommt daher, weil der Kodierer verbessert worden sein konnte (hinsichtlich schnellerer oder besserer Kompression), ohne das Dateiformat zu beeinflussen. Die Ausgabe kann sogar zwischen verschiedenen Programmen der gleichen Version der XZ-Utils variieren, wenn bei der Erstellung des Binarprogramms unterschiedliche Optionen verwendet wurden. Sobald --rsyncable implementiert wurde, bedeutet das, dass die sich ergebenden Dateien nicht notwendigerweise mit Rsync abgeglichen werden konnen, ausser wenn die alte und neue Datei mit der gleichen xz-Version erzeugt wurden. Das Problem kann beseitigt werden, wenn ein Teil der Encoder-Implementierung eingefroren wird, um die mit Rsync abgleichbare Ausgabe uber xz-Versionsgrenzen hinweg stabil zu halten. Eingebettete .xz-Dekompressoren Eingebettete .xz-Dekompressor-Implementierungen wie XZ Embedded unterstutzen nicht unbedingt Dateien, die mit anderen Integritatsprufungen (Prufung-Typen) als none und crc32 erzeugt wurden. Da --check=crc64 die Voreinstellung ist, mussen Sie --check=none oder --check=crc32 verwenden, wenn Sie Dateien fur eingebettete Systeme erstellen. Ausserhalb eingebetteter Systeme unterstutzen die Dekompressoren des .xz-Formats alle Prufung-Typen oder sind mindestens in der Lage, die Datei zu dekomprimieren, ohne deren Integritat zu prufen, wenn die bestimmte Prufung nicht verfugbar ist. XZ Embedded unterstutzt BCJ-Filter, aber nur mit dem vorgegebenen Startversatz. BEISPIELE Grundlagen Komprimiert die Datei foo mit der Standard-Kompressionsstufe (-6) zu foo.xz und entfernt foo nach erfolgreicher Kompression: xz foo bar.xz in bar dekomprimieren und bar.xz selbst dann nicht loschen, wenn die Dekompression erfolgreich war: xz -dk bar.xz baz.tar.xz mit der Voreinstellung -4e (-4 --extreme) erzeugen, was langsamer ist als die Vorgabe -6, aber weniger Speicher fur Kompression und Dekompression benotigt (48 MiB beziehungsweise 5 MiB): tar cf - baz | xz -4e > baz.tar.xz Eine Mischung aus komprimierten und unkomprimierten Dateien kann mit einem einzelnen Befehl dekomprimiert in die Standardausgabe geschrieben werden: xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt Parallele Kompression von vielen Dateien Auf GNU- und *BSD-Systemen konnen find(1) und xargs(1) zum Parallelisieren der Kompression vieler Dateien verwendet werden: find . -type f \! -name '*.xz' -print0 \ | xargs -0r -P4 -n16 xz -T1 Die Option -P von xargs(1) legt die Anzahl der parallelen xz-Prozesse fest. Der beste Wert fur die Option -n hangt davon ab, wie viele Dateien komprimiert werden sollen. Wenn es sich nur um wenige Dateien handelt, sollte der Wert wahrscheinlich 1 sein; bei Zehntausenden von Dateien kann 100 oder noch mehr angemessener sein, um die Anzahl der xz-Prozesse zu beschranken, die xargs(1) schliesslich erzeugen wird. Die Option -T1 fur xz dient dazu, den Einzelthread-Modus zu erzwingen, da xargs(1) zur Steuerung des Umfangs der Parallelisierung verwendet wird. Roboter-Modus Berechnen, wie viel Byte nach der Kompression mehrerer Dateien insgesamt eingespart wurden: xz --robot --list *.xz | awk '/^totals/{print $5-$4}' Ein Skript konnte abfragen wollen, ob es ein xz verwendet, das aktuell genug ist. Das folgende sh(1)-Skript pruft, ob die Versionsnummer des Dienstprogramms xz mindestens 5.0.0 ist. Diese Methode ist zu alten Beta-Versionen kompatibel, welche die Option --robot nicht unterstutzen: if ! eval "$(xz --robot --version 2> /dev/null)" || [ "$XZ_VERSION" -lt 50000002 ]; then echo "Ihre Version von Xz ist zu alt." fi unset XZ_VERSION LIBLZMA_VERSION Eine Speicherbedarfsbegrenzung fur die Dekompression mit XZ_OPT setzen, aber eine bereits gesetzte Begrenzung nicht erhohen: NEWLIM=$((123 << 20)) # 123 MiB OLDLIM=$(xz --robot --info-memory | cut -f3) if [ $OLDLIM -eq 0 -o $OLDLIM -gt $NEWLIM ]; then XZ_OPT="$XZ_OPT --memlimit-decompress=$NEWLIM" export XZ_OPT fi Benutzerdefinierte Filterketten fur die Kompression Der einfachste Anwendungsfall fur benutzerdefinierte Filterketten ist die Anpassung von LZMA2-Voreinstellungsstufen. Das kann nutzlich sein, weil die Voreinstellungen nur einen Teil der potenziell sinnvollen Kombinationen aus Kompressionseinstellungen abdecken. Die KompCPU-Spalten der Tabellen aus den Beschreibungen der Optionen -0 -9 und --extreme sind beim Anpassen der LZMA2-Voreinstellungen nutzlich. Diese sind die relevanten Teile aus diesen zwei Tabellen: Voreinst. KomprCPU -0 0 -1 1 -2 2 -3 3 -4 4 -5 5 -6 6 -5e 7 -6e 8 Wenn Sie wissen, dass eine Datei fur eine gute Kompression ein etwas grosseres Worterbuch benotigt (zum Beispiel 32 MiB), aber Sie sie schneller komprimieren wollen, als dies mit xz -8 geschehen wurde, kann eine Voreinstellung mit einem niedrigen KompCPU-Wert (zum Beispiel 1) dahingehend angepasst werden, ein grosseres Worterbuch zu verwenden: xz --lzma2=preset=1,dict=32MiB foo.tar Mit bestimmten Dateien kann der obige Befehl schneller sein als xz -6, wobei die Kompression deutlich besser wird. Dennoch muss betont werden, dass nur wenige Dateien von einem grosseren Worterbuch profitieren, wenn der KompCPU-Wert niedrig bleibt. Der offensichtlichste Fall, in dem ein grosseres Worterbuch sehr hilfreich sein kann, ist ein Archiv, das einander sehr ahnliche Dateien enthalt, die jeweils wenigstens einige Megabyte gross sind. Das Worterbuch muss dann deutlich grosser sein als die einzelne Datei, damit LZMA2 den grosstmoglichen Vorteil aus den Ahnlichkeiten der aufeinander folgenden Dateien zieht. Wenn hoher Speicherbedarf fur Kompression und Dekompression kein Problem ist und die zu komprimierende Datei mindestens einige Hundert Megabyte gross ist, kann es sinnvoll sein, ein noch grosseres Worterbuch zu verwenden, als die 64 MiB, die mit xz -9 verwendet werden wurden: xz -vv --lzma2=dict=192MiB big_foo.tar Die Verwendung von -vv (--verbose --verbose) wie im obigen Beispiel kann nutzlich sein, um den Speicherbedarf fur Kompressor und Dekompressor zu sehen. Denken Sie daran, dass ein Worterbuch, das grosser als die unkomprimierte Datei ist, Speicherverschwendung ware. Daher ist der obige Befehl fur kleine Dateien nicht sinnvoll. Manchmal spielt die Kompressionszeit keine Rolle, aber der Speicherbedarf bei der Dekompression muss gering gehalten werden, zum Beispiel um die Datei auf eingebetteten Systemen dekomprimieren zu konnen. Der folgende Befehl verwendet -6e (-6 --extreme) als Basis und setzt die Worterbuchgrosse auf nur 64 KiB. Die sich ergebende Datei kann mit XZ Embedded (aus diesem Grund ist dort --check=crc32) mit nur etwa 100 KiB Speicher dekomprimiert werden. xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo Wenn Sie so viele Byte wie moglich herausquetschen wollen, kann die Anpassung der Anzahl der literalen Kontextbits (lc) und der Anzahl der Positionsbits (pb) manchmal hilfreich sein. Auch die Anpassung der Anzahl der literalen Positionsbits (lp) konnte helfen, aber ublicherweise sind lc und pb wichtiger. Wenn ein Quellcode-Archiv zum Beispiel hauptsachlich ASCII-Text enthalt, konnte ein Aufruf wie der folgende eine etwas kleinere Datei (etwa 0,1 %) ergeben als mit xz -6e (versuchen Sie es auch lc=4): xz --lzma2=preset=6e,pb=0,lc=4 Quellcode.tar Die Verwendung eines anderen Filters mit LZMA2 kann die Kompression bei verschiedenen Dateitypen verbessern. So konnten Sie eine gemeinsam genutzte Bibliothek der Architekturen x86-32 oder x86-64 mit dem BCJ-Filter fur x86 komprimieren: xz --x86 --lzma2 libfoo.so Beachten Sie, dass die Reihenfolge der Filteroptionen von Bedeutung ist. Falls --x86 nach --lzma2 angegeben wird, gibt xz einen Fehler aus, weil nach LZMA2 kein weiterer Filter sein darf und auch weil der BCJ-Filter fur x86 nicht als letzter Filter in der Filterkette gesetzt werden darf. Der Delta-Filter zusammen mit LZMA2 kann bei Bitmap-Bildern gute Ergebnisse liefern. Er sollte ublicherweise besser sein als PNG, welches zwar einige fortgeschrittene Filter als ein simples delta bietet, aber fur die eigentliche Kompression >>Deflate<< verwendet. Das Bild muss in einem unkomprimierten Format gespeichert werden, zum Beispiel als unkomprimiertes TIFF. Der Abstandsparameter des Delta-Filters muss so gesetzt werden, dass er der Anzahl der Bytes pro Pixel im Bild entspricht. Zum Beispiel erfordert ein 24-Bit-RGB-Bitmap dist=3, ausserdem ist es gut, pb=0 an LZMA2 zu ubergeben, um die 3-Byte-Ausrichtung zu berucksichtigen: xz --delta=dist=3 --lzma2=pb=0 foo.tiff Wenn sich mehrere Bilder in einem einzelnen Archiv befinden (zum Beispiel .tar), funktioniert der Delta-Filter damit auch, sofern alle Bilder im Archiv die gleiche Anzahl Bytes pro Pixel haben. SIEHE AUCH xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1) XZ Utils: XZ Embedded: LZMA-SDK: Tukaani 25. Februar 2024 XZ(1)