'\" t
.\"
.\" Authors: Lasse Collin
.\"          Jia Tan
.\"
.\" This file has been put into the public domain.
.\" You can do whatever you want with this file.
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH XZ 1 "17. Juli 2023" Tukaani XZ\-Dienstprogramme
.
.SH BEZEICHNUNG
xz, unxz, xzcat, lzma, unlzma, lzcat \- .xz\- und .lzma\-Dateien komprimieren
oder dekomprimieren
.
.SH ÜBERSICHT
\fBxz\fP [\fIOption…\fP] [\fIDatei…\fP]
.
.SH BEFEHLSALIASE
\fBunxz\fP ist gleichbedeutend mit \fBxz \-\-decompress\fP.
.br
\fBxzcat\fP ist gleichbedeutend mit \fBxz \-\-decompress \-\-stdout\fP.
.br
\fBlzma\fP ist gleichbedeutend mit \fBxz \-\-format=lzma\fP.
.br
\fBunlzma\fP ist gleichbedeutend mit \fBxz \-\-format=lzma \-\-decompress\fP.
.br
\fBlzcat\fP ist gleichbedeutend mit \fBxz \-\-format=lzma \-\-decompress \-\-stdout\fP.
.PP
Wenn Sie Skripte schreiben, die Dateien dekomprimieren, sollten Sie stets
den Namen \fBxz\fP mit den entsprechenden Argumenten (\fBxz \-d\fP oder \fBxz \-dc\fP)
anstelle der Namen \fBunxz\fP und \fBxzcat\fP verwenden.
.
.SH BESCHREIBUNG
\fBxz\fP ist ein Allzweckwerkzeug zur Datenkompression, dessen
Befehlszeilensyntax denen von \fBgzip\fP(1) und \fBbzip2\fP(1) ähnelt. Das native
Dateiformat ist das \fB.xz\fP\-Format, aber das veraltete, von den
LZMA\-Dienstprogrammen verwendete Format sowie komprimierte Rohdatenströme
ohne Containerformat\-Header werden ebenfalls unterstützt. Außerdem wird die
Dekompression des von \fBlzip\fP verwendeten \fB.lz\fP\-Formats unterstützt.
.PP
\fBxz\fP komprimiert oder dekomprimiert jede \fIDatei\fP entsprechend des
gewählten Vorgangsmodus. Falls entweder \fB\-\fP oder keine Datei angegeben ist,
liest \fBxz\fP aus der Standardeingabe und leitet die verarbeiteten Dateien in
die Standardausgabe. Wenn die Standardausgabe kein Terminal ist, verweigert
\fBxz\fP das Schreiben komprimierter Daten in die Standardausgabe. Dabei wird
eine Fehlermeldung angezeigt und die \fIDatei\fP übersprungen. Ebenso
verweigert \fBxz\fP das Lesen komprimierter Daten aus der Standardeingabe, wenn
diese ein Terminal ist.
.PP
\fIDateien\fP, die nicht als \fB\-\fP angegeben sind, werden in eine neue Datei
geschrieben, deren Name aus dem Namen der Quell\-\fIDatei\fP abgeleitet wird
(außer wenn \fB\-\-stdout\fP angegeben ist):
.IP \(bu 3
Bei der Kompression wird das Suffix des Formats der Zieldatei (\fB.xz\fP oder
\&\fB.lzma\fP) an den Namen der Quelldatei angehängt und so der Name der
Zieldatei gebildet.
.IP \(bu 3
Bei der Dekompression wird das Suffix \fB.xz\fP, \fB.lzma\fP oder \fB.lz\fP vom
Dateinamen entfernt und so der Name der Zieldatei gebildet. Außerdem erkennt
\fBxz\fP die Suffixe \fB.txz\fP und \fB.tlz\fP und ersetzt diese durch \fB.tar\fP.
.PP
Wenn die Zieldatei bereits existiert, wird eine Fehlermeldung angezeigt und
die \fIDatei\fP übersprungen.
.PP
Außer beim Schreiben in die Standardausgabe zeigt \fBxz\fP eine Warnung an und
überspringt die \fIDatei\fP, wenn eine der folgenden Bedingungen zutreffend
ist:
.IP \(bu 3
Die \fIDatei\fP ist keine reguläre Datei. Symbolischen Verknüpfungen wird nicht
gefolgt und diese daher nicht zu den regulären Dateien gezählt.
.IP \(bu 3
Die \fIDatei\fP hat mehr als eine harte Verknüpfung.
.IP \(bu 3
Für die \fIDatei\fP ist das »setuid«\-, »setgid«\- oder »sticky«\-Bit gesetzt.
.IP \(bu 3
Der Aktionsmodus wird auf Kompression gesetzt und die \fIDatei\fP hat bereits
das Suffix des Zieldateiformats (\fB.xz\fP oder \fB.txz\fP beim Komprimieren in
das \fB.xz\fP\-Format und \fB.lzma\fP oder \fB.tlz\fP beim Komprimieren in das
\&\fB.lzma\fP\-Format).
.IP \(bu 3
Der Aktionsmodus wird auf Dekompression gesetzt und die \fIDatei\fP hat nicht
das Suffix eines der unterstützten Zieldateiformate (\fB.xz\fP, \fB.txz\fP,
\&\fB.lzma\fP, \fB.tlz\fP oder \fB.lz\fP).
.PP
Nach erfolgreicher Kompression oder Dekompression der \fIDatei\fP kopiert \fBxz\fP
Eigentümer, Gruppe, Zugriffsrechte, Zugriffszeit und Änderungszeit aus der
Ursprungs\-\fIDatei\fP 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\-\fIDatei\fP hatten. Das Kopieren anderer Metadaten wie
Zugriffssteuerlisten oder erweiterter Attribute wird von \fBxz\fP noch nicht
unterstützt.
.PP
Sobald die Zieldatei erfolgreich geschlossen wurde, wird die
Ursprungs\-\fIDatei\fP entfernt. Dies wird durch die Option \fB\-\-keep\fP
verhindert. Die Ursprungs\-\fIDatei\fP wird niemals entfernt, wenn die Ausgabe
in die Standardausgabe geschrieben wird oder falls ein Fehler auftritt.
.PP
Durch Senden der Signale \fBSIGINFO\fP oder \fBSIGUSR1\fP an den \fBxz\fP\-Prozess
werden Fortschrittsinformationen in den Fehlerkanal der Standardausgabe
geleitet. Dies ist nur eingeschränkt hilfreich, wenn die
Standardfehlerausgabe ein Terminal ist. Mittels \fB\-\-verbose\fP wird ein
automatisch aktualisierter Fortschrittsanzeiger angezeigt.
.
.SS Speicherbedarf
In Abhängigkeit von den gewählten 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 benötigt
üblicherweise zwischen 5\ % und 20\ % des Speichers, der bei der Kompression
der Datei erforderlich war. Beispielsweise benötigt die Dekompression einer
Datei, die mit \fBxz \-9\fP komprimiert wurde, gegenwärtig etwa 65\ MiB
Speicher. Es ist jedoch auch möglich, dass \fB.xz\fP\-Dateien mehrere Gigabyte
an Speicher zur Dekompression erfordern.
.PP
Insbesondere für Benutzer älterer Systeme wird eventuell ein sehr großer
Speicherbedarf ärgerlich sein. Um unangenehme Überraschungen zu vermeiden,
verfügt \fBxz\fP über eine eingebaute Begrenzung des Speicherbedarfs, die
allerdings in der Voreinstellung deaktiviert ist. Zwar verfügen einige
Betriebssysteme über eingebaute Möglichkeiten zur prozessabhängigen
Speicherbegrenzung, doch diese sind zu unflexibel (zum Beispiel kann
\fBulimit\fP(1) beim Begrenzen des virtuellen Speichers \fBmmap\fP(2)
beeinträchtigen).
.PP
Die Begrenzung des Speicherbedarfs kann mit der Befehlszeilenoption
\fB\-\-memlimit=\fP\fIBegrenzung\fP aktiviert werden. Oft ist es jedoch bequemer,
die Begrenzung durch Setzen der Umgebungsvariable \fBXZ_DEFAULTS\fP
standardmäßig zu aktivieren, zum Beispiel
\fBXZ_DEFAULTS=\-\-memlimit=150MiB\fP. Die Begrenzungen können getrennt für
Kompression und Dekompression mittels \fB\-\-memlimit\-compress=\fP\fIBegrenzung\fP
und \fB\-\-memlimit\-decompress=\fP\fIBegrenzung\fP festgelegt werden. Die Verwendung
einer solchen Option außerhalb der Variable \fBXZ_DEFAULTS\fP ist kaum
sinnvoll, da \fBxz\fP in einer einzelnen Aktion nicht gleichzeitig Kompression
und Dekompression ausführen kann und \fB\-\-memlimit=\fP\fIBegrenzung\fP (oder \fB\-M\fP
\fIBegrenzung\fP) lässt sich einfacher in der Befehlszeile eingeben.
.PP
Wenn die angegebene Speicherbegrenzung bei der Dekompression überschritten
wird, schlägt der Vorgang fehl und \fBxz\fP zeigt eine Fehlermeldung an. Wird
die Begrenzung bei der Kompression überschritten, dann versucht \fBxz\fP die
Einstellungen entsprechend anzupassen, außer wenn \fB\-\-format=raw\fP oder
\fB\-\-no\-adjust\fP angegeben ist. Auf diese Weise schlägt 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 geringfügig unter den Anforderungen
für \fBxz \-9\fP liegt, werden auch die Einstellungen nur wenig angepasst und
nicht vollständig herunter zu den Werten für \fBxz \-8\fP
.
.SS "Verkettung und Auffüllung von .xz\-Dateien"
Es ist möglich, \fB.xz\fP\-Dateien direkt zu verketten. Solche Dateien werden
von \fBxz\fP genauso dekomprimiert wie eine einzelne \fB.xz\fP\-Datei.
.PP
Es ist weiterhin möglich, eine Auffüllung zwischen den verketteten Teilen
oder nach dem letzten Teil einzufügen. Die Auffüllung muss aus Null\-Bytes
bestehen und deren Größe muss ein Vielfaches von vier Byte sein. Dies kann
zum Beispiel dann vorteilhaft sein, wenn die \fB.xz\fP\-Datei auf einem
Datenträger gespeichert wird, dessen Dateisystem die Dateigrößen in
512\-Byte\-Blöcken speichert.
.PP
Verkettung und Auffüllung sind für \fB.lzma\fP\-Dateien oder Rohdatenströme
nicht erlaubt.
.
.SH OPTIONEN
.
.SS "Ganzzahlige Suffixe und spezielle Werte"
An den meisten Stellen, wo ein ganzzahliges Argument akzeptiert wird, kann
ein optionales Suffix große Ganzzahlwerte einfacher darstellen. Zwischen
Ganzzahl und dem Suffix dürfen sich keine Leerzeichen befinden.
.TP 
\fBKiB\fP
multipliziert die Ganzzahl mit 1.024 (2^10). \fBKi\fP, \fBk\fP, \fBkB\fP, \fBK\fP und
\fBKB\fP werden als Synonyme für \fBKiB\fP akzeptiert.
.TP 
\fBMiB\fP
multipliziert die Ganzzahl mit 1.048.576 (2^20). \fBMi\fP, \fBm\fP, \fBM\fP und \fBMB\fP
werden als Synonyme für \fBMiB\fP akzeptiert.
.TP 
\fBGiB\fP
multipliziert die Ganzzahl mit 1.073.741.824 (2^30). \fBGi\fP, \fBg\fP, \fBG\fP und
\fBGB\fP werden als Synonyme für \fBGiB\fP akzeptiert.
.PP
Der spezielle Wert \fBmax\fP kann dazu verwendet werden, um den von der
jeweiligen Option akzeptierten maximalen Ganzzahlwert anzugeben.
.
.SS Aktionsmodus
Falls mehrere Aktionsmodi angegeben sind, wird der zuletzt angegebene
verwendet.
.TP 
\fB\-z\fP, \fB\-\-compress\fP
Kompression. Dies ist der voreingestellte Aktionsmodus, sofern keiner
angegeben ist und auch kein bestimmter Modus aus dem Befehlsnamen abgeleitet
werden kann (der Befehl \fBunxz\fP impliziert zum Beispiel \fB\-\-decompress\fP).
.TP 
\fB\-d\fP, \fB\-\-decompress\fP, \fB\-\-uncompress\fP
dekomprimpiert.
.TP 
\fB\-t\fP, \fB\-\-test\fP
prüft die Integrität der komprimierten \fIDateien\fP. Diese Option ist
gleichbedeutend mit \fB\-\-decompress \-\-stdout\fP, außer dass die dekomprimierten
Daten verworfen werden, anstatt sie in die Standardausgabe zu leiten. Es
werden keine Dateien erstellt oder entfernt.
.TP 
\fB\-l\fP, \fB\-\-list\fP
gibt Informationen zu den komprimierten \fIDateien\fP 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.
.IP ""
Die Liste zeigt in der Standardeinstellung grundlegende Informationen zu den
\fIDateien\fP an, zeilenweise pro Datei. Detailliertere Informationen erhalten
Sie mit der Option \fB\-\-verbose\fP. Wenn Sie diese Option zweimal angeben,
werden noch ausführlichere Informationen ausgegeben. Das kann den Vorgang
allerdings deutlich verlangsamen, da die Ermittlung der zusätzlichen
Informationen zahlreiche Suchvorgänge erfordert. Die Breite der
ausführlichen Ausgabe übersteigt 80 Zeichen, daher könnte die Weiterleitung
in beispielsweise\& \fBless\ \-S\fP sinnvoll sein, falls das Terminal nicht
breit genug ist.
.IP ""
Die exakte Ausgabe kann in verschiedenen \fBxz\fP\-Versionen und
Spracheinstellungen unterschiedlich sein. Wenn eine maschinell auswertbare
Ausgabe gewünscht ist, dann sollten Sie \fB\-\-robot \-\-list\fP verwenden.
.
.SS Aktionsattribute
.TP 
\fB\-k\fP, \fB\-\-keep\fP
verhindert das Löschen der Eingabedateien.
.IP ""
Seit der \fBxz\fP\-Version 5.2.6 wird die Kompression oder Dekompression auch
dann ausgeführt, wenn die Eingabe ein symbolischer Link zu einer regulären
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 früheren Versionen geschah dies nur mit \fB\-\-force\fP.
.TP 
\fB\-f\fP, \fB\-\-force\fP
Diese Option hat verschiedene Auswirkungen:
.RS
.IP \(bu 3
Wenn die Zieldatei bereits existiert, wird diese vor der Kompression oder
Dekompression gelöscht.
.IP \(bu 3
Die Kompression oder Dekompression wird auch dann ausgeführt, wenn die
Eingabe ein symbolischer Link zu einer regulären 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.
.IP \(bu 3
Wenn es zusammen mit \fB\-\-decompress\fP und \fB\-\-stdout\fP verwendet wird und
\fBxz\fP den Typ der Quelldatei nicht ermitteln kann, wird die Quelldatei
unverändert in die Standardausgabe kopiert. Dadurch kann \fBxzcat\fP \fB\-\-force\fP
für Dateien, die nicht mit \fBxz\fP komprimiert wurden, wie \fBcat\fP(1) verwendet
werden. Zukünftig könnte \fBxz\fP neue Dateikompressionsformate unterstützen,
wodurch \fBxz\fP mehr Dateitypen dekomprimieren kann, anstatt sie unverändert
in die Standardausgabe zu kopieren. Mit der Option \fB\-\-format=\fP\fIFormat\fP
können Sie \fBxz\fP anweisen, nur ein einzelnes Dateiformat zu dekomprimieren.
.RE
.TP 
\fB\-c\fP, \fB\-\-stdout\fP, \fB\-\-to\-stdout\fP
schreibt die komprimierten oder dekomprimierten Daten in die Standardausgabe
anstatt in eine Datei. Dies impliziert \fB\-\-keep\fP.
.TP 
\fB\-\-single\-stream\fP
dekomprimiert nur den ersten \fB.xz\fP\-Datenstrom und ignoriert stillschweigend
weitere Eingabedaten, die möglicherweise dem Datenstrom
folgen. Normalerweise führt solcher anhängender Datenmüll dazu, dass \fBxz\fP
eine Fehlermeldung ausgibt.
.IP ""
\fBxz\fP dekomprimiert niemals mehr als einen Datenstrom aus \fB.lzma\fP\-Dateien
oder Rohdatenströmen, aber dennoch wird durch diese Option möglicherweise
vorhandener Datenmüll nach der \fB.lzma\fP\-Datei oder dem Rohdatenstrom
ignoriert.
.IP ""
Diese Option ist wirkungslos, wenn der Aktionsmodus nicht \fB\-\-decompress\fP
oder \fB\-\-test\fP ist.
.TP 
\fB\-\-no\-sparse\fP
verhindert die Erzeugung von Sparse\-Dateien. In der Voreinstellung versucht
\fBxz\fP, bei der Dekompression in eine reguläre Datei eine Sparse\-Datei zu
erzeugen, wenn die dekomprimierten Daten lange Abfolgen von binären Nullen
enthalten. Dies funktioniert auch beim Schreiben in die Standardausgabe,
sofern diese in eine reguläre Datei weitergeleitet wird und bestimmte
Zusatzbedingungen erfüllt sind, die die Aktion absichern. Die Erzeugung von
Sparse\-Dateien kann Plattenplatz sparen und beschleunigt die Dekompression
durch Verringerung der Ein\-/Ausgaben der Platte.
.TP 
\fB\-S\fP \fI.suf\fP, \fB\-\-suffix=\fP\fI.suf\fP
verwendet \fI.suf\fP bei der Dekompression anstelle von \fB.xz\fP oder \fB.lzma\fP
als Suffix für die Zieldatei. Falls nicht in die Standardausgabe geschrieben
wird und die Quelldatei bereits das Suffix \fI.suf\fP hat, wird eine Warnung
angezeigt und die Datei übersprungen.
.IP ""
berücksichtigt bei der Dekompression zusätzlich zu Dateien mit den Suffixen
\&\fB.xz\fP, \fB.txz\fP, \fB.lzma\fP, \fB.tlz\fP oder \fB.lz\fP auch jene mit dem Suffix
\&\fI.suf\fP. Falls die Quelldatei das Suffix \fI.suf\fP hat, wird dieses entfernt
und so der Name der Zieldatei abgeleitet.
.IP ""
Beim Komprimieren oder Dekomprimieren von Rohdatenströmen mit
\fB\-\-format=raw\fP muss das Suffix stets angegeben werden, außer wenn die
Ausgabe in die Standardausgabe erfolgt. Der Grund dafür ist, dass es kein
vorgegebenes Suffix für Rohdatenströme gibt.
.TP 
\fB\-\-files\fP[\fB=\fP\fIDatei\fP]
liest die zu verarbeitenden Dateinamen aus \fIDatei\fP. Falls keine \fIDatei\fP
angegeben ist, werden die Dateinamen aus der Standardeingabe
gelesen. Dateinamen müssen mit einem Zeilenumbruch beendet werden. Ein
Bindestrich (\fB\-\fP) wird als regulärer Dateiname angesehen und nicht als
Standardeingabe interpretiert. Falls Dateinamen außerdem als
Befehlszeilenargumente angegeben sind, werden diese vor den Dateinamen aus
der \fIDatei\fP verarbeitet.
.TP 
\fB\-\-files0\fP[\fB=\fP\fIDatei\fP]
Dies ist gleichbedeutend mit \fB\-\-files\fP[\fB=\fP\fIDatei\fP], außer dass jeder
Dateiname mit einem Null\-Zeichen abgeschlossen werden muss.
.
.SS "Grundlegende Dateiformat\- und Kompressionsoptionen"
.TP 
\fB\-F\fP \fIFormat\fP, \fB\-\-format=\fP\fIFormat\fP
gibt das \fIFormat\fP der zu komprimierenden oder dekomprimierenden Datei an:
.RS
.TP 
\fBauto\fP
Dies ist die Voreinstellung. Bei der Kompression ist \fBauto\fP gleichbedeutend
mit \fBxz\fP. Bei der Dekompression wird das Format der Eingabedatei
automatisch erkannt. Beachten Sie, dass Rohdatenströme, wie sie mit
\fB\-\-format=raw\fP erzeugt werden, nicht automatisch erkannt werden können.
.TP 
\fBxz\fP
Die Kompression erfolgt in das \fB.xz\fP\-Dateiformat oder akzeptiert nur
\&\fB.xz\fP\-Dateien bei der Dekompression.
.TP 
\fBlzma\fP, \fBalone\fP
Die Kompression erfolgt in das veraltete \fB.lzma\fP\-Dateiformat oder
akzeptiert nur \fB.lzma\fP\-Dateien bei der Dekompression. Der alternative Name
\fBalone\fP dient der Abwärtskompatibilität zu den LZMA\-Dienstprogrammen.
.TP 
\fBlzip\fP
Akzeptiert nur \fB.lz\fP\-Dateien bei der Dekompression. Kompression wird nicht
unterstützt.
.IP ""
Das \fB.lz\fP\-Format wird in Version 0 und der unerweiterten Version 1
unterstützt. Dateien der Version 0 wurden von \fBlzip\fP 1.3 und älter
erstellt. Solche Dateien sind nicht sehr weit verbreitet, können aber in
Dateiarchiven gefunden werden, da einige Quellpakete in diesem Format
veröffentlicht wurden. Es ist auch möglich, dass Benutzer alte persönliche
Dateien in diesem Format haben. Die Dekompressionsunterstützung für das
Format der Version 0 wurde mit der Version 1.18 aus \fBlzip\fP entfernt.
.IP ""
\fBlzip\fP\-Versionen ab 1.4 erstellen Dateien im Format der Version 0. Die
Erweiterung »Sync Flush Marker« zur Formatversion 1 wurde in \fBlzip\fP 1.6
hinzugefügt. Diese Erweiterung wird sehr selten verwendet und wird von \fBxz\fP
nicht unterstützt (die Eingabe wird als beschädigt erkannt).
.TP 
\fBraw\fP
Komprimiert oder dekomprimiert einen Rohdatenstrom (ohne Header). Diese
Option ist nur für fortgeschrittene Benutzer bestimmt. Zum Dekodieren von
Rohdatenströmen müssen Sie die Option \fB\-\-format=raw\fP verwenden und die
Filterkette ausdrücklich angeben, die normalerweise in den (hier fehlenden)
Container\-Headern gespeichert worden wäre.
.RE
.TP 
\fB\-C\fP \fIPrüfung\fP, \fB\-\-check=\fP\fIPrüfung\fP
gibt den Typ der Integritätsprüfung an. Die Prüfsumme wird aus den
unkomprimierten Daten berechnet und in der \fB.xz\fP\-Datei gespeichert. Diese
Option wird nur bei der Kompression in das \fB.xz\fP\-Format angewendet, da das
\&\fB.lzma\fP\-Format keine Integritätsprüfungen unterstützt. Die eigentliche
Integritätsprüfung erfolgt (falls möglich), wenn die \fB.xz\fP\-Datei
dekomprimiert wird.
.IP ""
Folgende Typen von \fIPrüfungen\fP werden unterstützt:
.RS
.TP 
\fBnone\fP
führt keine Integritätsprüfung aus. Dies ist eine eher schlechte
Idee. Dennoch kann es nützlich sein, wenn die Integrität der Daten auf
andere Weise sichergestellt werden kann.
.TP 
\fBcrc32\fP
berechnet die CRC32\-Prüfsumme anhand des Polynoms aus IEEE\-802.3 (Ethernet).
.TP 
\fBcrc64\fP
berechnet die CRC64\-Prüfsumme anhand des Polynoms aus ECMA\-182. Dies ist die
Voreinstellung, da beschädigte Dateien etwas besser als mit CRC32 erkannt
werden und die Geschwindigkeitsdifferenz unerheblich ist.
.TP 
\fBsha256\fP
berechnet die SHA\-256\-Prüfsumme. Dies ist etwas langsamer als CRC32 und
CRC64.
.RE
.IP ""
Die Integrität der \fB.xz\fP\-Header wird immer mit CRC32 geprüft. Es ist nicht
möglich, dies zu ändern oder zu deaktivieren.
.TP 
\fB\-\-ignore\-check\fP
verifiziert die Integritätsprüfsumme der komprimierten Daten bei der
Dekompression nicht. Die CRC32\-Werte in den \fB.xz\fP\-Headern werden weiterhin
normal verifiziert.
.IP ""
\fBVerwenden Sie diese Option nicht, außer Sie wissen, was Sie tun.\fP Mögliche
Gründe, diese Option zu verwenden:
.RS
.IP \(bu 3
Versuchen, Daten aus einer beschädigten .xz\-Datei wiederherzustellen.
.IP \(bu 3
Erhöhung 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 für diesen Zweck zu verwenden, es
sei denn, die Integrität der Datei wird extern auf andere Weise überprüft.
.RE
.TP 
\fB\-0\fP … \fB\-9\fP
wählt eine der voreingestellten Kompressionsstufen, standardmäßig
\fB\-6\fP. 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.
.IP ""
Die Unterschiede zwischen den Voreinstellungsstufen sind deutlicher als bei
\fBgzip\fP(1) und \fBbzip2\fP(1). Die gewählten Kompressionseinstellungen
bestimmen den Speicherbedarf bei der Dekompression, daher ist es auf älteren
Systemen mit wenig Speicher bei einer zu hoch gewählten Voreinstellung
schwer, eine Datei zu dekomprimieren. Insbesondere \fBist es keine gute Idee, blindlings \-9 für alles\fP zu verwenden, wie dies häufig mit \fBgzip\fP(1) und
\fBbzip2\fP(1) gehandhabt wird.
.RS
.TP 
\fB\-0\fP … \fB\-3\fP
Diese Voreinstellungen sind recht schnell. \fB\-0\fP ist manchmal schneller als
\fBgzip \-9\fP, wobei aber die Kompression wesentlich besser ist. Die
schnelleren Voreinstellungen sind im Hinblick auf die Geschwindigkeit mit
\fBbzip2\fP(1) vergleichbar , mit einem ähnlichen oder besseren
Kompressionsverhältnis, wobei das Ergebnis aber stark vom Typ der zu
komprimierenden Daten abhängig ist.
.TP 
\fB\-4\fP … \fB\-6\fP
Gute bis sehr gute Kompression, wobei der Speicherbedarf für die
Dekompression selbst auf alten Systemen akzeptabel ist. \fB\-6\fP ist die
Voreinstellung, welche üblicherweise eine gute Wahl für die Verteilung von
Dateien ist, die selbst noch auf Systemen mit nur 16\ MiB Arbeitsspeicher
dekomprimiert werden müssen (\fB\-5e\fP oder \fB\-6e\fP sind ebenfalls eine
Überlegung wert. Siehe \fB\-\-extreme\fP).
.TP 
\fB\-7 … \-9\fP
Ähnlich wie \fB\-6\fP, aber mit einem höheren Speicherbedarf für die Kompression
und Dekompression. Sie sind nur nützlich, wenn Dateien komprimiert werden
sollen, die größer als 8\ MiB, 16\ MiB beziehungsweise 32\ MiB sind.
.RE
.IP ""
Auf der gleichen Hardware ist die Dekompressionsgeschwindigkeit ein nahezu
konstanter Wert in Bytes komprimierter Daten pro Sekunde. Anders
ausgedrückt: Je besser die Kompression, umso schneller wird üblicherweise
die Dekompression sein. Das bedeutet auch, dass die Menge der pro Sekunde
ausgegebenen unkomprimierten Daten stark variieren kann.
.IP ""
Die folgende Tabelle fasst die Eigenschaften der Voreinstellungen zusammen:
.RS
.RS
.PP
.TS
tab(;);
c c c c c
n n n n n.
Voreinst.;Wörtb.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
.TE
.RE
.RE
.IP ""
Spaltenbeschreibungen:
.RS
.IP \(bu 3
Wörtb.Größe ist die Größe des LZMA2\-Wörterbuchs. Es ist
Speicherverschwendung, ein Wörterbuch zu verwenden, das größer als die
unkomprimierte Datei ist. Daher ist es besser, die Voreinstellungen \fB\-7\fP …
\fB\-9\fP zu vermeiden, falls es keinen wirklichen Bedarf dafür gibt. Mit \fB\-6\fP
und weniger wird üblicherweise so wenig Speicher verschwendet, dass dies
nicht ins Gewicht fällt.
.IP \(bu 3
KomprCPU ist eine vereinfachte Repräsentation der LZMA2\-Einstellungen,
welche die Kompressionsgeschwindigkeit beeinflussen. Die Wörterbuchgröße
wirkt sich ebenfalls auf die Geschwindigkeit aus. Während KompCPU für die
Stufen \fB\-6\fP bis \fB\-9\fP gleich ist, tendieren höhere Stufen dazu, etwas
langsamer zu sein. Um eine noch langsamere, aber möglicherweise bessere
Kompression zu erhalten, siehe \fB\-\-extreme\fP.
.IP \(bu 3
KompSpeich enthält den Speicherbedarf des Kompressors im
Einzel\-Thread\-Modus. Dieser kann zwischen den \fBxz\fP\-Versionen leicht
variieren. Der Speicherbedarf einiger der zukünftigen Multithread\-Modi kann
dramatisch höher sein als im Einzel\-Thread\-Modus.
.IP \(bu 3
DekompSpeich enthält den Speicherbedarf für die Dekompression. Das bedeutet,
dass die Kompressionseinstellungen den Speicherbedarf bei der Dekompression
bestimmen. Der exakte Speicherbedarf bei der Dekompression ist geringfügig
größer als die Größe des LZMA2\-Wörterbuchs, aber die Werte in der Tabelle
wurden auf ganze MiB aufgerundet.
.RE
.TP 
\fB\-e\fP, \fB\-\-extreme\fP
verwendet eine langsamere Variante der gewählten
Kompressions\-Voreinstellungsstufe (\fB\-0\fP … \fB\-9\fP), um hoffentlich ein etwas
besseres Kompressionsverhältnis zu erreichen, das aber in ungünstigen Fällen
auch schlechter werden kann. Der Speicherverbrauch bei der Dekompression
wird dabei nicht beeinflusst, aber der Speicherverbrauch der Kompression
steigt in den Voreinstellungsstufen \fB\-0\fP bis \fB\-3\fP geringfügig an.
.IP ""
Da es zwei Voreinstellungen mit den Wörterbuchgrößen 4\ MiB und 8\ MiB gibt,
verwenden die Voreinstellungsstufen \fB\-3e\fP und \fB\-5e\fP etwas schnellere
Einstellungen (niedrigere KompCPU) als \fB\-4e\fP beziehungsweise \fB\-6e\fP. Auf
diese Weise sind zwei Voreinstellungen nie identisch.
.RS
.RS
.PP
.TS
tab(;);
c c c c c
n n n n n.
Voreinst.;Wörtb.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
.TE
.RE
.RE
.IP ""
Zum Beispiel gibt es insgesamt vier Voreinstellungen, die ein 8\ MiB großes
Wörterbuch verwenden, deren Reihenfolge von der schnellsten zur langsamsten
\fB\-5\fP, \fB\-6\fP, \fB\-5e\fP und \fB\-6e\fP ist.
.TP 
\fB\-\-fast\fP
.PD 0
.TP 
\fB\-\-best\fP
.PD
sind etwas irreführende Aliase für \fB\-0\fP beziehungsweise \fB\-9\fP. Sie werden
nur zwecks Abwärtskompatibilität zu den LZMA\-Dienstprogrammen
bereitgestellt. Sie sollten diese Optionen besser nicht verwenden.
.TP 
\fB\-\-block\-size=\fP\fIGröße\fP
teilt beim Komprimieren in das \fB.xz\fP\-Format die Eingabedaten in Blöcke der
angegebenen \fIGröße\fP in Byte. Die Blöcke werden unabhängig voneinander
komprimiert, was dem Multi\-Threading entgegen kommt und Zufallszugriffe bei
der Dekompression begrenzt. Diese Option wird typischerweise eingesetzt, um
die vorgegebene Blockgröße im Multi\-Thread\-Modus außer Kraft zu setzen, aber
sie kann auch im Einzel\-Thread\-Modus angewendet werden.
.IP ""
Im Multi\-Thread\-Modus wird etwa die dreifache \fIGröße\fP in jedem Thread zur
Pufferung der Ein\- und Ausgabe belegt. Die vorgegebene \fIGröße\fP ist das
Dreifache der Größe des LZMA2\-Wörterbuchs oder 1 MiB, je nachdem, was mehr
ist. Typischerweise ist das Zwei\- bis Vierfache der Größe des
LZMA2\-Wörterbuchs oder wenigstens 1 MB ein guter Wert. Eine \fIGröße\fP, die
geringer ist als die des LZMA2\-Wörterbuchs, ist Speicherverschwendung, weil
dann der LZMA2\-Wörterbuchpuffer niemals vollständig genutzt werden
würde. Die Größe der Blöcke wird in den Block\-Headern gespeichert, die von
einer zukünftigen Version von \fBxz\fP für eine Multi\-Thread\-Dekompression
genutzt wird.
.IP ""
Im Einzel\-Thread\-Modus werden die Blöcke standardmäßig nicht geteilt. Das
Setzen dieser Option wirkt sich nicht auf den Speicherbedarf aus. In den
Block\-Headern werden keine Größeninformationen gespeichert, daher werden im
Einzel\-Thread\-Modus erzeugte Dateien nicht zu den im Multi\-Thread\-Modus
erzeugten Dateien identisch sein. Das Fehlen der Größeninformation bedingt
auch, dass eine zukünftige Version von \fBxz\fP nicht in der Lage sein wird,
die Dateien im Multi\-Thread\-Modus zu dekomprimieren.
.TP 
\fB\-\-block\-list=\fP\fIGrößen\fP
beginnt bei der Kompression in das \fB.xz\fP\-Format nach den angegebenen
Intervallen unkomprimierter Daten einen neuen Block.
.IP ""
Die unkomprimierte \fIGröße\fP der Blöcke wird in einer durch Kommata
getrennten Liste angegeben. Auslassen einer Größe (zwei oder mehr
aufeinander folgende Kommata) ist ein Kürzel dafür, die Größe des vorherigen
Blocks zu verwenden.
.IP ""
Falls die Eingabedatei größer ist als die Summe der \fIGrößen\fP, dann wird der
letzte in \fIGröße\fP angegebene Wert bis zum Ende der Datei wiederholt. Mit
dem speziellen Wert \fB0\fP können Sie angeben, dass der Rest der Datei als
einzelner Block kodiert werden soll.
.IP ""
Falls Sie \fIGrößen\fP angeben, welche die Blockgröße des Encoders übersteigen
(entweder den Vorgabewert im Thread\-Modus oder den mit
\fB\-\-block\-size=\fP\fIGröße\fP angegebenen Wert), wird der Encoder zusätzliche
Blöcke erzeugen, wobei die in den \fIGrößen\fP angegebenen Grenzen eingehalten
werden. Wenn Sie zum Beispiel \fB\-\-block\-size=10MiB\fP
\fB\-\-block\-list=5MiB,10MiB,8MiB,12MiB,24MiB\fP angeben und die Eingabedatei 80
MiB groß ist, erhalten Sie 11 Blöcke: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 und
1 MiB.
.IP ""
Im Multi\-Thread\-Modus werden die Blockgrößen 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.
.TP 
\fB\-\-flush\-timeout=\fP\fIZeit\fP
löscht bei der Kompression die ausstehenden Daten aus dem Encoder und macht
sie im Ausgabedatenstrom verfügbar, wenn mehr als die angegebene \fIZeit\fP in
Millisekunden (als positive Ganzzahl) seit dem vorherigen Löschen vergangen
ist und das Lesen weiterer Eingaben blockieren würde. Dies kann nützlich
sein, wenn \fBxz\fP zum Komprimieren von über das Netzwerk eingehenden Daten
verwendet wird. Kleine \fIZeit\fP\-Werte machen die Daten unmittelbar nach dem
Empfang nach einer kurzen Verzögerung verfügbar, während große \fIZeit\fP\-Werte
ein besseres Kompressionsverhältnis bewirken.
.IP ""
Dieses Funktionsmerkmal ist standardmäßig deaktiviert. Wenn diese Option
mehrfach angegeben wird, ist die zuletzt angegebene wirksam. Für die Angabe
der \fIZeit\fP kann der spezielle Wert \fB0\fP verwendet werden, um dieses
Funktionsmerkmal explizit zu deaktivieren.
.IP ""
Dieses Funktionsmerkmal ist außerhalb von POSIX\-Systemen nicht verfügbar.
.IP ""
.\" FIXME
\fBDieses Funktionsmerkmal ist noch experimentell.\fP Gegenwärtig ist \fBxz\fP
aufgrund der Art und Weise, wie \fBxz\fP puffert, für Dekompression in Echtzeit
ungeeignet.
.TP 
\fB\-\-memlimit\-compress=\fP\fIGrenze\fP
legt eine Grenze für die Speichernutzung bei der Kompression fest. Wenn
diese Option mehrmals angegeben wird, ist die zuletzt angegebene wirksam.
.IP ""
Falls die Kompressionseinstellungen die \fIGrenze\fP überschreiten, versucht
\fBxz\fP, die Einstellungen nach unten anzupassen, so dass die Grenze nicht
mehr überschritten 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
\fIGrenze\fP überschreitet, und schlussendlich die Reduzierung der Größe des
LZMA2\-Wörterbuchs.
.IP ""
Beim Komprimieren mit \fB\-\-format=raw\fP oder falls \fB\-\-no\-adjust\fP angegeben
wurde, wird nur die Anzahl der Threads reduziert, da nur so die komprimierte
Ausgabe nicht beeinflusst wird.
.IP ""
Falls die \fIGrenze\fP nicht anhand der vorstehend beschriebenen Anpassungen
gesetzt werden kann, wird ein Fehler angezeigt und \fBxz\fP wird mit dem
Exit\-Status 1 beendet.
.IP ""
Die \fIGrenze\fP kann auf verschiedene Arten angegeben werden:
.RS
.IP \(bu 3
Die \fIGrenze\fP kann ein absoluter Wert in Byte sein. Ein Suffix wie \fBMiB\fP
kann dabei hilfreich sein. Beispiel: \fB\-\-memlimit\-compress=80MiB\fP.
.IP \(bu 3
Die \fIGrenze\fP kann als Prozentsatz des physischen Gesamtspeichers (RAM)
angegeben werden. Dies ist insbesondere nützlich, wenn in einem
Shell\-Initialisierungsskript, das mehrere unterschiedliche Rechner gemeinsam
verwenden, die Umgebungsvariable \fBXZ_DEFAULTS\fP gesetzt ist. Auf diese Weise
ist die Grenze auf Systemen mit mehr Speicher höher. Beispiel:
\fB\-\-memlimit\-compress=70%\fP
.IP \(bu 3
Mit \fB0\fP kann die \fIGrenze\fP auf den Standardwert zurückgesetzt werden. Dies
ist gegenwärtig gleichbedeutend mit dem Setzen der \fIGrenze\fP auf \fBmax\fP
(keine Speicherbegrenzung).
.RE
.IP ""
Für die 32\-Bit\-Version von \fBxz\fP gibt es einen Spezialfall: Falls die Grenze
über \fB4020\ MiB\fP liegt, wird die \fIGrenze\fP auf \fB4020\ MiB\fP gesetzt. Auf
MIPS32 wird stattdessen \fB2000\ MB\fP verwendet (die Werte \fB0\fP und \fBmax\fP
werden hiervon nicht beeinflusst; für die Dekompression gibt es keine
vergleichbare Funktion). Dies kann hilfreich sein, wenn ein
32\-Bit\-Executable auf einen 4\ GiB großen Adressraum (2 GiB auf MIPS32)
zugreifen kann, wobei wir hoffen wollen, dass es in anderen Situationen
keine negativen Effekte hat.
.IP ""
Siehe auch den Abschnitt \fBSpeicherbedarf\fP.
.TP 
\fB\-\-memlimit\-decompress=\fP\fIGrenze\fP
legt eine Begrenzung des Speicherverbrauchs für die Dekompression fest. Dies
beeinflusst auch den Modus \fB\-\-list\fP. Falls die Aktion nicht ausführbar ist,
ohne die \fIGrenze\fP zu überschreiten, gibt \fBxz\fP eine Fehlermeldung aus und
die Dekompression wird fehlschlagen. Siehe \fB\-\-memlimit\-compress=\fP\fIGrenze\fP
zu möglichen Wegen, die \fIGrenze\fP anzugeben.
.TP 
\fB\-\-memlimit\-mt\-decompress=\fP\fIGrenze\fP
legt eine Begrenzung des Speicherverbrauchs für Multithread\-Dekompression
fest. Dies beeinflusst lediglich die Anzahl der Threads; \fBxz\fP wird dadurch
niemals die Dekompression einer Datei verweigern. Falls die \fIGrenze\fP für
jegliches Multithreading zu niedrig ist, wird sie ignoriert und \fBxz\fP setzt
im Einzelthread\-modus fort. Beachten Sie auch, dass bei der Verwendung von
\fB\-\-memlimit\-decompress\fP dies stets sowohl auf den Einzelthread\-als auch auf
den Multithread\-Modus angewendet wird und so die effektive \fIGrenze\fP für den
Multithread\-Modus niemals höher sein wird als die mit
\fB\-\-memlimit\-decompress\fP gesetzte Grenze.
.IP ""
Im Gegensatz zu anderen Optionen zur Begrenzung des Speicherverbrauchs hat
\fB\-\-memlimit\-mt\-decompress=\fP\fIGrenze\fP eine systemspezifisch vorgegebene
\fIGrenze\fP. Mit \fBxz \-\-info\-memory\fP können Sie deren aktuellen Wert anzeigen
lassen.
.IP ""
Diese Option und ihr Standardwert existieren, weil die unbegrenzte
threadbezogene Dekompression bei einigen Eingabedateien zu unglaublich
großem Speicherverbrauch führen würde. Falls die vorgegebene \fIGrenze\fP auf
Ihrem System zu niedrig ist, können Sie die \fIGrenze\fP durchaus erhöhen, aber
setzen Sie sie niemals auf einen Wert größer als die Menge des nutzbaren
Speichers, da \fBxz\fP 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.
.IP ""
Siehe \fB\-\-memlimit\-compress=\fP\fIGrenze\fP für mögliche Wege zur Angabe der
\fIGrenze\fP.  Sezen der \fIGrenze\fP auf \fB0\fP setzt die \fIGrenze\fP auf den
vorgegebenen systemspezifischen Wert zurück.
.TP 
\fB\-M\fP \fIGrenze\fP, \fB\-\-memlimit=\fP\fIGrenze\fP, \fB\-\-memory=\fP\fIGrenze\fP
Dies ist gleichbedeutend mit \fB\-\-memlimit\-compress=\fP\fIGrenze\fP
\fB\-\-memlimit\-decompress=\fP\fIGrenze\fP \fB\-\-memlimit\-mt\-decompress=\fP\fIGrenze\fP.
.TP 
\fB\-\-no\-adjust\fP
zeigt einen Fehler an und beendet, falls die Grenze der Speichernutzung
nicht ohne Änderung der Einstellungen, welche die komprimierte Ausgabe
beeinflussen, berücksichtigt werden kann. Das bedeutet, dass \fBxz\fP daran
gehindert wird, den Encoder vom Multithread\-Modus in den Einzelthread\-Modus
zu versetzen und die Größe des LZMA2\-Wörterbuchs 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.
.IP ""
Die automatische Anpassung ist beim Erzeugen von Rohdatenströmen
(\fB\-\-format=raw\fP) immer deaktiviert.
.TP 
\fB\-T\fP \fIThreads\fP, \fB\-\-threads=\fP\fIThreads\fP
gibt die Anzahl der zu verwendenden Arbeits\-Threads an. Wenn Sie \fIThreads\fP
auf einen speziellen Wert \fB0\fP setzen, verwendet \fBxz\fP maximal so viele
Threads, wie der/die Prozessor(en) im System untestützen. Die tatsächliche
Anzahl kann geringer sein als die angegebenen \fIThreads\fP, wenn die
Eingabedatei nicht groß genug für Threading mit den gegebenen Einstellungen
ist oder wenn mehr Threads die Speicherbegrenzung übersteigen würden.
.IP ""
Die Multithread\- bzw. Einzelthread\-Kompressoren erzeugen unterschiedliche
Ausgaben. Der Einzelthread\-Kompressor erzeugt die geringste Dateigröße, aber
nur die Ausgabe des Multithread\-Kompressors kann mit mehreren Threads wieder
dekomprimiert werden. Das Setzen der Anzahl der \fIThreads\fP auf \fB1\fP wird den
Einzelthread\-Modus verwenden.  Das Setzen der Anzahl der \fIThreads\fP auf
einen anderen Wert einschließlich \fB0\fP verwendet den Multithread\-Kompressor,
und zwar sogar dann, wenn das System nur einen einzigen Hardware\-Thread
unterstützt (\fBxz\fP 5.2.x verwendete in diesem Fall noch den
Einzelthread\-Modus).
.IP ""
Um den Multithread\-Modus mit nur einem einzigen Thread zu verwenden, setzen
Sie die Anzahl der \fIThreads\fP auf \fB+1\fP. Das Präfix \fB+\fP hat mit Werten
verschieden von \fB1\fP keinen Effekt. Eine Begrenzung des Speicherverbrauchs
kann \fBxz\fP dennoch veranlassen, den Einzelthread\-Modus zu verwenden, außer
wenn \fB\-\-no\-adjust\fP verwendet wird. Die Unterstützung für das Präfix \fB+\fP
wurde in \fBxz\fP 5.4.0 hinzugefügt.
.IP ""
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
\fBxz\fP niemals an der Kompression oder Dekompression hindern. Diese
vorgegebene weiche Grenze veranlasst \fBxz\fP nicht, vom Multithread\-Modus in
den Einzelthread\-Modus zu wechseln. Die aktiven Grenzen können Sie mit dem
Befehl \fBxz \-\-info\-memory\fP anzeigen lassen.
.IP ""
Die gegenwärtig einzige Threading\-Methode teilt die Eingabe in Blöcke und
komprimiert diese unabhängig voneinander. Die vorgegebene Blockgröße ist von
der Kompressionsstufe abhängig und kann mit der Option
\fB\-\-block\-size=\fP\fIGröße\fP außer Kraft gesetzt werden.
.IP ""
Eine thread\-basierte Dekompression wird nur bei Dateien funktionieren, die
mehrere Blöcke mit Größeninformationen in deren Headern enthalten. Alle im
Multi\-Thread\-Modus komprimierten Dateien, die groß genug sind, erfüllen
diese Bedingung, im Einzel\-Thread\-Modus komprimierte Dateien dagegen nicht,
selbst wenn \fB\-\-block\-size=\fP\fIGröße\fP verwendet wurde.
.
.SS "Benutzerdefinierte Filterketten für die Kompression"
Eine benutzerdefinierte Filterkette ermöglicht die Angabe detaillierter
Kompressionseinstellungen, anstatt von den Voreinstellungen auszugehen. Wenn
eine benutzerdefinierte Filterkette angegeben wird, werden die vorher in der
Befehlszeile angegebenen Voreinstellungsoptionen (\fB\-0\fP … \fB\-9\fP und
\fB\-\-extreme\fP) außer 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 außer Kraft gesetzt.
.PP
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 zulässig, aber typischerweise besteht eine Filterkette nur aus einem
oder zwei Filtern.
.PP
Bei vielen Filtern ist die Positionierung in der Filterkette eingeschränkt:
Einige Filter sind nur als letzte in der Kette verwendbar, einige können
nicht als letzte Filter gesetzt werden, und andere funktionieren an
beliebiger Stelle. Abhängig von dem Filter ist diese Beschränkung entweder
auf das Design des Filters selbst zurückzuführen oder ist aus
Sicherheitsgründen vorhanden.
.PP
Eine benutzerdefinierte Filterkette wird durch eine oder mehrere
Filteroptionen in der Reihenfolge angegeben, in der sie in der Filterkette
wirksam werden sollen. Daher ist die Reihenfolge der Filteroptionen von
signifikanter Bedeutung! Beim Dekodieren von Rohdatenströmen
(\fB\-\-format=raw\fP) wird die Filterkette in der gleichen Reihenfolge angegeben
wie bei der Kompression.
.PP
Filter akzeptieren filterspezifische \fIOptionen\fP in einer durch Kommata
getrennten Liste. Zusätzliche Kommata in den \fIOptionen\fP werden
ignoriert. Jede Option hat einen Standardwert, daher brauchen Sie nur jene
anzugeben, die Sie ändern wollen.
.PP
Um die gesamte Filterkette und die \fIOptionen\fP anzuzeigen, rufen Sie \fBxz \-vv\fP auf (was gleichbedeutend mit der zweimaligen Angabe von \fB\-\-verbose\fP
ist). Dies funktioniert auch zum Betrachten der von den Voreinstellungen
verwendeten Filterkettenoptionen.
.TP 
\fB\-\-lzma1\fP[\fB=\fP\fIOptionen\fP]
.PD 0
.TP 
\fB\-\-lzma2\fP[\fB=\fP\fIOptionen\fP]
.PD
fügt LZMA1\- oder LZMA2\-Filter zur Filterkette hinzu. Diese Filter können nur
als letzte Filter in der Kette verwendet werden.
.IP ""
LZMA1 ist ein veralteter Filter, welcher nur wegen des veralteten
\&\fB.lzma\fP\-Dateiformats unterstützt wird, welches nur LZMA1 unterstützt. LZMA2
ist eine aktualisierte Version von LZMA1, welche einige praktische Probleme
von LZMA1 behebt. Das \fB.xz\fP\-Format verwendet LZMA2 und unterstützt LZMA1
gar nicht. Kompressionsgeschwindigkeit und \-verhältnis sind bei LZMA1 und
LZMA2 praktisch gleich.
.IP ""
LZMA1 und LZMA2 haben die gleichen \fIOptionen\fP:
.RS
.TP 
\fBpreset=\fP\fIVoreinstellung\fP
setzt alle LZMA1\- oder LZMA2\-\fIOptionen\fP auf die \fIVoreinstellung\fP
zurück. Diese \fIVoreinstellung\fP wird in Form einer Ganzzahl angegeben, der
ein aus einem einzelnen Buchstaben bestehender Voreinstellungsmodifikator
folgen kann. Die Ganzzahl kann \fB0\fP bis \fB9\fP sein, entsprechend den
Befehlszeilenoptionen \fB\-0\fP … \fB\-9\fP. Gegenwärtig ist \fBe\fP der einzige
unterstützte Modifikator, was \fB\-\-extreme\fP entspricht. Wenn keine
\fBVoreinstellung\fP angegeben ist, werden die Standardwerte der LZMA1\- oder
LZMA2\-\fIOptionen\fP der Voreinstellung \fB6\fP entnommen.
.TP 
\fBdict=\fP\fIGröße\fP
Die \fIGröße\fP des Wörterbuchs (Chronikpuffers) gibt an, wie viel Byte der
kürzlich verarbeiteten unkomprimierten Daten im Speicher behalten werden
sollen. Der Algorithmus versucht, sich wiederholende Byte\-Abfolgen
(Übereinstimmungen) in den unkomprimierten Daten zu finden und diese durch
Referenzen zu den Daten zu ersetzen, die sich gegenwärtig im Wörterbuch
befinden. Je größer das Wörterbuch, umso größer ist die Chance, eine
Übereinstimmung zu finden. Daher bewirkt eine Erhöhung der \fIGröße\fP des
Wörterbuchs üblicherweise ein besseres Kompressionsverhältnis, aber ein
Wörterbuch, das größer ist als die unkomprimierte Datei, wäre
Speicherverschwendung.
.IP ""
Typische Wörterbuch\-\fIGrößen\fP liegen im Bereich von 64\ KiB bis 64\ MiB. Das
Minimum ist 4\ KiB. Das Maximum für die Kompression ist gegenwärtig 1.5\ GiB
(1536\ MiB). Bei der Dekompression wird bereits eine Wörterbuchgröße bis zu
4\ GiB minus 1 Byte unterstützt, welche das Maximum für die LZMA1\- und
LZMA2\-Datenstromformate ist.
.IP ""
Die \fIGröße\fP des Wörterbuchs und der Übereinstimmungsfinder (\fIÜf\fP)
bestimmen zusammen den Speicherverbrauch des LZMA1\- oder
LZMA2\-Kodierers. Bei der Dekompression ist ein Wörterbuch der gleichen
\fIGröße\fP (oder ein noch größeres) wie bei der Kompression erforderlich,
daher wird der Speicherverbrauch des Dekoders durch die Größe des bei der
Kompression verwendeten Wörterbuchs bestimmt. Die \fB.xz\fP\-Header speichern
die \fIGröße\fP des Wörterbuchs entweder als 2^\fIn\fP oder 2^\fIn\fP + 2^(\fIn\fP\-1),
so dass diese \fIGrößen\fP für die Kompression etwas bevorzugt werden. Andere
\fIGrößen\fP werden beim Speichern in den \fB.xz\fP\-Headern aufgerundet.
.TP 
\fBlc=\fP\fIlc\fP
gibt die Anzahl der literalen Kontextbits an. Das Minimum ist 0 und das
Maximum 4; der Standardwert ist 3. Außerdem darf die Summe von \fIlc\fP und
\fIlp\fP nicht größer als 4 sein.
.IP ""
Alle Bytes, die nicht als Übereinstimmungen kodiert werden können, werden
als Literale kodiert. Solche Literale sind einfache 8\-bit\-Bytes, die jeweils
für sich kodiert werden.
.IP ""
Bei der Literalkodierung wird angenommen, dass die höchsten \fIlc\fP\-Bits des
zuvor unkomprimierten Bytes mit dem nächsten Byte in Beziehung stehen. Zum
Beispiel folgt in typischen englischsprachigen Texten auf einen
Großbuchstaben ein Kleinbuchstabe und auf einen Kleinbuchstaben
üblicherweise wieder ein Kleinbuchstabe. Im US\-ASCII\-Zeichensatz sind die
höchsten drei Bits 010 für Großbuchstaben und 011 für Kleinbuchstaben. Wenn
\fIlc\fP mindestens 3 ist, kann die literale Kodierung diese Eigenschaft der
unkomprimierten Daten ausnutzen.
.IP ""
Der Vorgabewert (3) ist üblicherweise gut. Wenn Sie die maximale Kompression
erreichen wollen, versuchen Sie \fBlc=4\fP. Manchmal hilft es ein wenig, doch
manchmal verschlechtert es die Kompression. Im letzteren Fall versuchen Sie
zum Beispiel auch\& \fBlc=2\fP.
.TP 
\fBlp=\fP\fIlp\fP
gibt die Anzahl der literalen Positionsbits an. Das Minimum ist 0 und das
Maximum 4; die Vorgabe ist 0.
.IP ""
\fILp\fP beeinflusst, welche Art der Ausrichtung der unkomprimierten Daten beim
Kodieren von Literalen angenommen wird. Siehe \fIpb\fP weiter unten für weitere
Informationen zur Ausrichtung.
.TP 
\fBpb=\fP\fIAnzahl\fP
legt die Anzahl der Positions\-Bits fest. Das Minimum ist 0 und das Maximum
4; Standard ist 2.
.IP ""
\fIPb\fP beeinflusst, welche Art der Ausrichtung der unkomprimierten Daten
generell angenommen wird. Standardmäßig wird eine Vier\-Byte\-Ausrichtung
angenommen (2^\fIpb\fP=2^2=4), was oft eine gute Wahl ist, wenn es keine
bessere Schätzung gibt.
.IP ""
Wenn die Ausrichtung bekannt ist, kann das entsprechende Setzen von \fIpb\fP
die Dateigröße ein wenig verringern. Wenn Textdateien zum Beispiel eine
Ein\-Byte\-Ausrichtung haben (US\-ASCII, ISO\-8859\-*, UTF\-8), kann das Setzen
von \fBpb=0\fP die Kompression etwas verbessern. Für UTF\-16\-Text ist \fBpb=1\fP
eine gute Wahl. Wenn die Ausrichtung eine ungerade Zahl wie beispielsweise 3
Byte ist, könnte \fBpb=0\fP die beste Wahl sein.
.IP ""
Obwohl die angenommene Ausrichtung mit \fIpb\fP und \fIlp\fP angepasst werden
kann, bevorzugen LZMA1 und LZMA2 noch etwas die 16\-Byte\-Ausrichtung. Das
sollten Sie vielleicht beim Design von Dateiformaten berücksichtigen, die
wahrscheinlich oft mit LZMA1 oder LZMA2 komprimiert werden.
.TP 
\fBmf=\fP\fIÜf\fP
Der Übereinstimmungsfinder hat einen großen Einfluss auf die Geschwindigkeit
des Kodierers, den Speicherbedarf und das
Kompressionsverhältnis. Üblicherweise sind auf Hash\-Ketten basierende
Übereinstimmungsfinder schneller als jene, die mit Binärbäumen arbeiten. Die
Vorgabe hängt von der \fIVoreinstellungsstufe\fP ab: 0 verwendet \fBhc3\fP, 1\-3
verwenden \fBhc4\fP und der Rest verwendet \fBbt4\fP.
.IP ""
Die folgenden Übereinstimmungsfinder werden unterstützt. Die Formeln zur
Ermittlung des Speicherverbrauchs sind grobe Schätzungen, die der Realität
am nächsten kommen, wenn \fIWörterbuch\fP eine Zweierpotenz ist.
.RS
.TP 
\fBhc3\fP
Hash\-Kette mit 2\- und 3\-Byte\-Hashing
.br
Minimalwert für \fInice\fP: 3
.br
Speicherbedarf:
.br
\fIdict\fP * 7,5 (falls \fIdict\fP <= 16 MiB);
.br
\fIdict\fP * 5,5 + 64 MiB (falls \fIdict\fP > 16 MiB)
.TP 
\fBhc4\fP
Hash\-Kette mit 2\-, 3\- und 4\-Byte\-Hashing
.br
Minimaler Wert für \fInice\fP: 4
.br
Speicherbedarf:
.br
\fIdict\fP * 7,5 (falls \fIdict\fP <= 32 MiB ist);
.br
\fIdict\fP * 6,5 (falls \fIdict\fP > 32 MiB ist)
.TP 
\fBbt2\fP
Binärbaum mit 2\-Byte\-Hashing
.br
Minimaler Wert für \fInice\fP: 2
.br
Speicherverbrauch: \fIdict\fP * 9.5
.TP 
\fBbt3\fP
Binärbaum mit 2\- und 3\-Byte\-Hashing
.br
Minimalwert für \fInice\fP: 3
.br
Speicherbedarf:
.br
\fIdict\fP * 11,5 (falls \fIdict\fP <= 16 MiB ist);
.br
\fIdict\fP * 9,5 + 64 MiB (falls \fIdict\fP > 16 MiB ist)
.TP 
\fBbt4\fP
Binärbaum mit 2\-, 3\- und 4\-Byte\-Hashing
.br
Minimaler Wert für \fInice\fP: 4
.br
Speicherbedarf:
.br
\fIdict\fP * 11,5 (falls \fIdict\fP <= 32 MiB ist);
.br
\fIdict\fP * 10,5 (falls \fIdict\fP > 32 MiB ist)
.RE
.TP 
\fBmode=\fP\fIModus\fP
gibt die Methode zum Analysieren der vom Übereinstimmungsfinder gelieferten
Daten an. Als \fIModi\fP werden \fBfast\fP und \fBnormal\fP unterstützt. Die Vorgabe
ist \fBfast\fP für die \fIVoreinstellungsstufen\fP 0\-3 und \fBnormal\fP für die
\fIVoreinstellungsstufen\fP 4\-9.
.IP ""
Üblicherweise wird \fBfast\fP mit Hashketten\-basierten Übereinstimmungsfindern
und \fBnormal\fP mit Binärbaum\-basierten Übereinstimmungsfindern verwendet. So
machen es auch die \fIVoreinstellungsstufen\fP.
.TP 
\fBnice=\fP\fInice\fP
gibt an, was als annehmbarer Wert für eine Übereinstimmung angesehen werden
kann. Wenn eine Übereinstimmung gefunden wird, die mindestens diesen
\fInice\fP\-Wert hat, sucht der Algorithmus nicht weiter nach besseren
Übereinstimmungen.
.IP ""
Der \fInice\fP\-Wert kann 2\-273 Byte sein. Höhere Werte tendieren zu einem
besseren Kompressionsverhältnis, aber auf Kosten der Geschwindigkeit. Die
Vorgabe hängt von der \fIVoreinstellungsstufe\fP ab.
.TP 
\fBdepth=\fP\fITiefe\fP
legt die maximale Suchtiefe im Übereinstimmungsfinder fest. Vorgegeben ist
der spezielle Wert 0, der den Kompressor veranlasst, einen annehmbaren Wert
für \fITiefe\fP aus \fIÜf\fP und \fInice\fP\-Wert zu bestimmen.
.IP ""
Die angemessene \fITiefe\fP für Hash\-Ketten ist 4\-100 und 16\-1000 für
Binärbäume. Hohe Werte für die \fITiefe\fP können den Kodierer bei einigen
Dateien extrem verlangsamen. Vermeiden Sie es, die \fITiefe\fP über einen Wert
von 100 zu setzen, oder stellen Sie sich darauf ein, die Kompression
abzubrechen, wenn sie zu lange dauert.
.RE
.IP ""
Beim Dekodieren von Rohdatenströmen (\fB\-\-format=raw\fP) benötigt LZMA2 nur die
Wörterbuch\-\fIGröße\fP.  LZMA1 benötigt außerdem \fIlc\fP, \fIlp\fP und \fIpb\fP.
.TP 
\fB\-\-x86\fP[\fB=\fP\fIOptionen\fP]
.PD 0
.TP 
\fB\-\-arm\fP[\fB=\fP\fIOptionen\fP]
.TP 
\fB\-\-armthumb\fP[\fB=\fP\fIOptionen\fP]
.TP 
\fB\-\-arm64\fP[\fB=\fP\fIOptionen\fP]
.TP 
\fB\-\-powerpc\fP[\fB=\fP\fIOptionen\fP]
.TP 
\fB\-\-ia64\fP[\fB=\fP\fIOptionen\fP]
.TP 
\fB\-\-sparc\fP[\fB=\fP\fIOptionen\fP]
.PD
fügt ein »Branch/Call/Jump«\-(BCJ\-)Filter zur Filterkette hinzu. Diese Filter
können nicht als letzter Filter in der Filterkette verwendet werden.
.IP ""
Ein BCJ\-Filter wandelt relative Adressen im Maschinencode in deren absolute
Gegenstücke um. Die Datengröße wird dadurch nicht geändert, aber die
Redundanz erhöht, was LZMA2 dabei helfen kann, eine um 10 bis 15% kleinere
\&\fB.xz\fP\-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 Kompressionsverhältnis etwas schlechter werden
könnte. Die BCJ\-Filter sind sehr schnell und verbrauchen nur wenig mehr
Speicher.
.IP ""
Diese BCJ\-Filter haben bekannte Probleme mit dem Kompressionsverhältnis:
.RS
.IP \(bu 3
In einigen Dateitypen, die ausführbaren Code enthalten (zum Beispiel
Objektdateien, statische Bibliotheken und Linux\-Kernelmodule), sind die
Adressen in den Anweisungen mit Füllwerten gefüllt. Diese BCJ\-Filter führen
dennoch die Adressumwandlung aus, wodurch die Kompression bei diesen Dateien
schlechter wird.
.IP \(bu 3
Falls ein BCJ\-Filter auf ein Archiv angewendet wird, ist es möglich, dass
das Kompressionsverhältnis schlechter als ohne Filter wird. Falls es
beispielsweise ähnliche oder sogar identische ausführbare Dateien gibt, dann
werden diese durch die Filterung wahrscheinlich »unähnlicher« und
verschlechtern dadurch das Kompressionsverhältnis. Der Inhalt
nicht\-ausführbarer Dateien im gleichen Archiv kann sich ebenfalls darauf
auswirken. In der Praxis werden Sie durch Versuche mit oder ohne BCJ\-Filter
selbst herausfinden müssen, was situationsbezogen besser ist.
.RE
.IP ""
Verschiedene Befehlssätze haben unterschiedliche Ausrichtungen: Die
ausführbare Datei muss in den Eingabedateien einem Vielfachen dieses Wertes
entsprechen, damit dieser Filter funktioniert.
.RS
.RS
.PP
.TS
tab(;);
l n l
l n l.
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;
.TE
.RE
.RE
.IP ""
Da die BCJ\-gefilterten Daten üblicherweise mit LZMA2 komprimiert sind, kann
das Kompressionsverhältnis dadurch etwas verbessert werden, dass die
LZMA2\-Optionen so gesetzt werden, dass sie der Ausrichtung des gewählten
BCJ\-Filters entsprechen. Zum Beispiel ist es beim IA\-64\-Filter eine gute
Wahl, \fBpb=4\fP oder sogar \fBpb=4,lp=4,lc=0\fP mit LZMA2 zu setzen (2^4=16). Der
x86\-Filter bildet dabei eine Ausnahme; Sie sollten bei der für LZMA2
voreingestellten 4\-Byte\-Ausrichtung bleiben, wenn Sie x86\-Binärdateien
komprimieren.
.IP ""
Alle BCJ\-Filter unterstützen die gleichen \fIOptionen\fP:
.RS
.TP 
\fBstart=\fP\fIVersatz\fP
gibt den Start\-\fIVersatz\fP an, der bei der Umwandlung zwischen relativen und
absoluten Adressen verwendet wird. Der \fIVersatz\fP 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
\fIVersatzes\fP ist fast immer unnütz.
.RE
.TP 
\fB\-\-delta\fP[\fB=\fP\fIOptionen\fP]
fügt den Delta\-Filter zur Filterkette hinzu. Der Delta\-Filter kann nicht als
letzter Filter in der Filterkette verwendet werden.
.IP ""
Gegenwärtig wird nur eine einfache, Byte\-bezogene Delta\-Berechnung
unterstützt. Beim Komprimieren von zum Beispiel unkomprimierten
Bitmap\-Bildern oder unkomprimierten PCM\-Audiodaten kann es jedoch sinnvoll
sein. Dennoch können für spezielle Zwecke entworfene Algorithmen deutlich
bessere Ergebnisse als Delta und LZMA2 liefern. Dies trifft insbesondere auf
Audiodaten zu, die sich zum Beispiel mit \fBflac\fP(1) schneller und besser
komprimieren lassen.
.IP ""
Unterstützte \fIOptionen\fP:
.RS
.TP 
\fBdist=\fP\fIAbstand\fP
gibt den \fIAbstand\fP der Delta\-Berechnung in Byte an. Zulässige Werte für den
\fIAbstand\fP sind 1 bis 256. Der Vorgabewert ist 1.
.IP ""
Zum Beispiel wird mit \fBdist=2\fP und der 8\-Byte\-Eingabe A1 B1 A2 B3 A3 B5 A4
B7 die Ausgabe A1 B1 01 02 01 02 01 02 sein.
.RE
.
.SS "Andere Optionen"
.TP 
\fB\-q\fP, \fB\-\-quiet\fP
unterdrückt Warnungen und Hinweise. Geben Sie dies zweimal an, um auch
Fehlermeldungen zu unterdrücken. Diese Option wirkt sich nicht auf den
Exit\-Status aus. Das bedeutet, das selbst bei einer unterdrückten Warnung
der Exit\-Status zur Anzeige einer Warnung dennoch verwendet wird.
.TP 
\fB\-v\fP, \fB\-\-verbose\fP
bewirkt ausführliche Ausgaben. Wenn die Standardfehlerausgabe mit einem
Terminal verbunden ist, zeigt \fBxz\fP den Fortschritt an. Durch zweimalige
Angabe von \fB\-\-verbose\fP wird die Ausgabe noch ausführlicher.
.IP ""
Der Fortschrittsanzeiger stellt die folgenden Informationen dar:
.RS
.IP \(bu 3
Der Prozentsatz des Fortschritts wird angezeigt, wenn die Größe der
Eingabedatei bekannt ist. Das bedeutet, dass der Prozentsatz in
Weiterleitungen (Pipes) nicht angezeigt werden kann.
.IP \(bu 3
Menge der erzeugten komprimierten Daten (bei der Kompression) oder der
verarbeiteten Daten (bei der Dekompression).
.IP \(bu 3
Menge der verarbeiteten unkomprimierten Daten (bei der Kompression) oder der
erzeugten Daten (bei der Dekompression).
.IP \(bu 3
Kompressionsverhältnis, das mittels Dividieren der Menge der bisher
komprimierten Daten durch die Menge der bisher verarbeiteten unkomprimierten
Daten ermittelt wird.
.IP \(bu 3
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 \fBxz\fP mit der Verarbeitung der Datei
begonnen hat.
.IP \(bu 3
Die vergangene Zeit im Format M:SS oder H:MM:SS.
.IP \(bu 3
Die geschätzte verbleibende Zeit wird nur angezeigt, wenn die Größe der
Eingabedatei bekannt ist und bereits einige Sekunden vergangen sind, nachdem
\fBxz\fP mit der Verarbeitung der Datei begonnen hat. Die Zeit wird in einem
weniger präzisen Format ohne Doppelpunkte angezeigt, zum Beispiel 2 min 30
s.
.RE
.IP ""
Wenn die Standardfehlerausgabe kein Terminal ist, schreibt \fBxz\fP mit
\fB\-\-verbose\fP nach dem Komprimieren oder Dekomprimieren der Datei in einer
einzelnen Zeile den Dateinamen, die komprimierte Größe, die unkomprimierte
Größe, das Kompressionsverhältnis 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 außerdem der Prozentsatz des
erreichten Verarbeitungsfortschritts aufgenommen, sofern die Größe der
Eingabedatei bekannt ist.
.TP 
\fB\-Q\fP, \fB\-\-no\-warn\fP
setzt den Exit\-Status nicht auf 2, selbst wenn eine Bedingung erfüllt ist,
die eine Warnung gerechtfertigt hätte. Diese Option wirkt sich nicht auf die
Ausführlichkeitsstufe aus, daher müssen sowohl \fB\-\-quiet\fP als auch
\fB\-\-no\-warn\fP angegeben werden, um einerseits keine Warnungen anzuzeigen und
andererseits auch den Exit\-Status nicht zu ändern.
.TP 
\fB\-\-robot\fP
gibt Meldungen in einem maschinenlesbaren Format aus. Dadurch soll das
Schreiben von Frontends erleichtert werden, die \fBxz\fP anstelle von Liblzma
verwenden wollen, was in verschiedenen Skripten der Fall sein kann. Die
Ausgabe mit dieser aktivierten Option sollte über mehrere
\fBxz\fP\-Veröffentlichungen stabil sein. Details hierzu finden Sie im Abschnitt
\fBROBOTER\-MODUS\fP.
.TP 
\fB\-\-info\-memory\fP
zeigt in einem menschenlesbaren Format an, wieviel physischen Speicher (RAM)
und wie viele Prozessor\-Threads das System nach Annahme von \fBxz\fP hat, sowie
die Speicherbedarfsbegrenzung für Kompression und Dekompression, und beendet
das Programm erfolgreich.
.TP 
\fB\-h\fP, \fB\-\-help\fP
zeigt eine Hilfemeldung mit den am häufigsten genutzten Optionen an und
beendet das Programm erfolgreich.
.TP 
\fB\-H\fP, \fB\-\-long\-help\fP
zeigt eine Hilfemeldung an, die alle Funktionsmerkmale von \fBxz\fP beschreibt
und beendet das Programm erfolgreich.
.TP 
\fB\-V\fP, \fB\-\-version\fP
zeigt die Versionsnummer von \fBxz\fP und Liblzma in einem menschenlesbaren
Format an. Um eine maschinell auswertbare Ausgabe zu erhalten, geben Sie
\fB\-\-robot\fP vor \fB\-\-version\fP an.
.
.SH ROBOTER\-MODUS
Der Roboter\-Modus wird mit der Option \fB\-\-robot\fP aktiviert. Er bewirkt, dass
die Ausgabe von \fBxz\fP leichter von anderen Programmen ausgewertet werden
kann. Gegenwärtig wird \fB\-\-robot\fP nur zusammen mit \fB\-\-version\fP,
\fB\-\-info\-memory\fP und \fB\-\-list\fP unterstützt. In der Zukunft wird dieser Modus
auch für Kompression und Dekompression unterstützt.
.
.SS Version
\fBxz \-\-robot \-\-version\fP gibt die Versionsnummern von \fBxz\fP und Liblzma im
folgenden Format aus:
.PP
\fBXZ_VERSION=\fP\fIXYYYZZZS\fP
.br
\fBLIBLZMA_VERSION=\fP\fIXYYYZZZS\fP
.TP 
\fIX\fP
Hauptversion.
.TP 
\fIYYY\fP
Unterversion. Gerade Zahlen bezeichnen eine stabile Version. Ungerade Zahlen
bezeichnen Alpha\- oder Betaversionen.
.TP 
\fIZZZ\fP
Patch\-Stufe für stabile Veröffentlichungen oder einfach nur ein Zähler für
Entwicklungsversionen.
.TP 
\fIS\fP
Stabilität. 0 ist Alpha, 1 ist Beta und 2 ist stabil. \fIS\fP sollte immer 2
sein, wenn \fIYYY\fP eine gerade Zahl ist.
.PP
\fIXYYYZZZS\fP sind in beiden Zeilen gleich, sofern \fBxz\fP und Liblzma aus der
gleichen Veröffentlichung der XZ\-Utils stammen.
.PP
Beispiele: 4.999.9beta ist \fB49990091\fP und 5.0.0 is \fB50000002\fP.
.
.SS "Informationen zur Speicherbedarfsbegrenzung"
\fBxz \-\-robot \-\-info\-memory\fP gibt eine einzelne Zeile mit mehreren durch
Tabulatoren getrennten Spalten aus:
.IP 1. 4
Gesamter physischer Speicher (RAM) in Byte.
.IP 2. 4
Speicherbedarfsbegrenzung für die Kompression in Byte
(\fB\-\-memlimit\-compress\fP). Ein spezieller Wert von \fB0\fP bezeichnet die
Standardeinstellung, die im Einzelthread\-Modus bedeutet, dass keine
Begrenzung vorhanden ist.
.IP 3. 4
Speicherbedarfsbegrenzung für die Dekompression in Byte
(\fB\-\-memlimit\-decompress\fP). Ein spezieller Wert von \fB0\fP bezeichnet die
Standardeinstellung, die im Einzelthread\-Modus bedeutet, dass keine
Begrenzung vorhanden ist.
.IP 4. 4
Seit \fBxz\fP 5.3.4alpha: Die Speichernutzung für Multithread\-Dekompression in
Byte (\fB\-\-memlimit\-mt\-decompress\fP). Dies ist niemals \fB0\fP, da ein
systemspezifischer Vorgabewert (gezeigt in Spalte 5) verwendet wird, falls
keine Grenze ausdrücklich angegeben wurde. Dies ist außerdem niemals größer
als der Wert in in Spalte 3, selbst wenn mit \fB\-\-memlimit\-mt\-decompress\fP ein
größerer Wert angegeben wurde.
.IP 5. 4
Seit \fBxz\fP 5.3.4alpha: Eine systemspezifisch vorgegebene Begrenzung des
Speicherverbrauchs, die zur Begrenzung der Anzahl der Threads beim
Komprimieren mit automatischer Anzahl der Threads (\fB\-\-threads=0\fP) und wenn
keine Speicherbedarfsbegrenzung angegeben wurde (\fB\-\-memlimit\-compress\fP)
verwendet wird. Dies wird auch als Standardwert für
\fB\-\-memlimit\-mt\-decompress\fP verwendet.
.IP 6. 4
Seit \fBxz\fP 5.3.4alpha: Anzahl der verfügbaren Prozessorthreads.
.PP
In der Zukunft könnte die Ausgabe von \fBxz \-\-robot \-\-info\-memory\fP weitere
Spalten enthalten, aber niemals mehr als eine einzelne Zeile.
.
.SS Listenmodus
\fBxz \-\-robot \-\-list\fP 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:
.TP 
\fBname\fP
Dies ist stets die erste Zeile, wenn eine Datei aufgelistet wird. Die zweite
Spalte in der Zeile enthält den Dateinamen.
.TP 
\fBfile\fP
Diese Zeile enthält allgemeine Informationen zur \fB.xz\fP\-Datei. Diese Zeile
wird stets nach der \fBname\fP\-Zeile ausgegeben.
.TP 
\fBstream\fP
Dieser Zeilentyp wird nur verwendet, wenn \fB\-\-verbose\fP angegeben wurde. Es
gibt genau so viele \fBstream\fP\-Zeilen, wie Datenströme in der \fB.xz\fP\-Datei
enthalten sind.
.TP 
\fBblock\fP
Dieser Zeilentyp wird nur verwendet, wenn \fB\-\-verbose\fP angegeben wurde. Es
gibt so viele \fBblock\fP\-Zeilen, wie Blöcke in der \fB.xz\fP\-Datei. Die
\fBblock\fP\-Zeilen werden nach allen \fBstream\fP\-Zeilen angezeigt; verschiedene
Zeilentypen werden nicht verschachtelt.
.TP 
\fBsummary\fP
Dieser Zeilentyp wird nur verwendet, wenn \fB\-\-verbose\fP zwei Mal angegeben
wurde. Diese Zeile wird nach allen \fBblock\fP\-Zeilen ausgegeben. Wie die
\fBfile\fP\-Zeile enthält die \fBsummary\fP\-Zeile allgemeine Informationen zur
\&\fB.xz\fP\-Datei.
.TP 
\fBtotals\fP
Diese Zeile ist immer die letzte der Listenausgabe. Sie zeigt die
Gesamtanzahlen und \-größen an.
.PP
Die Spalten der \fBfile\fP\-Zeilen:
.PD 0
.RS
.IP 2. 4
Anzahl der Datenströme in der Datei
.IP 3. 4
Gesamtanzahl der Blöcke in den Datenströmen
.IP 4. 4
Komprimierte Größe der Datei
.IP 5. 4
Unkomprimierte Größe der Datei
.IP 6. 4
Das Kompressionsverhältnis, zum Beispiel \fB0.123\fP. Wenn das Verhältnis über
9.999 liegt, werden drei Minuszeichen (\fB\-\-\-\fP) anstelle des
Kompressionsverhältnisses angezeigt.
.IP 7. 4
Durch Kommata getrennte Liste der Namen der Integritätsprüfungen. Für die
bekannten Überprüfungstypen werden folgende Zeichenketten verwendet:
\fBNone\fP, \fBCRC32\fP, \fBCRC64\fP und \fBSHA\-256\fP. \fBUnbek.\fP\fIN\fP wird verwendet,
wobei \fIN\fP die Kennung der Überprüfung als Dezimalzahl angibt (ein\- oder
zweistellig).
.IP 8. 4
Gesamtgröße der Datenstromauffüllung in der Datei
.RE
.PD
.PP
Die Spalten der \fBstream\fP\-Zeilen:
.PD 0
.RS
.IP 2. 4
Datenstromnummer (der erste Datenstrom ist 1)
.IP 3. 4
Anzahl der Blöcke im Datenstrom
.IP 4. 4
Komprimierte Startposition
.IP 5. 4
Unkomprimierte Startposition
.IP 6. 4
Komprimierte Größe (schließt die Datenstromauffüllung nicht mit ein)
.IP 7. 4
Unkomprimierte Größe
.IP 8. 4
Kompressionsverhältnis
.IP 9. 4
Name der Integritätsprüfung
.IP 10. 4
Größe der Datenstromauffüllung
.RE
.PD
.PP
Die Spalten der \fBblock\fP\-Zeilen:
.PD 0
.RS
.IP 2. 4
Anzahl der in diesem Block enthaltenen Datenströme
.IP 3. 4
Blocknummer relativ zum Anfang des Datenstroms (der erste Block ist 1)
.IP 4. 4
Blocknummer relativ zum Anfang der Datei
.IP 5. 4
Komprimierter Startversatz relativ zum Beginn der Datei
.IP 6. 4
Unkomprimierter Startversatz relativ zum Beginn der Datei
.IP 7. 4
Komprimierte Gesamtgröße des Blocks (einschließlich Header)
.IP 8. 4
Unkomprimierte Größe
.IP 9. 4
Kompressionsverhältnis
.IP 10. 4
Name der Integritätsprüfung
.RE
.PD
.PP
Wenn \fB\-\-verbose\fP zwei Mal angegeben wurde, werden zusätzliche Spalten in
die \fBblock\fP\-Zeilen eingefügt. Diese werden mit einem einfachen \fB\-\-verbose\fP
nicht angezeigt, da das Ermitteln dieser Informationen viele Suchvorgänge
erfordert und daher recht langsam sein kann:
.PD 0
.RS
.IP 11. 4
Wert der Integritätsprüfung in hexadezimaler Notation
.IP 12. 4
Block\-Header\-Größe
.IP 13. 4
Block\-Schalter: \fBc\fP gibt an, dass die komprimierte Größe verfügbar ist, und
\fBu\fP gibt an, dass die unkomprimierte Größe verfügbar ist. Falls der
Schalter nicht gesetzt ist, wird stattdessen ein Bindestrich (\fB\-\fP)
angezeigt, um die Länge der Zeichenkette beizubehalten. In Zukunft könnten
neue Schalter am Ende der Zeichenkette hinzugefügt werden.
.IP 14. 4
Größe der tatsächlichen komprimierten Daten im Block. Ausgeschlossen sind
hierbei die Block\-Header, die Blockauffüllung und die Prüffelder.
.IP 15. 4
Größe des Speichers (in Byte), der zum Dekomprimieren dieses Blocks mit
dieser \fBxz\fP\-Version benötigt wird.
.IP 16. 4
Filterkette. Beachten Sie, dass die meisten der bei der Kompression
verwendeten Optionen nicht bekannt sein können, da in den \fB.xz\fP\-Headern nur
die für die Dekompression erforderlichen Optionen gespeichert sind.
.RE
.PD
.PP
Die Spalten der \fBsummary\fP\-Zeilen:
.PD 0
.RS
.IP 2. 4
Größe des Speichers (in Byte), der zum Dekomprimieren dieser Datei mit
dieser \fBxz\fP\-Version benötigt wird.
.IP 3. 4
\fByes\fP oder \fBno\fP geben an, ob in allen Block\-Headern sowohl die
komprimierte als auch die unkomprimierte Größe gespeichert ist.
.PP
\fISeit\fP \fBxz\fP \fI5.1.2alpha:\fP
.IP 4. 4
Minimale \fBxz\fP\-Version, die zur Dekompression der Datei erforderlich ist
.RE
.PD
.PP
Die Spalten der \fBtotals\fP\-Zeile:
.PD 0
.RS
.IP 2. 4
Anzahl der Datenströme
.IP 3. 4
Anzahl der Blöcke
.IP 4. 4
Komprimierte Größe
.IP 5. 4
Unkomprimierte Größe
.IP 6. 4
Durchschnittliches Kompressionsverhältnis
.IP 7. 4
Durch Kommata getrennte Liste der Namen der Integritätsprüfungen, die in den
Dateien präsent waren.
.IP 8. 4
Größe der Datenstromauffüllung
.IP 9. 4
Anzahl der Dateien. Dies dient dazu, die Reihenfolge der vorigen Spalten an
die in den \fBfile\fP\-Zeilen anzugleichen.
.PD
.RE
.PP
Wenn \fB\-\-verbose\fP zwei Mal angegeben wird, werden zusätzliche Spalten in die
\fBtotals\fP\-Zeile eingefügt:
.PD 0
.RS
.IP 10. 4
Maximale Größe des Speichers (in Byte), der zum Dekomprimieren der Dateien
mit dieser \fBxz\fP\-Version benötigt wird.
.IP 11. 4
\fByes\fP oder \fBno\fP geben an, ob in allen Block\-Headern sowohl die
komprimierte als auch die unkomprimierte Größe gespeichert ist.
.PP
\fISeit\fP \fBxz\fP \fI5.1.2alpha:\fP
.IP 12. 4
Minimale \fBxz\fP\-Version, die zur Dekompression der Datei erforderlich ist
.RE
.PD
.PP
Zukünftige Versionen könnten neue Zeilentypen hinzufügen, weiterhin könnten
auch in den vorhandenen Zeilentypen weitere Spalten hinzugefügt werden, aber
die existierenden Spalten werden nicht geändert.
.
.SH EXIT\-STATUS
.TP 
\fB0\fP
Alles ist in Ordnung.
.TP 
\fB1\fP
Ein Fehler ist aufgetreten.
.TP 
\fB2\fP
Es ist etwas passiert, das eine Warnung rechtfertigt, aber es sind keine
tatsächlichen Fehler aufgetreten.
.PP
In die Standardausgabe geschriebene Hinweise (keine Warnungen oder Fehler),
welche den Exit\-Status nicht beeinflussen.
.
.SH UMGEBUNGSVARIABLEN
\fBxz\fP wertet eine durch Leerzeichen getrennte Liste von Optionen in den
Umgebungsvariablen \fBXZ_DEFAULTS\fP und \fBXZ_OPT\fP aus (in dieser Reihenfolge),
bevor die Optionen aus der Befehlszeile ausgewertet werden. Beachten Sie,
dass beim Auswerten der Umgebungsvariablen nur Optionen berücksichtigt
werden; alle Einträge, die keine Optionen sind, werden stillschweigend
ignoriert. Die Auswertung erfolgt mit \fBgetopt_long\fP(3), welches auch für
die Befehlszeilenargumente verwendet wird.
.TP 
\fBXZ_DEFAULTS\fP
Benutzerspezifische oder systemweite Standardoptionen. Typischerweise werden
diese in einem Shell\-Initialisierungsskript gesetzt, um die
Speicherbedarfsbegrenzung von \fBxz\fP standardmäßig zu aktivieren. Außer bei
Shell\-Initialisierungsskripten und in ähnlichen Spezialfällen darf die
Variable \fBXZ_DEFAULTS\fP in Skripten niemals gesetzt oder außer Kraft gesetzt
werden.
.TP 
\fBXZ_OPT\fP
Dies dient der Übergabe von Optionen an \fBxz\fP, wenn es nicht möglich ist,
die Optionen direkt in der Befehlszeile von \fBxz\fP zu übergeben. Dies ist der
Fall, wenn \fBxz\fP von einem Skript oder Dienstprogramm ausgeführt wird, zum
Beispiel GNU \fBtar\fP(1):
.RS
.RS
.PP
.nf
\f(CWXZ_OPT=\-2v tar caf foo.tar.xz foo\fP
.fi
.RE
.RE
.IP ""
Skripte können \fBXZ_OPT\fP zum Beispiel zum Setzen skriptspezifischer
Standard\-Kompressionsoptionen verwenden. Es ist weiterhin empfehlenswert,
Benutzern die Außerkraftsetzung von \fBXZ_OPT\fP zu erlauben, falls dies
angemessen ist. Zum Beispiel könnte in \fBsh\fP(1)\-Skripten Folgendes stehen:
.RS
.RS
.PP
.nf
\f(CWXZ_OPT=${XZ_OPT\-"\-7e"} export XZ_OPT\fP
.fi
.RE
.RE
.
.SH "KOMPATIBILITÄT ZU DEN LZMA\-UTILS"
Die Befehlszeilensyntax von \fBxz\fP ist praktisch eine Obermenge der von
\fBlzma\fP, \fBunlzma\fP und \fBlzcat\fP in den LZMA\-Utils der Versionen 4.32.x. In
den meisten Fällen sollte es möglich sein, die LZMA\-Utils durch die XZ\-Utils
zu ersetzen, ohne vorhandene Skripte ändern zu müssen. Dennoch gibt es
einige Inkompatibilitäten, die manchmal Probleme verursachen können.
.
.SS "Voreinstellungsstufen zur Kompression"
Die Nummerierung der Voreinstellungsstufen der Kompression ist in \fBxz\fP und
den LZMA\-Utils unterschiedlich. Der wichtigste Unterschied ist die Zuweisung
der Wörterbuchgrößen zu den verschiedenen Voreinstellungsstufen. Die
Wörterbuchgröße ist etwa gleich dem Speicherbedarf bei der Dekompression.
.RS
.PP
.TS
tab(;);
c c c
c n n.
Stufe;xz;LZMA\-Utils
\-0;256 KiB;nicht verfügbar
\-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
.TE
.RE
.PP
Die Unterschiede in der Wörterbuchgröße 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 vergrößern:
.RS
.PP
.TS
tab(;);
c c c
c n n.
Stufe;xz;LZMA\-Utils 4.32.x
\-0;3 MiB;nicht verfügbar
\-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
.TE
.RE
.PP
Die standardmäßige Voreinstellungsstufe in den LZMA\-Utils ist \fB\-7\fP, während
diese in den XZ\-Utils \fB\-6\fP ist, daher verwenden beide standardmäßig ein 8
MiB großes Wörterbuch.
.
.SS "Vor\- und Nachteile von .lzma\-Dateien als Datenströme"
Die unkomprimierte Größe der Datei kann in den \fB.lzma\fP\-Headern gespeichert
werden. Die LZMA\-Utils tun das beim Komprimieren gewöhnlicher Dateien. Als
Alternative kann die unkomprimierte Größe 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 Größe unbekannt ist, was beispielsweise in Pipes
(Befehlsverkettungen) der Fall ist.
.PP
\fBxz\fP unterstützt die Dekompression von \fB.lzma\fP\-Dateien mit oder ohne
Nutzdatenende\-Markierung, aber alle von \fBxz\fP erstellten \fB.lzma\fP\-Dateien
verwenden diesen Nutzdatenende\-Markierung, wobei die unkomprimierte Größe in
den \fB.lzma\fP\-Headern als unbekannt markiert wird. Das könnte in einigen
unüblichen Situationen ein Problem sein. Zum Beispiel könnte ein
\&\fB.lzma\fP\-Dekompressor in einem Gerät mit eingebettetem System nur mit
Dateien funktionieren, deren unkomprimierte Größe bekannt ist. Falls Sie auf
dieses Problem stoßen, müssen Sie die LZMA\-Utils oder das LZMA\-SDK
verwenden, um \fB.lzma\fP\-Dateien mit bekannter unkomprimierter Größe zu
erzeugen.
.
.SS "Nicht unterstützte .lzma\-Dateien"
Das \fB.lzma\fP\-Format erlaubt \fIlc\fP\-Werte bis zu 8 und \fIlp\fP\-Werte bis zu
4. Die LZMA\-Utils können Dateien mit beliebigem \fIlc\fP und \fIlp\fP
dekomprimieren, aber erzeugen immer Dateien mit \fBlc=3\fP und \fBlp=0\fP. Das
Erzeugen von Dateien mit anderem \fIlc\fP und \fIlp\fP ist mit \fBxz\fP und mit dem
LZMA\-SDK möglich.
.PP
Die Implementation des LZMA\-Filters in liblzma setzt voraus, dass die Summe
von \fIlc\fP und \fIlp\fP nicht größer als 4 ist. Daher können \fB.lzma\fP\-Dateien,
welche diese Begrenzung überschreiten, mit \fBxz\fP nicht dekomprimiert werden.
.PP
Die LZMA\-Utils erzeugen nur \fB.lzma\fP\-Dateien mit einer Wörterbuchgröße von
2^\fIn\fP (einer Zweierpotenz), aber akzeptieren Dateien mit einer beliebigen
Wörterbuchgröße. Liblzma akzeptiert nur \fB.lzma\fP\-Dateien mit einer
Wörterbuchgröße von 2^\fIn\fP oder 2^\fIn\fP + 2^(\fIn\fP\-1). Dies dient zum
Verringern von Fehlalarmen beim Erkennen von \fB.lzma\fP\-Dateien.
.PP
Diese Einschränkungen sollten in der Praxis kein Problem sein, da praktisch
alle \fB.lzma\fP\-Dateien mit Einstellungen komprimiert wurden, die Liblzma
akzeptieren wird.
.
.SS "Angehängter Datenmüll"
Bei der Dekompression ignorieren die LZMA\-Utils stillschweigend alles nach
dem ersten \fB.lzma\fP\-Datenstrom. In den meisten Situationen ist das ein
Fehler. Das bedeutet auch, dass die LZMA\-Utils die Dekompression verketteter
\&\fB.lzma\fP\-Dateien nicht unterstützen.
.PP
Wenn nach dem ersten \fB.lzma\fP\-Datenstrom Daten verbleiben, erachtet \fBxz\fP
die Datei als beschädigt, es sei denn, die Option \fB\-\-single\-stream\fP wurde
verwendet. Dies könnte die Ausführung von Skripten beeinflussen, die davon
ausgehen, dass angehängter Datenmüll ignoriert wird.
.
.SH ANMERKUNGEN
.
.SS "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 könnte
(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
Binärprogramms unterschiedliche Optionen verwendet wurden.
.PP
Sobald \fB\-\-rsyncable\fP implementiert wurde, bedeutet das, dass die sich
ergebenden Dateien nicht notwendigerweise mit Rsync abgeglichen werden
können, außer wenn die alte und neue Datei mit der gleichen \fBxz\fP\-Version
erzeugt wurden. Das Problem kann beseitigt werden, wenn ein Teil der
Encoder\-Implementierung eingefroren wird, um die mit Rsync abgleichbare
Ausgabe über \fBxz\fP\-Versionsgrenzen hinweg stabil zu halten.
.
.SS "Eingebettete .xz\-Dekompressoren"
Eingebettete \fB.xz\fP\-Dekompressor\-Implementierungen wie XZ Embedded
unterstützen nicht unbedingt Dateien, die mit anderen Integritätsprüfungen
(\fIPrüfung\fP\-Typen) als \fBnone\fP und \fBcrc32\fP erzeugt wurden. Da
\fB\-\-check=crc64\fP die Voreinstellung ist, müssen Sie \fB\-\-check=none\fP oder
\fB\-\-check=crc32\fP verwenden, wenn Sie Dateien für eingebettete Systeme
erstellen.
.PP
Außerhalb eingebetteter Systeme unterstützen die Dekompressoren des
\&\fB.xz\fP\-Formats alle \fIPrüfung\fP\-Typen oder sind mindestens in der Lage, die
Datei zu dekomprimieren, ohne deren Integrität zu prüfen, wenn die bestimmte
\fIPrüfung\fP nicht verfügbar ist.
.PP
XZ Embedded unterstützt BCJ\-Filter, aber nur mit dem vorgegebenen
Startversatz.
.
.SH BEISPIELE
.
.SS Grundlagen
Komprimiert die Datei \fIfoo\fP mit der Standard\-Kompressionsstufe (\fB\-6\fP) zu
\fIfoo.xz\fP und entfernt \fIfoo\fP nach erfolgreicher Kompression:
.RS
.PP
.nf
\f(CWxz foo\fP
.fi
.RE
.PP
\fIbar.xz\fP in \fIbar\fP dekomprimieren und \fIbar.xz\fP selbst dann nicht löschen,
wenn die Dekompression erfolgreich war:
.RS
.PP
.nf
\f(CWxz \-dk bar.xz\fP
.fi
.RE
.PP
\fIbaz.tar.xz\fP mit der Voreinstellung \fB\-4e\fP (\fB\-4 \-\-extreme\fP) erzeugen, was
langsamer ist als die Vorgabe \fB\-6\fP, aber weniger Speicher für Kompression
und Dekompression benötigt (48\ MiB beziehungsweise 5\ MiB):
.RS
.PP
.nf
\f(CWtar cf \- baz | xz \-4e > baz.tar.xz\fP
.fi
.RE
.PP
Eine Mischung aus komprimierten und unkomprimierten Dateien kann mit einem
einzelnen Befehl dekomprimiert in die Standardausgabe geschrieben werden:
.RS
.PP
.nf
\f(CWxz \-dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt\fP
.fi
.RE
.
.SS "Parallele Kompression von vielen Dateien"
Auf GNU\- und *BSD\-Systemen können \fBfind\fP(1) und \fBxargs\fP(1) zum
Parallelisieren der Kompression vieler Dateien verwendet werden:
.RS
.PP
.nf
\f(CWfind . \-type f \e! \-name '*.xz' \-print0 \e     | xargs \-0r \-P4 \-n16 xz \-T1\fP
.fi
.RE
.PP
Die Option \fB\-P\fP von \fBxargs\fP(1) legt die Anzahl der parallelen
\fBxz\fP\-Prozesse fest. Der beste Wert für die Option \fB\-n\fP hängt 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
\fBxz\fP\-Prozesse zu beschränken, die \fBxargs\fP(1) schließlich erzeugen wird.
.PP
Die Option \fB\-T1\fP für \fBxz\fP dient dazu, den Einzelthread\-Modus zu erzwingen,
da \fBxargs\fP(1) zur Steuerung des Umfangs der Parallelisierung verwendet
wird.
.
.SS Roboter\-Modus
Berechnen, wie viel Byte nach der Kompression mehrerer Dateien insgesamt
eingespart wurden:
.RS
.PP
.nf
\f(CWxz \-\-robot \-\-list *.xz | awk '/^totals/{print $5\-$4}'\fP
.fi
.RE
.PP
Ein Skript könnte abfragen wollen, ob es ein \fBxz\fP verwendet, das aktuell
genug ist. Das folgende \fBsh\fP(1)\-Skript prüft, ob die Versionsnummer des
Dienstprogramms \fBxz\fP mindestens 5.0.0 ist. Diese Methode ist zu alten
Beta\-Versionen kompatibel, welche die Option \fB\-\-robot\fP nicht unterstützen:
.RS
.PP
.nf
\f(CWif ! 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\fP
.fi
.RE
.PP
Eine Speicherbedarfsbegrenzung für die Dekompression mit \fBXZ_OPT\fP setzen,
aber eine bereits gesetzte Begrenzung nicht erhöhen:
.RS
.PP
.nf
\f(CWNEWLIM=$((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\fP
.fi
.RE
.
.SS "Benutzerdefinierte Filterketten für die Kompression"
Der einfachste Anwendungsfall für benutzerdefinierte Filterketten ist die
Anpassung von LZMA2\-Voreinstellungsstufen. Das kann nützlich sein, weil die
Voreinstellungen nur einen Teil der potenziell sinnvollen Kombinationen aus
Kompressionseinstellungen abdecken.
.PP
Die KompCPU\-Spalten der Tabellen aus den Beschreibungen der Optionen \fB\-0\fP …
\fB\-9\fP und \fB\-\-extreme\fP sind beim Anpassen der LZMA2\-Voreinstellungen
nützlich. Diese sind die relevanten Teile aus diesen zwei Tabellen:
.RS
.PP
.TS
tab(;);
c c
n n.
Voreinst.;KomprCPU
\-0;0
\-1;1
\-2;2
\-3;3
\-4;4
\-5;5
\-6;6
\-5e;7
\-6e;8
.TE
.RE
.PP
Wenn Sie wissen, dass eine Datei für eine gute Kompression ein etwas
größeres Wörterbuch benötigt (zum Beispiel 32 MiB), aber Sie sie schneller
komprimieren wollen, als dies mit \fBxz \-8\fP geschehen würde, kann eine
Voreinstellung mit einem niedrigen KompCPU\-Wert (zum Beispiel 1) dahingehend
angepasst werden, ein größeres Wörterbuch zu verwenden:
.RS
.PP
.nf
\f(CWxz \-\-lzma2=preset=1,dict=32MiB foo.tar\fP
.fi
.RE
.PP
Mit bestimmten Dateien kann der obige Befehl schneller sein als \fBxz \-6\fP,
wobei die Kompression deutlich besser wird. Dennoch muss betont werden, dass
nur wenige Dateien von einem größeren Wörterbuch profitieren, wenn der
KompCPU\-Wert niedrig bleibt. Der offensichtlichste Fall, in dem ein größeres
Wörterbuch  sehr hilfreich sein kann, ist ein Archiv, das einander sehr
ähnliche Dateien enthält, die jeweils wenigstens einige Megabyte groß
sind. Das Wörterbuch muss dann deutlich größer sein als die einzelne Datei,
damit LZMA2 den größtmöglichen Vorteil aus den Ähnlichkeiten der aufeinander
folgenden Dateien zieht.
.PP
Wenn hoher Speicherbedarf für Kompression und Dekompression kein Problem ist
und die zu komprimierende Datei mindestens einige Hundert Megabyte groß ist,
kann es sinnvoll sein, ein noch größeres Wörterbuch zu verwenden, als die 64
MiB, die mit \fBxz \-9\fP verwendet werden würden:
.RS
.PP
.nf
\f(CWxz \-vv \-\-lzma2=dict=192MiB big_foo.tar\fP
.fi
.RE
.PP
Die Verwendung von \fB\-vv\fP (\fB\-\-verbose \-\-verbose\fP) wie im obigen Beispiel
kann nützlich sein, um den Speicherbedarf für Kompressor und Dekompressor zu
sehen. Denken Sie daran, dass ein Wörterbuch, das größer als die
unkomprimierte Datei ist, Speicherverschwendung wäre. Daher ist der obige
Befehl für kleine Dateien nicht sinnvoll.
.PP
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 können. Der folgende Befehl
verwendet \fB\-6e\fP (\fB\-6 \-\-extreme\fP) als Basis und setzt die Wörterbuchgröße
auf nur 64\ KiB. Die sich ergebende Datei kann mit XZ Embedded (aus diesem
Grund ist dort \fB\-\-check=crc32\fP) mit nur etwa 100\ KiB Speicher
dekomprimiert werden.
.RS
.PP
.nf
\f(CWxz \-\-check=crc32 \-\-lzma2=preset=6e,dict=64KiB foo\fP
.fi
.RE
.PP
Wenn Sie so viele Byte wie möglich herausquetschen wollen, kann die
Anpassung der Anzahl der literalen Kontextbits (\fIlc\fP) und der Anzahl der
Positionsbits (\fIpb\fP) manchmal hilfreich sein. Auch die Anpassung der Anzahl
der literalen Positionsbits (\fIlp\fP) könnte helfen, aber üblicherweise sind
\fIlc\fP und \fIpb\fP wichtiger. Wenn ein Quellcode\-Archiv zum Beispiel
hauptsächlich ASCII\-Text enthält, könnte ein Aufruf wie der folgende eine
etwas kleinere Datei (etwa 0,1\ %) ergeben als mit \fBxz \-6e\fP (versuchen Sie
es auch \fBlc=4\fP):
.RS
.PP
.nf
\f(CWxz \-\-lzma2=preset=6e,pb=0,lc=4 Quellcode.tar\fP
.fi
.RE
.PP
Die Verwendung eines anderen Filters mit LZMA2 kann die Kompression bei
verschiedenen Dateitypen verbessern. So könnten Sie eine gemeinsam genutzte
Bibliothek der Architekturen x86\-32 oder x86\-64 mit dem BCJ\-Filter für x86
komprimieren:
.RS
.PP
.nf
\f(CWxz \-\-x86 \-\-lzma2 libfoo.so\fP
.fi
.RE
.PP
Beachten Sie, dass die Reihenfolge der Filteroptionen von Bedeutung
ist. Falls \fB\-\-x86\fP nach \fB\-\-lzma2\fP angegeben wird, gibt \fBxz\fP einen Fehler
aus, weil nach LZMA2 kein weiterer Filter sein darf und auch weil der
BCJ\-Filter für x86 nicht als letzter Filter in der Filterkette gesetzt
werden darf.
.PP
Der Delta\-Filter zusammen mit LZMA2 kann bei Bitmap\-Bildern gute Ergebnisse
liefern. Er sollte üblicherweise besser sein als PNG, welches zwar einige
fortgeschrittene Filter als ein simples delta bietet, aber für die
eigentliche Kompression »Deflate« verwendet.
.PP
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 \fBdist=3\fP, außerdem
ist es gut, \fBpb=0\fP an LZMA2 zu übergeben, um die 3\-Byte\-Ausrichtung zu
berücksichtigen:
.RS
.PP
.nf
\f(CWxz \-\-delta=dist=3 \-\-lzma2=pb=0 foo.tiff\fP
.fi
.RE
.PP
Wenn sich mehrere Bilder in einem einzelnen Archiv befinden (zum Beispiel\&
\&\fB.tar\fP), funktioniert der Delta\-Filter damit auch, sofern alle Bilder im
Archiv die gleiche Anzahl Bytes pro Pixel haben.
.
.SH "SIEHE AUCH"
\fBxzdec\fP(1), \fBxzdiff\fP(1), \fBxzgrep\fP(1), \fBxzless\fP(1), \fBxzmore\fP(1),
\fBgzip\fP(1), \fBbzip2\fP(1), \fB7z\fP(1)
.PP
XZ Utils: <https://tukaani.org/xz/>
.br
XZ Embedded: <https://tukaani.org/xz/embedded.html>
.br
LZMA\-SDK: <https://7\-zip.org/sdk.html>