Adding upstream version 5.4.1.upstream/5.4.1upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 1938 insertions, 0 deletions

diff --git a/po4a/man/de/xz.1 b/po4a/man/de/xz.1
new file mode 100644
index 0000000..521e553
--- /dev/null
+++ b/po4a/man/de/xz.1
@@ -0,0 +1,1938 @@
+'\" t
+.\"
+.\" Author: Lasse Collin
+.\"
+.\" 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 "1. Dezember 2022" 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 dekomprimierte 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 den 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 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 ist breiter als 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 \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.
+.IP ""
+.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 drei 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: <http://7\-zip.org/sdk.html>