XZ(1)

名前
xz, unxz, xzcat, lzma, unlzma, lzcat - .xz, .lzma ファイルの圧縮、伸長

書式
xz [option...] [file...]

コマンドエイリアス
unxz は xz --decompress と同じです。
xzcat は xz --decompress --stdout と同じです。
lzma は xz --format=lzma と同じです。
unlzma は xz --format=lzma --decompress と同じです。
lzcat は xz --format=lzma --decompress --stdout と同じです。

ファイル圧縮を行うスクリプトを記述する場合は、unxz や xzcat などを用いるのではなく、常に xz コマンドに適切な引数 (xz -d or xz -dc) をつけて利用することをお勧めします。

説明
xz は汎用目的のデータ圧縮ツールです。コマンドラインには gzip(1) や bzip2(1) と同等の文法が用いられています。ネイティブなファイルフォーマットは .xz です。さらに LZMA Utils が利用しているこれまでの .lzma フォーマットや、コンテナーフォーマットヘッダーを持たない、生の (raw) 圧縮ストリームにも対応しています。

xz は指定されたオペレーションモードに従って、各 file の圧縮、伸長を行います。files が指定されていない、または - と指定された場合、xz は標準入力からデータを読み込んで、処理結果を標準出力へ書き出します。端末上において圧縮データを標準出力に書き出そうとした場合には、xz は処理停止します (エラーを表示して file の処理をスキップします)。同様に端末上において圧縮データを標準入力から読み込もうとした場合も、xz は処理停止します。

--stdout の指定がなく files が - でない場合は新規のファイル生成となり、そのファイル名は元の file から命名されます。

•   圧縮時は、目的とするファイルフォーマット (.xz または .lzma) をサフィックスとして、元のファイル名にこれを加えたファイル名とします。

•   伸長時は、サフィックス .xz または .lzma を取り除いて、目的のファイル名とします。xz はサフィックスとして .txz と .tlz も識別します。この場合はサフィックスを .tar として置き換えます。

目的とするファイルがすでに存在している場合、エラーが表示されて file に対する処理はスキップされます。

出力先が標準出力でなく、以下のいずれかに該当する場合、xz は警告を表示して file の処理をスキップします。

•   file が通常の (regular) ファイルではない場合。シンボリックリンクをたどることはありません。したがってその場合は通常のファイルではないものとして扱われます。

•   file が複数のハードリンクを持つ場合。

•   file に setuid、setgid、スティッキービット (sticky bit) セットがある場合。

•   オペレーションモードが圧縮として設定されていて、file のサフィックスが目的とするファイルフォーマットにすでになっていた場合 (.xz への圧縮時にすでに .xz や .txz であった場合、また .lzma への圧縮時にすでに .lzma や .tlz であった場合)。

•   オペレーションモードが伸長として設定されていて、file のサフィックスが対応しているファイルフォーマット (.xz, .txz, .lzma, .tlz) でない場合。

file に対する圧縮または伸長が正常に処理された後は、元のソース file の所有者、グループ、パーミッション、アクセス時刻、更新時刻を、目的とするファイルにコピーします。グループ情報のコピーに失敗した場合は、パーミッションを修正して、元のソース file にアクセス権を有していなかったユーザーが、目的のファイルにアクセスできないようにします。現状の xz では、アクセスコントロールリストや拡張属性のようなメタデータのコピーには対応していません。

目的とするファイルのクローズ処理が正常終了したら、--keep が指定されていない限り、ソース file は削除されます。このソース file は、出力先が標準出力である場合には削除されません。

xz に対して SIGINFO や SIGUSR1 を送信すると、標準エラー出力に対して進捗情報を出力します。この用途は限られています。なぜなら標準エラー出力先が端末である場合、--verbose を利用すれば進捗インジケーターが自動的に更新されるためです。

  メモリ利用
xz が利用するメモリ量は、圧縮の設定により数 100 キロバイトから数ギガバイトまでとさまざまです。ファイル圧縮時に利用される設定は、ファイル伸長時のメモリ利用を決定づけます。通常、伸長処理に要するメモリ容量は、圧縮処理においてファイル生成に必要となるメモリ容量の 5 % から 20 % です。たとえば xz -9 によって圧縮されたファイルを伸長するには、今のところ 65 MiB のメモリを要します。ただし .xz ファイルの伸長に数ギガバイトを利用することも可能です。

特に、古いシステムを利用してきたユーザーは、あまりにもメモリが大量に消費されるので、好ましく思わないかもしれません。そのような状況を回避するために xz にはビルトインのメモリ制限機能があります。これはデフォルトでは無効化されています。オペレーティングシステムの中には、プロセスのメモリ利用を制限する方法を提供するものがありますが、そこに依存するのは、柔軟性に欠けると考えられてきました (たとえば ulimit(1) を利用して仮想メモリを制限すると、mmap(2) が機能しなくなる傾向にあるなどです)。

メモリ制限機能を有効にするには、コマンドラインオプション --memlimit=limit を指定します。この制限機能は、環境変数 XZ_DEFAULTS を用いて XZ_DEFAULTS=--memlimit=150MiB のようにしてデフォルトで有効にしておくと、利用しやすくなります。この制限機能は、圧縮時と伸長時のそれぞれに対して --memlimit-compress=limit および --memlimit-decompress=limit を使えば、個別に指定することができます。この 2 つのオプションを XZ_DEFAULTS 以外のところで用いるのは、あまり意味がありません。なぜなら xz が圧縮と伸長を同時に処理することはありえず、また --memlimit=limit (あるいは -M limit) と設定しておくことの方が、コマンドラインから入力するよりも短くて済むからです。

伸長時に、指定したメモリ利用制限を超過した場合、xz はエラーを表示し伸長処理は失敗します。圧縮時にその制限が超過した場合、xz はその制限値を引き下げて、制限を超過しないようにします (ただし --format=raw または --no-adjust の指定時は除きます)。このような処理方法により、制限値が極端に小さくない限り、処理は失敗しないようになります。設定値を引き下げていく際には、圧縮レベルを示すプリセット値までには至らない範囲で、徐々に引き下げられていきます。たとえばこの設定値が xz -9 に必要となる容量よりも少しだけ小さかった場合、設定値の引き下げはほんの少しだけ行われるものであって、xz -8 に必要となる容量まで一気に引き下げられるわけではありません。

  .xz ファイルの連結とパディング
複数の .xz ファイルは、その状態のまま連結 (concatenate) することができます。連結されたファイルを xz が伸長する際には、あたかも 1 つの .xz ファイルであるかのようにして処理します。

連結した間の部分や連結の最後に、パディング (padding) という追加データを挿入することができます。パディングはヌルバイトによって構成されるものであり、そのサイズは 4 バイトの倍数でなければなりません。これが有用となるのは、たとえば 512 バイト単位のブロックごとにファイルサイズを定めるような媒体に .xz ファイルを保存する場合です。

連結とパディングは、.lzma ファイルや生の (raw) ストリームにおいて行うことはできません。

オプション

  整数に対するサフィックスと特別な値
整数引数を必要とする場面の多くにおいては、サフィックスをさらにつけることで多大な数値を簡単に表現できるようにしています。整数値とそのサフィックスの間には空白文字を含めないでください。

KiB 1,024 (2^10) の倍数を表現します。KiB と同じ意味を表す Ki, k, kB, K, KB が利用できます。

MiB 1,048,576 (2^20) の倍数を表現します。MiB と同じ意味を表す Mi, m, M, MB が利用できます。

GiB 1,073,741,824 (2^30) の倍数を表現します。GiB と同じ意味を表す Gi, g, G, GB が利用できます。

特別な数値指定 max が利用できます。これはそのオプションにおいてサポートされている最大整数値を表します。

  オペレーションモード
オペレーションモードオプションが複数指定された場合は、最後の指定が有効となります。

-z, --compress
    圧縮を指示します。これはデフォルトのオペレーションモードです。オペレーションモードオプションが指定されなかった場合、あるいはコマンドラインからの指定において暗にオペレーションモードの指定が含まれていない場合に採用されます (たとえば unxz には --decompress が暗に含まれています)。

-d, --decompress, --uncompress
    伸長を指示します。

-t, --test
    圧縮された files の整合性をテストします。このオプションは --decompress --stdout とすることと同じです。ただし伸長されるデータが、標準出力へは書き込まれずに捨てられてしまう場合を除きます。このオプションでは、ファイル生成や削除は発生しません。

-l, --list
    圧縮された files に関する情報を一覧表示します。伸長処理が行われるわけではなく、ファイル生成や削除は発生しません。このリストモードでは、標準入力あるいは他のシークできない入力ソースからの圧縮データは読み込むことができません。

    このオプションによる一覧出力では、files に関する基本的な情報が、1 つにつき 1 行ずつ表示されます。さらに詳しい情報を得るには --verbose オプションも併用します。それ以上に細かい情報を得るには --verbose を 2 回指定します。ただしこれを行うと処理が遅くなるかもしれません。細かい情報を得るためには、数多くの検索処理が必要となるためです。詳細な情報を出力する際の出力幅は 80 文字を超えます。したがって less -S を利用するなどして出力をパイプすれば、横幅が十分に取れない端末であっても問題なく利用できます。

    実際の出力は xz のバージョンやロケール指定により変わります。マシンにとって読み込み可能な出力とするには、--robot --list を利用してください。

  オペレーション修飾子 (operation modifiers)

-k, --keep
    入力ファイルを削除しません。

-f, --force
    このオプションには複数の効果があります。

    •   目的とするファイルがすでに存在していた場合、そのファイルを削除してから圧縮や伸長を行います。

    •   入力ファイルが通常ファイルへのシンボリックリンクである場合、ハードリンクを複数持つ場合、setuid, setgid, スティッキービット (sticky bit) セットを持つ場合であっても、圧縮または伸長を行います。setuid, setgid, スティッキービットは目的となるファイルにはコピーされません。

    •   --decompress --stdout が指定された際に xz がソースファイルの種類を認識できなかった場合は、ソースファイルがそのまま標準出力へコピーされます。これは xzcat --force を利用した際に、ソースファイルが xz によって圧縮されていないファイルであっても cat(1) と同じように処理できることになります。将来的に xz は新たな圧縮ファイルフォーマットをサポートするかもしれないので、単に標準出力へコピーするのではなく、多くのファイルタイプを伸長できるようになるかもしれません。--format=format を指定すれば、xz が伸長を行うファイルフォーマットをただ 1 つに限定することができます。

-c, --stdout, --to-stdout
    圧縮または伸長する際に、出力先をファイルではなく標準出力とします。このオプションには --keep の指定が暗に含まれます。

--single-stream
    .xz の入力ストリームから最初の 1 つだけを伸長します。そしてそのストリームの続きとして入力データが残っていても、そのことを示さずに無視します。ただし通常は、そういったゴミデータが続いていると xz はエラーを出力します。

    xz では .lzma ファイルや生の (raw) ストリームからの複数ストリームは伸長処理を行いません。そこでこのオプションを利用しておけば、.lzma ファイルや生のストリームの次にくるゴミデータを無視できます。

    本オプションは、オペレーションモードが --decompress または --test である場合には何も行いません。

--no-sparse
    スパース (sparse) ファイルを生成しないようにします。伸長処理によって通常ファイルを生成する際に、伸長したデータ内にバイナリ値ゼロの並びが長く続く場合、xz はデフォルトでスパースファイルを生成しようとします。このような処理は、たとえ出力先が標準出力であっても、この標準出力が通常ファイルに結びついていて、かつ所定の条件をいくつか満たすことで安全に処理が進められるのであれば、同様に処理されます。スパースファイルを生成すれば、ディスク容量を節約できます。またディスク I/O の回数が減るので、伸長処理時間が短縮されます。

-S .suf, --suffix=.suf
    圧縮処理においては、目的とするファイルのサフィックスを .xz や .lzma ではなく .suf とします。標準出力への書き出しではなく、ソースファイルがすでにサフィックス .suf を持っていた場合は、警告メッセージが表示されて、そのファイルの処理はスキップされます。

    伸長処理においては、ファイルのサフィックスを .xz, .txz, .lzma, .tlz に加えて .suf を扱うようにします。ソースファイルのサフィックスが .suf である場合、このサフィックスを取り除いたものを目的のファイル名とします。

    生の (raw) ストリームを圧縮または伸長する場合 (--format=raw)、標準出力に書き込む場合を除き、サフィックスは必ずつけなければなりません。生のストリームに対するデフォルトのサフィックスがないためです。

--files[=file]
    処理対象とする file のファイル名を読み込みます。file を省略した場合、ファイル名は標準入力から読み込まれます。ファイル名は改行文字によって終了していなければなりません。ダッシュ (-) は通常のファイル名として扱われます。つまり標準入力を意味するものではありません。ファイル名がコマンドライン引数からも指定された場合、file からファイル名を読み込む前にその指定が処理されます。

--files0[=file]
    これは --files[=file] と同等です。ただしこれを利用する場合、各ファイル名はヌル文字で区切られていなければなりません。

  基本的なファイルフォーマットと圧縮オプション

-F format, --format=format
    圧縮または伸長を行う際のファイルフォーマットを format に指定します。

    auto
        これがデフォルトの設定です。圧縮処理の場合、auto は xz と同じになります。伸長処理の場合、入力ファイルのフォーマットは自動検出されます。ただし生の (raw) ストリーム (--format=raw により生成される) は自動検出されません。

    xz  ファイルフォーマット .xz として圧縮します。また伸長時には .xz ファイルのみを受けつけます。

    lzma, alone
        古いファイルフォーマット .lzma として圧縮します。また伸長時には .lzma ファイルのみを受けつけます。別名 alone は LZMA Utils との後方互換性のために提供されています。

    raw 生の (raw) ストリームを (ヘッダーはなしにして) 圧縮または伸長します。これは上級者向けの利用を意図しています。生のストリームをデコードするためには、--format=raw の指定、および明示的なフィルターチェーン (filter chain) の指定が必要です。フィルターチェーンは通常はコンテナーヘッダー内に保存されます。

-C check, --check=check
    整合性チェックのタイプを指定します。このチェックは伸長データから計算され、.xz ファイル内に保存されます。本オプションは、.xz フォーマットへの圧縮時にのみ効果があります。つまり .lzma フォーマットでは、整合性チェック機能はサポートされていません。整合性チェックは (もしあれば) .xz ファイルの伸長時に検証されます。

    サポートされる check のタイプは以下です：

    none
        整合性チェックを一切行いません。通常はあまりよくないことです。別の方法によってデータ整合性が検証されるのであれば、このタイプを利用することができます。

    crc32
        IEEE-802.3 (Ethernet) による多項式を利用して CRC32 を計算します。

    crc64
        ECMA-182 による多項式を用いて CRC64 を計算します。これがデフォルトです。CRC32 に比べると、破損ファイルの検出に若干有利であり、処理速度の違いは気にならない程度であるからです。

    sha256
        SHA-256 を計算します。CRC32 や CRC64 に比べると、処理速度がやや劣ります。

    .xz ヘッダーの整合性を、常に CRC32 によって検証します。これを変更したり無効化することはできません。

--ignore-check
    伸長時に圧縮データの整合性チェックを検証しません。.xz ヘッダー内にある CRC32 値は、それでも普通に検証されます。

    このオプションが何を行うのかを理解していない場合は利用しないでください。 本オプションを利用する状況は以下のとおりです：

    •   壊れた .xz ファイルからデータ回復を試みる場合。

    •   伸長処理の速度改善を図る場合。このオプションが効果があるのは、たいていは、 SHA-256 を利用する場合、または極めて効率よく圧縮されたファイルの場合です。ただしこの目的であっても、外部の別手段を利用してファイル整合性の検証を完全に行う場合を除き、推奨されません。

-0 ... -9
    圧縮プリセットレベル (preset level) を選択します。デフォルトは -6 です。複数のプリセットレベルが指定された場合、最後に指定されたものが採用されます。カスタムフィルターチェーン (custom filter chain) がすでに指定されている場合、圧縮プリセットレベルの指定により、そのカスタムフィルターチェーンの指定は解除されます。

    プリセットの違いは、gzip(1) や bzip2(1) にはない重要な意味があります。圧縮処理に対するプリセット指定は、伸長時におけるメモリ容量を決定づけます。したがってより高度なプリセットレベルを用いると、小容量の RAM しかない旧来のシステムでは、伸長時に相当な負荷がかかるかもしれません。特に gzip(1) や bzip2(1) では -9 をよく指定しますが、xz では 何も考えず常に -9 を用いるのは得策ではありません。

    -0 ... -3
        比較的速いプリセットです。-0 は gzip -9 よりも圧縮性能がよく、高速に処理されます。より高いプリセット値では、bzip2(1) と同等またはそれ以上の圧縮率が得られ、より高速に処理されます。ただしこの結果は、圧縮を行うデータタイプに大きく依存します。

    -4 ... -6
        古いシステムでの利用時でも伸長処理におけるメモリ利用は妥当なもので、圧縮処理も良好に行われます。-6 がデフォルトです。たとえば、たった 16 MiB の RAM しかないシステム上において伸長処理を行うことになっても、これを選んでおけば間違いはなく、配布を問題なく行うことができます。(-5e や -6e を選ぶことも有効かもしれません。--extreme 参照のこと。)

    -7 ... -9
        これらは -6 と同様ですが、より高圧縮になるとともに、伸長時はより多くのメモリを必要とします。これが有効になるのは、圧縮ファイルがそれぞれ 8 MiB, 16 MiB, 32 MiB を超える場合です。

    同一のハードウェア上であれば、伸長にかかる処理速度は毎秒、データ圧縮に要したバイト数の倍数にほぼ一致します。言い換えると、通常は圧縮率が高ければ伸長処理は速くなります。ということはつまり、単位時間内に生成される伸長処理の出力データ量は、状況によりさまざまであるということです。

    以下の表はプリセットの特徴をまとめたものです。

        プリセット | DictSize | CompCPU | CompMem | DecMem
        -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

    各カラムは以下のとおりです。

    •   DictSize とは LZMA2 辞書サイズです。辞書を利用すると、伸長するファイルサイズ以上にメモリを消費します。つまり -7 ... -9 は、本当に利用する必要がないのであれば、用いるべきでない理由がここにあります。-6 またはこれ未満において、消費されるメモリ容量は通常は十分に少なく、問題にならない程度です。

    •   CompCPU とは LZMA2 設定における簡易表現であり、圧縮速度に影響を及ぼすものです。辞書サイズももちろん速度に影響します。したがって CompCPU が同一である -6 ... -9 に対しては、プリセット値が高くなるほど、処理速度が低下する傾向にあります。処理が低下するということは、その分、圧縮率が向上する可能性があります。--extreme を参照してください。

    •   CompMem はシングルスレッドモードにおいて、圧縮処理時のメモリ消費量を表します。これは xz バージョンが異なることで変化する場合があります。メモリ消費量は、マルチスレッドモードでの機能によっては、シングルスレッドモードよりも急激に高まる場合があります。

    •   DecMem は伸長処理時におけるメモリ消費量を表します。つまり圧縮時の設定が、伸長処理時のメモリ消費量を決定づけるものです。実際に伸長処理におけるメモリ消費量は、LZMA2 辞書サイズより若干大きくなります。ただし上の表に示した値は、きれいな MiB 値になるように切り上げています。

-e, --extreme
    指定されているプリセットレベル (-0 ... -9) に比較して、より遅い処理方式 (variant) を用います。これにより少しでも高圧縮率が得られるようにします。ただし場合によっては、期待に沿わない結果となることもあります。伸長処理時におけるメモリ利用量には影響しません。ただし圧縮処理時のメモリ利用量は、そのときのレベルが -0 ... -3 である場合には若干増加します。

    辞書サイズを 4 MiB、8 MiB とするプリセットが 2 つずつあり、プリセット -3e と -5e はそれぞれ -4e と -6e に比べて若干高速になる (CompCPU は低くなる) 設定です。このようにして 2 つのプリセットが異なることになります。

        プリセット | DictSize | CompCPU | CompMem | DecMem
        -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

    たとえば 8 MiB の辞書サイズとなるプリセットは、全部で 4 つあります。これらにおいて処理が高速となる順は -5, -6, -5e, -6e です。

--fast
--best
    これらはそれぞれ -0 と -9 に対するエイリアスですが、やや誤解を招きやすいものです。これは LZMA Utils との後方互換性のために提供されています。このオプションを利用することは避けてください。

--block-size=size
    .xz フォーマットに圧縮する場合に、入力データを size バイトごとのブロックに分割します。このブロックは互いに独立して圧縮されます。これはマルチスレッド対応のためであり、限定されたランダムアクセス伸張を可能にします。このオプションによって、通常はマルチスレッドモードでのデフォルトブロックサイズをオーバーライドします。ただしこのオプションは、シングルスレッドモードでも利用することができます。

    マルチスレッドモードにおいては、size バイトのおよそ 3 倍分が、各スレッドの入出力バッファとして割り当てられます。デフォルトの size は LZMA2 辞書サイズの 3 倍か、1 MiB のいずれか大きい方になります。通常なら、LZMA2 辞書サイズの 2 ～ 4 倍か、最低 1 MiB が適正な値です。size に LZMA2 辞書サイズよりも小さな値を用いると、RAM を無駄に消費します。LZMA2 辞書のバッファはすべてが十分に利用されることはないためです。ブロックサイズはブロックヘッダー内に保存されます。これは xz の将来版において、マルチスレッドでの伸長処理に利用される予定です。

    シングルスレッドモードでは、デフォルトではブロック分割処理は行われません。本オプションを設定しても、メモリ利用量には影響しません。サイズ情報はブロックヘッダーに保存されないため、シングルモードにおいて生成されたファイルは、マルチスレッドで生成されたファイルと同一にはならなくなります。サイズ情報を含んでいないということは、つまり xz の将来版において、マルチスレッドモードにおける伸長処理が不能となる場合があることを意味します。

--block-list=sizes
    .xz フォーマットに圧縮する場合に、非圧縮データから指定された間隔分をあけて、新たなブロックを開始します。

    非圧縮ブロックの sizes は、カンマ区切りリストとして指定します。サイズを省略する (2 つ以上の連続したカンマのみを記述する) と、それは省略表記として前ブロックのサイズを利用する指定となります。

    入力ファイルが size の合計よりも大きかった場合、sizes の最後に指定された値を用いて、入力ファイルを繰り返し処理します。特別な設定値として 0 を用いると、これが最終の値として用いられ、ファイルの残りのデータを単一のブロックとしてエンコード処理を行うことを指示します。

    sizes に設定した値が、エンコード処理するブロックサイズ (スレッドモードにおけるデフォルト値、あるいは --block-size=size に指定された値) を超える場合、sizes に指定されたブロック範囲を超えたところで追加のブロックを生成します。たとえば--block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB と指定し、入力ファイルが 80 MiB であった場合、合計で 11 ブロック、つまり順番に 5, 10, 8, 10, 2, 10, 10, 4, 10, 10, 1 MiB のブロックとなります。

    マルチスレッドモードの場合、ブロックサイズはブロックヘッダー内に保存されます。これはシングルスレッドモードでは行われません。したがってエンコード処理結果は、マルチスレッドモードによるものとは同一になりません。

--flush-timeout=timeout
    圧縮時に、前回のフラッシュ処理からtimeoutミリ秒(正の整数)以上経過し、それ以上の入力を読み取るとブロックされるような場合、処理中断していた入力データがエンコード処理からフラッシュされて、出力ストリームでの利用が可能になります。こういった処理は、xz がネットワーク越しにストリームされたデータを圧縮する際に活用されます。timeout に小さな値を設定しておくと、受信したデータの最終分を利用する際に、わずかな遅延を起こすものとなります。もっともこの timeout に大きな値を設定しておけば、高圧縮率が得られます。

    この機能はデフォルトでは無効化されています。本オプションが複数回指定されると、最後の指定が適用されます。特別な値として timeout に 0 を設定すると、本機能を明示的に無効にするものとなります。

    本機能は非 POSIX システム上では利用できません。

    なお 本機能はまだ実験段階のものです。 今のところ xz のバッファリング方法に問題があるため、ストリームをリアルタイムで伸長する処理には適していません。

--memlimit-compress=limit
    圧縮時のメモリ利用制限を設定します。本オプションが複数回指定された場合、最後の指定が適用されます。

    圧縮設定が limit を超えた場合、xz はその設定を引き下げて、制限を超えないようにします。そして自動調整がなされたことを出力表示します。このような調整処理は、圧縮処理にあたって --format=raw や --no-adjust が指定された場合には行われません。この場合 xz はエラーを表示して、終了ステータス 1 を返して終了します。

    limit を指定する方法はいくつかあります。

    •   limit にバイト数の絶対値を指定します。この際には MiB のような整数サフィックスを利用するのが便利です。たとえば --memlimit-compress=80MiB とします。

    •   limit に物理メモリ (RAM) の総容量に対するパーセントを指定することができます。環境変数 XZ_DEFAULTS を用いてさまざまなコンピューター間において、シェル初期化スクリプトを利用するような場合に特に活用することができます。この方法を用いると、よりメモリ容量の多いシステムでは、自動的に制限値が大きくなります。たとえば --memlimit-compress=70% とします。

    •   limit を 0 に指定すれば、デフォルト設定に戻すことができます。現時点では limit に max (メモリ利用制限なし) と指定することと同じです。ただし、マルチスレッド対応が実装されたら、マルチスレッド処理時の 0 と max の意味が変わるかもしれません。したがって詳細が決定するまでの間は、max ではなく 0 を用いておくことをお勧めします。

    32 ビット版 xz には特別なケースがあります。limit の設定が 4020 MiB を超える場合、limit は 4020 MiB に設定されます。(そうなったとしても 0 と max には影響しません。なお伸長処理にこのような機能はありません。) この機能が他に支障を引き起こさない限りは、32 ビット実行モジュールが 4 GiB アドレス空間にアクセスするものとして有用です。

    メモリ利用 のセクションも参照してください。

--memlimit-decompress=limit
    伸長時のメモリ利用制限を設定します。これは --list モードに影響します。limit を超えなければ処理できなくなった場合、xz はエラーを表示して伸長処理は失敗します。limit の設定する別の方法については --memlimit-compress=limit を参照してください。

-M limit, --memlimit=limit, --memory=limit
    これは --memlimit-compress=limit --memlimit-decompress=limit と指定することと同じです。

--no-adjust
    圧縮設定がメモリ利用制限を超えた場合、xz はエラーを表示して終了します。デフォルトでは、設定内容は引き下げられる方向に調整されます。そのようにしてメモリ利用制限を超えないようにします。この自動調整機能は、生の (raw) ストリーム生成時 (--format=raw 指定時) は常に無効です。

-T threads, --threads=threads
    ワーカースレッド数を指定します。threads に対して特別な値 0 を指定すると、xz はシステム上の CPU コア分のスレッドを利用します。実際のスレッド数は threads の指定値より小さくなることがあります。それは入力ファイルのサイズが、指定されたスレッドを必要とするほどには大きくない場合や、スレッドを多く利用しすぎることによってメモリ利用制限を超える場合などです。

    現在行われているスレッド処理方法は 1 つだけです。入力データをブロック分けして、互いに独立して圧縮を行うという方法です。デフォルトのブロックサイズは、圧縮レベルに依存します。これは --block-size=size オプションによってオーバーライドすることができます。

    伸長処理時のスレッド化はまだ実装されていません。スレッド化に対応しているのは、入力ファイルに複数ブロックが含まれていて、そのサイズ情報がブロックヘッダーに存在しているファイルのみです。マルチスレッドモードにおいて圧縮されたファイルは、この条件をすべて満たします。しかしシングルスレッドモードにおいて圧縮されたファイルでは、--block-size=size を指定していたとしても、この条件を満たしません。

  カスタム圧縮フィルターチェーン
カスタムフィルターチェーン (custom filter chain) を用いると、圧縮設定を細かく設定することができ、プリセット値に関連づいた設定に頼る必要がなくなります。カスタムフィルターチェーンが指定されると、コマンドライン上でプリセットオプション (-0 ... -9 および --extreme) が初めに指定されていても無視されます。また複数のカスタムフィルター指定の後ろにプリセットオプションが指定された場合は、新たな意味になるプリセット指定が採用されて、それよりも前に指定されていたカスタムフィルターチェーンは無視されます。

フィルターチェーンというものは、コマンドライン上のパイプ処理と同じように動作します。圧縮時には、伸長されている入力データが 1 つめのフィルターに受け渡されます。そしてその出力は、次のフィルターがあればそこに受け渡されます。最終のフィルターから出力される結果が、圧縮ファイルとして書き出されます。指定できるフィルターチェーンは最大 4 つまでです。通常、フィルターチェーンを利用するのは、せいぜい 1 つか 2 つまでです。

フィルターの多くは、どこに記述するかという制限があります。たとえばフィルターの中にはチェーン内の最終フィルターとしてしか動作しないものがあります。逆に最終フィルターとしては動作しないものもあります。もちろんどの場所に置いても動作するものも存在します。フィルターにもよりますが、こういった制約はフィルター設計によって発生している場合や、セキュリティ問題を回避するために存在している場合もあります。

カスタムフィルターチェーンは、フィルターオプションを必要な分だけ、またフィルターチェーンの中で実行させたい順番で指定します。つまりフィルターオプションとして指定する順番が極めて重要です。生の (raw) ストリーム (--format=raw 指定) をデコードする際には、それが圧縮された際に指定された順番どおりのフィルターチェーンを指定します。

フィルターには、フィルター固有の options があり、カンマで区切ったリストにより指定します。options に余計なカンマがあると無視されます。すべてのオプションにはデフォルト値が設定されています。したがってオプションは、変更したいもののみ指定するだけで十分です。

フィルターチェーンと options をすべて見るには xz -vv を入力します (つまり --verbose を 2 回指定します)。これにより、プリセットが利用するフィルターチェーンオプションも参照することができます。

--lzma1[=options]
--lzma2[=options]
    フィルター LZMA1 および LZMA2 をフィルターチェーンに追加します。これらのフィルターは、チェーン内の最終フィルターとしてのみ利用できます。

    LZMA1 は古いフィルターです。古い .lzma ファイルフォーマットは LZMA1 のみに対応していて、つまりこのフィルターは .lzma 向けだけにサポートされています。LZMA2 は LZMA1 の更新版であり、LZMA1 が抱えている具体的な問題を修正しています。.xz フォーマットは LZMA2 を利用していて、LZMA1 には一切対応していません。圧縮速度および圧縮率は、LZMA1 と LZMA2 において実質変わりません。

    LZMA1 と LXMA2 における options は共通しています。

    preset=preset
        LZMA1 および LZMA2 の options をすべて preset にリセットします。preset は整数により構成され、英字 1 文字からなるプリセット修飾子をつける場合があります。整数とは 0 から 9 までの値であり、コマンドラインオプション -0 ... -9 に対応します。プリセット修飾子とは、今のところ e というもののみがサポートされています。これは --extreme に対応します。preset の指定がなかった場合、LZMA1 および LZMA2 の options はともにプリセット 6 に対応する値がデフォルトして採用されます。

    dict=size
        辞書の (履歴バッファの) size は、直近にメモリ上で処理され保持されている伸長データのバイト量を表します。そのアルゴリズムでは、伸長データの中からバイトシーケンスの繰り返し (合致するもの) を探し出そうとします。そしてその時点での辞書内データへの参照に置き換えます。辞書が大きくなれば、それだけ合致する機会は増えることになります。つまり辞書の size を増やしておけば、普通は圧縮率が向上します。ただし伸長ファイル以上に辞書サイズが大きいと、メモリを無駄に消費します。

        辞書の size は通常は 64 KiB から 64 MiB です。最小でも 4 KiB です。圧縮用の最大値は、今のところ 1.5 GiB (1536 MiB) です。伸長処理においては 4 GiB 未満、1 バイトまでの辞書がすでにサポートされています。4 GiB は LZMA1 および LZMA2 のストリームフォーマットにおける最大値です。

        辞書の size とマッチ検索処理 (match finder; mf) はともに、LZMA1 または LZMA2 のエンコード処理におけるメモリ利用量を決定づけます。伸長処理においては、圧縮時に用いられた辞書 size と同じ (あるいはそれよりも大きい) サイズが必要になります。つまり伸長処理時のメモリ利用量は、圧縮時に用いられた辞書サイズによって決定します。.xz ヘッダーには辞書の size が、2^n または 2^n + 2^(n-1) のいずれかとして保存されます。したがってこの sizes はどちらかと言うと、圧縮時に適したものです。これ以外の sizes は .xz ヘッダーに保存される際に切り上げられます。

    lc=lc
        リテラルコンテキスト (literal context) のビット数を指定します。最小値は 0、最大値は 4、デフォルトは 3 です。また lc と lp を合計した値は 4 を超えてはなりません。

        エンコード処理に際して合致しなかったバイトは、すべてリテラルとしてエンコードされます。つまりリテラルとは、1 回に 1 つずつエンコードされる、単純な 8 ビットのバイト列です。

        リテラルの処理では、直前に伸長したバイトの上位 lc ビットは、次のバイトと相関関係にあることを前提にしています。たとえば通常の英文の場合、英大文字の次にたいていは小文字が続きます。そしてその小文字の次には、たいていは別の小文字が続きます。また US-ASCII キャラクターセットの場合、大文字の上位 3 ビットは 010 であり、小文字の場合は 011 です。lc が最低 3 として設定されていれば、リテラル処理は伸長データ内のこの特性を利用することができます。

        デフォルト値 (3) は通常はうまく動作します。圧縮率を最大にしたい場合は lc=4 を試してみてください。これによって多少はうまくいくことがありますが、場合によっては圧縮率が悪くなることもあります。もし悪くなった場合には lc=2 といった指定も試してみてください。

    lp=lp
        リテラルポジション (literal position) のビット数を指定します。最小値は 0、最大値は 4、デフォルトは 0 です。

        lp はリテラルをエンコードする際に、伸長データ内においてどのようなバイトの並び (alignment) を前提にするのかという点に影響します。バイトの並びに関する詳細は、以下の pb を参照してください。

    pb=pb
        ポジションのビット数を指定します。最小値は 0、最大値は 4、デフォルトは 2 です。

        pb は全般に、伸長データ内においてどのようなバイトの並び (alignment) を前提にするのかという点に影響します。デフォルト値は 4 バイトの並びを意味します (2^pb=2^2=4)。他に類推する手段がない場合には、これがうまく動作します。

        バイトの並び方がわかっている場合、それに応じて pb を設定しておけば、ファイルサイズをやや小さくできる場合があります。たとえば 1 バイト並びのテキストファイル (US-ASCII, ISO-8859-*, UTF-8) の場合、pb=0 に設定しておくと、圧縮率がやや向上します。UTF-16 テキストであれば pb=1 とするのが最適です。バイトの並びが 3 バイトなどのような奇数である場合、pb=0 とするのが最良かもしれません。

        前提となったバイトの並びは pb や lp を使って調整ができますが、それでも LZMA1 や LZMA2 は 16 バイトの並びの方がふさわしいものです。したがって LZMA1 や LZMA2 を使って圧縮することが多いファイル形式を設計する場合には、このことに配慮しておく価値があるかもしれません。

    mf=mf
        マッチ検索処理 (match finder) は、エンコード処理速度、メモリ利用量、圧縮率に大きな影響を与えます。通常はバイナリツリーによるマッチ検索処理よりも、ハッシュチェーンによるマッチ検索処理の方が早くなります。デフォルト値は preset の値により変わります。0 のときは hc3、1-3 のときは hc4、それ以外は bt4 がデフォルトになります。

        マッチ検索処理は以下に示すものがサポートされます。以下に示すメモリ利用計算式 (memory usage formulas) はかなりの概算であり、dict が 2 のべき乗である場合に、実際の値に最も近くなります。

        hc3 2 バイトまたは 3 バイトハッシング (hashing) を用いたハッシュチェーン (hash chain)。
            nice の最小値は 3 です。
            メモリ利用量：
            dict * 7.5 (dict <= 16 MiB である場合);
            dict * 5.5 + 64 MiB (dict > 16 MiB である場合)

        hc4 2 バイト、3 バイト、4 バイトハッシングを用いたハッシュチェーン。
            nice の最小値は 4 です。
            メモリ利用量：
            dict * 7.5 (dict <= 32 MiB である場合);
            dict * 6.5 (dict > 32 MiB である場合)

        bt2 2 バイトハッシングを用いたバイナリツリー (binary tree)。
            nice の最小値は 2 です。
            メモリ利用量: dict * 9.5

        bt3 2 バイトと 3 バイトハッシングを用いたバイナリツリー。
            nice の最小値は 3 です。
            メモリ利用量：
            dict * 11.5 (dict <= 16 MiB である場合);
            dict * 9.5 + 64 MiB (dict > 16 MiB である場合)

        bt4 2 バイト、3 バイト、4 バイトハッシングを用いたバイナリツリー。
            nice の最小値は 4 です。
            メモリ利用量：
            dict * 11.5 (dict <= 32 MiB である場合);
            dict * 10.5 (dict > 32 MiB である場合)

    mode=mode
        圧縮の mode は、マッチ検索処理によって生成されるデータの分析手法を指定します。サポートされる modes は fast と normal です。デフォルトは presets が 0-3 のとき fast、presets が 4-9 のとき normal です。

        一般的に fast が用いられるのはハッシュチェーンによるマッチ検索処理の場合であり、normal はバイナリツリーによるマッチ検索処理の場合です。これは presets が用いるものと同じです。

    nice=nice
        マッチ処理に対して適切なバイト数と思われる値を指定します。最低 nice バイト分にマッチしたとき、アルゴリズムはそれ以上、マッチする可能性をあきらめて探さないようにします。

        Nice は 2 ～ 273 バイトの範囲とします。値を大きくすれば処理速度は低下しますが、より高い圧縮率が得られる傾向にあります。デフォルト値は preset の値によって変わります。

    depth=depth
        マッチ検索処理において、検索する最大深さを指定します。デフォルトは特別な値 0 です。この値は、圧縮処理において mf と nice の値から妥当な値 depth が決定されることを意味します。

        ハッシュチェーンに対しての妥当な depth の値は 4 ～ 100 です。バイナリツリーでは 16 ～ 1000 です。depth に対して非常に大きな値を設定すると、ファイル内容によってはエンコード処理が極端に遅くなる場合があります。時間が無用に長くなりすぎた際に圧縮を取りやめる段取りが整っていないのであれば、depth に 1000 以上の値を設定することは避けてください。

    生の (raw) ストリーム (--format=raw 指定) に対するデコード処理の際には、LZMA2 は辞書サイズ size だけが必要です。LZMA1 の場合は lc, lp, pb だけあれば十分です。

--x86[=options]
--powerpc[=options]
--ia64[=options]
--arm[=options]
--armthumb[=options]
--sparc[=options]
    branch/call/jump (BCJ) フィルターをフィルターチェーンに追加します。このフィルターは、フィルターチェーン内の最終フィルターとして利用することはできません。

    BCJ フィルターは、マシンコード内の相対アドレスを絶対アドレスに変換します。これによりデータサイズは変わりません。ただし冗長性は増します。LZMA2 からは 0 ～ 15 % 小さな .xz ファイルが生成されることになります。BCJ フィルターはいつでも元に戻すことができます。つまり誤ったデータタイプに対して BCJ フィルターを用いても、データを失うことはありません。ただし圧縮率がやや低下することがあります。

    BCJ フィルターを実行ファイル全体に適用しても、問題はありません。そしてこのフィルターを実行ファイルの実行セクション (executable section) にのみ適用する必要はありません。実行モジュールと実行不可ファイルを両方含むアーカイブに対してこのフィルターを適用すると、良い結果が得られる場合もあり、そうでない場合もあります。したがって一般的には、バイナリパッケージを配布向けに圧縮する際にまで、BCJ フィルターを用いるのは適切ではありません。

    この BCJ フィルターは非常に高速であり、目立ったメモリ消費は発生しません。BCJ フィルターによってファイル圧縮率が向上したとすれば、伸長処理の速度が向上します。なぜなら同一のハードウェア上であれば、伸長にかかる処理速度は毎秒、データ圧縮に要したバイト数の倍数にほぼ一致するからです。

    この BCJ フィルターには、圧縮率に関して以下のような問題があります。

    •   実行コードを含んだファイル (たとえばオブジェクトファイル、スタティックライブラリ、Linux カーネルモジュールなど) の中には、命令内のアドレスにフィルター値が埋め込まれることになります。この BCJ フィルターは、それでもアドレス変換を続行しますが、そういったファイルにおいては圧縮率が悪くなる場合があります。

    •   似通った実行ファイルが複数含まれるアーカイブに対して BCJ フィルターを適用すると、BCJ フィルターを使わなかった場合に比べて圧縮率が悪くなります。これは BCJ フィルターが実行ファイル間の境界を検出しないためであり、各実行ファイルに対してアドレス変換のカウンターをリセットしないことから発生します。

    将来的には新たなフィルターを通じて、上記の 2 つの問題は解消される予定です。従来の BCJ フィルターは、埋め込みシステムにおいては引き続き有用となるはずです。というのも、新たなフィルターはより大きくなり、メモリ消費も増加するはずだからです。

    命令セットが異なるとバイトの並びも異なります:

        フィルター | Alignment | 説明
        x86 | 1 | 32 ビット、64 ビット x86
        PowerPC | 4 | ビッグエンディアンのみ
        ARM | 4 | リトルエンディアンのみ
        ARM-Thumb | 2 | リトルエンディアンのみ
        IA-64 | 16 | ビッグエンディアンおよびリトルエンディアン
        SPARC | 4 | ビッグエンディアンおよびリトルエンディアン

    BCJ フィルターによって処理したデータは、通常は LZMA2 によって圧縮されるので、利用された BCJ フィルターのバイト並びにマッチするように LZMA2 オプションが設定されていれば、圧縮率はわずかながら改善されます。たとえば IA-64 フィルターを用いた場合、LZMA2 に対しては pb=4 (2^4=16) とするのが適切です。ただし、x86 フィルターの場合は例外と考えてください。x86 実行ファイルを圧縮する場合には、LZMA2 のデフォルトである 4 バイト並びを必ず用いるようにするのが適切です。

    BCJ フィルターはすべて同一の options をサポートします。

    start=offset
        相対および絶対アドレス間の変換の際に用いられる、オフセット値 offset の開始位置を指定します。offset はフィルターのバイト並びの倍数でなければなりません (上表参照)。デフォルトはゼロです。現実にはデフォルト値で十分です。つまり offset を独自に設定しても、たいていは役に立ちません。

--delta[=options]
    フィルターチェーンにデルタ (delta) フィルターを追加します。デルタフィルターは、フィルターチェーン内の最終フィルターとして利用することはできません。

    現時点では、単純にバイト単位によるデルタ計算のみがサポートされています。これはたとえばビットマップイメージあるいは PCM オーディオを圧縮する際に利用できます。ただし特別に用意されたアルゴリズムを使えば Delta + LZMA2 よりも優れた結果が得られるかもしれません。これはオーディオデータに対しては明らかなことで、flac(1) などを用いれば、圧縮はより速く適切なものになります。

    サポートされている options：

    dist=distance
        デルタ計算の distance をバイト単位で指定します。distance は 1 ～ 256 であることが必要です。デフォルトは 1 です。

        たとえば dist=2 を指定し、入力が 8 バイト A1 B1 A2 B3 A3 B5 A4 B7 であったとすると、出力は A1 B1 01 02 01 02 01 02 となります。

  その他のオプション

-q, --quiet
    警告メッセージや通知メッセージを省略します。この指定を 2 つ重ねると、エラーメッセージも省略します。本オプションは終了ステータスには影響しません。警告メッセージがたとえ省略されていても変わらないことなので、終了ステータスには警告を示す値が返されます。

-v, --verbose
    詳細な出力とします。標準エラー出力が端末に接続されている場合、xz は進捗インジケーターを表示します。--verbose を 2 つ重ねて指定すると、さらに詳細な出力が行われます。

    進捗インジケーターには以下の情報が表示されます。

    •   入力ファイルのサイズがわかっている場合は、完了率が表示されます。これはパイプ処理の場合には表示されません。

    •   生成された圧縮データ量 (圧縮時) または消費された圧縮データ量 (伸長時) が表示されます。

    •   消費された伸長データ量 (圧縮時) または生成された伸長データ量 (伸長時) が表示されます。

    •   圧縮率が表示されます。これはその時点までに圧縮されたデータ量を、未圧縮のデータ量で割った値として算出されます。

    •   圧縮または伸長の処理速度が表示されます。これは消費された伸長データ (圧縮時) または生成された伸長データ (伸長時) の秒ごとの処理量です。処理量の表示は xz がファイル処理を開始した後、しばらくたってから表示されます。

    •   経過時間を M:SS または H:MM:SS の書式により表示します。

    •   入力ファイルのサイズがわかっている場合だけ、残り時間の見積もりが表示されます。その場合、xz がファイル処理を開始してから、数秒が経過した後に表示が始まります。時刻表記は精度を落として、小数点表記を行いません。たとえば 2 min 30 s とします。

    標準エラー出力先が端末ではない場合、--verbose によって出力される内容は、ファイル名、圧縮サイズ、伸長サイズ、圧縮率です。また圧縮あるいは伸長が始まると、表示可能であれば処理速度や経過時間を 1 行にまとめて標準エラー出力に書き出します。処理速度や経過時間が表示されるのは、あくまで処理時間が一定秒数以上かかる場合のみです。ユーザーによる処理中断のように処理が完了しなかった場合でも、入力ファイルサイズがわかっていれば、完了率は表示されます。

-Q, --no-warn
    警告に相当する状況が発生したとしても、終了ステータスは 2 に設定しないでください。本オプションは詳細表示のレベルには影響しません。したがって --quiet と --no-warn の 2 つは、警告を非表示とするために利用するものであって、終了ステータスを変更する目的で用いてはなりません。

--robot
    マシン解析が可能な書式でメッセージ出力を行います。これは liblzma でなく xz を利用したフロントエンドを容易に構築できるように意図したものです。さまざまなスクリプトを用いることが想定されるでしょう。本オプションを使って出力した結果は、xz の将来のリリースに向けて安定して提供していくつもりです。詳しくは ロボットモード セクションを参照してください。

--info-memory
    読みやすい書式で以下の出力を行います。xz が識別している、システム搭載の物理メモリ (RAM) 量。圧縮および伸長におけるメモリ利用制限。これを表示して正常終了します。

-h, --help
    よく利用されるオプションに対するヘルプメッセージを表示して、正常終了します。

-H, --long-help
    xz の全機能を説明するヘルプメッセージを表示して、正常終了します。

-V, --version
    xz と liblzma のバージョン番号を読みやすい書式で表示します。マシンが解析しやすい出力とするには、--version の前に --robot を指定します。

ロボットモード
ロボットモードは --robot オプションを指定することで有効になります。これを指定すると、別プログラムが xz の出力を解析しやすくなります。今のところ --robot は、--version, --info-memory, --list をともに指定したときのみ機能するようになっています。将来は圧縮時、伸長時にも対応する予定です。

  バージョン
xz --robot --version を実行すると、xz と liblzma のバージョンを以下の書式により出力します:

XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS

X   メジャーバージョン。

YYY マイナーバージョン。偶数が安定版を意味します。奇数はアルファ版かベータ版を表します。

ZZZ 安定版に対するパッチレベル。または単に開発版の割り振り番号。

S   安定度。0 はアルファ版、1 はベータ版、2 は安定版をそれぞれ表します。YYY が偶数のとき S は必ず 2 となります。

xz と liblzma が同一 XZ Utils リリースのものである限り、2 行に表示されている XYYYZZZS の表記は同一になります。

例： 4.999.9beta は 49990091、5.0.0 は 50000002 と表記されます。

  メモリ制限に関する情報
xz --robot --info-memory を指定すると、タブで区切った 3 つの情報を 1 行で出力します：

1.  物理メモリ (RAM) の総容量。バイト単位。

2.  圧縮時のメモリ利用制限。バイト単位。特別な値としてゼロがあります。これはシングルスレッドモードでのデフォルト値であり、無制限を意味します。

3.  伸長時のメモリ利用制限。バイト単位。特別な値としてゼロがあります。これはシングルスレッドモードでのデフォルト値であり、無制限を意味します。

xz --robot --info-memory の出力項目は、今後追加される可能性があります。ただし複数行にわたって出力するような変更は行いません。

  リストモード
xz --robot --list はタブ区切りによる出力を行います。各行における先頭カラムは、それぞれの行に示される情報の種類を表します。

name
    ファイルの一覧を示す際にはこれが必ず第 1 行目に置かれます。その行の第 2 カラムにはファイル名が出力されます。

file
    この行には .xz ファイルに関する全体的な情報が示されます。この行は必ず name 行の次に表示されます。

stream
    この行タイプは --verbose が指定された場合にのみ表示されます。.xz ファイル内に存在するストリーム分だけ stream 行が出力されます。

block
    この行タイプは --verbose が指定された場合にのみ表示されます。.xz ファイル内に存在するブロック分だけ block 行が出力されます。block 行は stream 行の出力がすべて行われた後に出力されます。つまりタイプの異なる両者が混在して出力されることはありません。

summary
    この行タイプは --verbose が 2 重に指定された場合にのみ表示されます。この行は block 行の次に出力されます。file 行と同様に summary 行には .xz ファイルに関する全体的な情報が示されます。

totals
    本行は必ず出力結果の最終行に位置します。ここには総数、総サイズが示されます。

file 行のカラム：
    2.  ファイル内のストリーム数。
    3.  ストリーム内のブロック総数。
    4.  ファイルの圧縮サイズ。
    5.  ファイルの伸長サイズ。
    6.  圧縮率。たとえば 0.123 など。圧縮率が 9.999 を超える場合は、圧縮率は表示せず 3 つのダッシュ (---) が表示されます。
    7.  整合性チェックの名称をカンマ区切りで指定したリスト。既知の整合性チェック名として、以下の表記が用いられます。None, CRC32, CRC64, SHA-256。未知のチェックタイプには Unknown-N が用いられます。ここで N は 10 進数 (1 桁または 2 桁) で表されるチェック ID です。
    8.  ファイル内ストリームのパディング (padding) データの総量。

stream 行のカラム：
    2.  ストリーム番号 (先頭を 1 とします)。
    3.  ストリーム内のブロック数。
    4.  圧縮データの開始オフセット。
    5.  伸長データの開始オフセット。
    6.  圧縮サイズ (ストリームパディングを含みません)。
    7.  伸長サイズ。
    8.  圧縮率。
    9.  整合性チェック名。
    10. ストリームパディングのサイズ。

block 行のカラム：
    2.  当ブロックに含まれるストリーム数。
    3.  ストリーム先頭からの相対的なブロック数 (先頭ブロックを 1 とします)。
    4.  ファイル先頭からの相対的なブロック数。
    5.  ファイル先頭からの相対的な圧縮開始オフセット。
    6.  ファイル先頭からの相対的な伸長開始オフセット。
    7.  ブロックの総圧縮サイズ (ヘッダーを含みます)。
    8.  伸長サイズ。
    9.  圧縮率。
    10. 整合性チェック名。

--verbose が 2 重に指定された場合、block 行にはさらに以下のカラムが出力されます。これは --verbose が 1 つだけ指定された際には表示されません。この情報取得にあたってはさらにシークを必要とするため、その分だけ処理が遅くなります。
    11. 16 進数表記による整合性チェック値。
    12. ブロックヘッダーサイズ。
    13. ブロックフラグ。c は圧縮サイズが存在することを示します。u は伸長サイズが存在することを示します。このフラグが設定されていない場合、固定幅の文字出力は行わずにダッシュ (-) だけを表示します。将来の版においては、新しいフラグがこの文字列の後ろに追加されるかもしれません。
    14. ブロック内の実際の圧縮データサイズ (ブロックヘッダー、ブロックパディング、チェック項目は除きます)。
    15. xz の現バージョンを使って、このブロックの伸長を行うために必要となるメモリ利用量。バイト単位。
    16. フィルターチェーン。圧縮時に利用されたオプションは、ほとんど知ることができません。.xz ヘッダーにオプションが保存されますが、それは伸長時に必要となるオプションだけだからです。

summary 行のカラム：
    2.  xz の現バージョンを使って、このファイルの伸長を行うために必要となるメモリ利用量。バイト単位。
    3.  yes または no。全ブロックヘッダー内に、圧縮サイズと伸長サイズがともに保存されているかどうかを表します。
    xz 5.1.2alpha 以降：
    4.  ファイル伸長に必要となる xz の最低バージョン。

totals 行のカラム：
    2.  ストリーム数。
    3.  ブロック数。
    4.  圧縮サイズ。
    5.  伸長サイズ。
    6.  圧縮率の平均。
    7.  ファイル内に存在している整合性チェック名をカンマで区切ったリスト。
    8.  ストリームパディングのサイズ。
    9.  ファイル数。ここにこのカラムを設けることで、これ以前のカラムの並びが file 行と同じになるようにします。

--verbose が 2 重に指定され totals 行にカラムが追加された場合：
    10. xz の現バージョンを使って、このファイルの伸長を行うために必要となる最大メモリ利用量。バイト単位。
    11. yes または no。全ブロックヘッダー内に、圧縮サイズと伸長サイズがともに保存されているかどうかを表します。
    xz 5.1.2alpha 以降：
    12. ファイル伸長に必要となる xz の最低バージョン。

将来の版において、新たな行タイプの追加、あるいは既存の行タイプへのカラム追加があるかもしれません。ただし既存のカラムが変更されることはありません。

終了ステータス

0   正常終了。

1   エラー発生。

2   警告に相当する何かが発生。ただし実際のエラーが発生したわけではない。

通知 (警告やエラーではない) が標準エラー出力に表示されても、終了ステータスには影響しません。

環境変数
xz では環境変数 XZ_DEFAULTS および XZ_OPT からこの順で、設定された空白区切りのオプションを読み込みます。これは、コマンドラインから指定されたオプションよりも前に処理されます。環境変数から読み取られるのはオプションだけです。オプション以外の情報はすべて無視されます。オプションの読み込みは getopt_long(3) を使って行われますが、コマンドライン引数の読み込みにも用いられています。

XZ_DEFAULTS
    ユーザー定義あるいはシステムワイドなデフォルトオプションを指定します。通常はシェル初期化スクリプト内において設定され、デフォルトで利用する xz のメモリ利用制限処理を有効にします。シェル初期化スクリプトあるいはこれに相当する特別なケースを除くと、スクリプトにおいて XZ_DEFAULTS を設定したり未設定にしたりしてはなりません。

XZ_OPT
    xz コマンドラインからオプション指定ができない場合に、B(xz) にオプションを受け渡すために用います。これを利用するのは、たとえばスクリプトから、あるいは GNU tar(1) のようなツールから xz を実行する場合です:

        XZ_OPT=-2v tar caf foo.tar.xz foo

    スクリプトにおいてそのスクリプト固有のデフォルト圧縮オプションを設定するために XZ_OPT を用いる場合があります。その場合であっても XZ_OPT のオーバーライドが認められるのは、たとえば以下に示すように sh(1) スクリプト内にて妥当な利用の仕方をする場合に限ります：

        XZ_OPT=${XZ_OPT-"-7e"}
        export XZ_OPT

LZMA Utils との互換性
xz のコマンドラインの文法は、実質的に LZMA Utils 4.32.x にある lzma, unlzma, lzcat のスーパーセットになっています。LZMA Utils を用いる既存のスクリプトは、たいていは特に変更することなくそのまま XZ Utils に置き換えることができます。ただし非互換性も存在しており、中には問題が発生する場合もあります。

  圧縮プリセットレベル
圧縮レベルのプリセット値は xz と LZMA Utils において同一の番号振りにはなっていません。もっとも重要な違いは、さまざまなプリセットに対する辞書サイズがどのように割り振られているか、という点です。辞書サイズは、おおまかに言えば伸長処理時のメモリ利用量に等しくなります。

    レベル | xz | LZMA Utils
    -0 | 256 KiB | なし
    -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

辞書サイズの違いは、圧縮時でのメモリ利用量にも影響します。ただし LZMA Utils と XZ Utils の違いは他にあって、その違いの方がより大きなものです。

    レベル | xz | LZMA Utils 4.32.x
    -0 | 3 MiB | なし
    -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

デフォルトのプリセットレベルは LZMA Utils では -7 ですが、XZ Utils では -6 です。ともにデフォルトで 8 MiB の辞書を利用します。

  ストリーム化されている/されていない .lzma ファイル
ファイルの伸長サイズは .lzma ヘッダーに保存されます。LZMA Utils は、通常のファイルを圧縮する際にはこれを保存します。代替策として、伸長サイズが不明であるとマークしておき、ペイロード終了マーカー (end-of-payload marker) を使って伸長処理の終了位置を示すこともあります。LZMA Utils はこの方法を、伸長サイズが不明なときに利用します。たとえばパイプを使った場合がこの利用にあたります。

xz では .lzma ファイルを伸長する際に、ペイロード終了マーカーを利用することも利用しないこともできます。しかし xz から生成された すべての .lzma に対しては、ペイロード終了マーカーを利用して、.lzma ヘッダー内に伸長サイズが不明であるものとしてマークします。これは特殊なケースで問題となる場合があります。たとえば埋め込みデバイス上での .lzma 伸長処理は、伸長サイズがわかっていないファイルでは動作しないかもしれません。このような問題に遭遇した場合は、LZMA Utils または LZMA SDK を利用して、伸長サイズが明確となっている .lzma ファイルを生成してください。

  サポートされない .lzma ファイル
.lzma フォーマットが用いる lc 値は 8 まで、lp 値は 4 までです。LZMA Utils がファイル伸長する際には lc と lp の値はどのような値であってもかまいませんが、ただし lc=3 かつ lp=0 のファイルが常に生成されます。これ以外の lc や lp を生成するには xz か LZMA SDK を利用してください。

liblzma 内の LZMA1 フィルターの実装では、lc と lp の合計が 4 を超えてはならないものとなっています。したがってこの制限を超えた .lzma ファイルは xz を使って伸長することはできません。

LZMA Utils が生成する .lzma ファイルは、辞書サイズが 2^n (2 のべき乗) のものだけです。ただしどのようなサイズのファイルでも受けることはできます。一方 liblzma が受け付けられるのは、辞書サイズが 2^n または 2^n + 2^(n-1) であるような .lzma ファイルのみです。これは .lzma ファイルを検出する際に、誤った検出を回避するためです。

上のような制約は現実に問題となることはありません。事実上 .lzma ファイルは liblzma が受け入れる設定すべてを使って圧縮されるものとなっているからです。

  ゴミデータ
LZMA Utils は伸長時に、最初の .lzma ストリーム以降のデータは完全に無視します。ほとんどの場合、これはバグになります。これはまた LZMA Utils が、連結された .lzma ファイルを伸長できないことを表しています。

.lzma の最初のストリーム以降にデータが残っている場合、xz は --single-stream が指定されていない限りは、そのファイルが壊れているとみなします。したがって、ゴミデータは無視されるという前提で作られているスクリプトは、動作しなくなるかもしれません。

情報

  圧縮結果はさまざま
同一の圧縮前ファイルを使って圧縮ファイルを生成したとしても、XZ Utils のバージョンが異なると、その生成結果は異なることになります。それは圧縮オプションが全く同じであっても起こります。ファイルフォーマットに影響を与えることなく、エンコード処理は常に (より高速に、より高圧縮に) 改善されているためです。XZ Utils のバージョンが同一であっても、ビルド時のオプションが違っていると、生成結果が異なる場合があります。

このことは --rsyncable が実装された際には問題となります。rsync の機能を用いる際には、古いファイルと新しいファイルを同一の xz バージョンで圧縮しておかないと、rsync 処理ができないということになります。この問題を解決するには、どちらかのエンコード実装を凍結して、xz バージョン間において安定して rsync 処理ができるような出力とすることが必要になります。

  埋め込み .xz の伸長処理
XZ Embedded のような埋め込み .xz 伸長処理の実装では、整合性チェックのうち none と crc32 以外のものを使ったファイル生成には対応する必要がありません。デフォルトは --check=crc64 ですから、埋め込みシステム上でのファイル生成時は --check=none か --check=crc32 を指定しなければなりません。

埋め込みシステムを除くと、.xz フォーマットにおける伸長処理では、check タイプすべてに対応しています。あるいは特定の check がサポートされていなかったとしても、最低でも整合性チェックの検証を行わずにファイル伸長処理が可能となっています。

XZ Embedded は BCJ フィルターに対応しています。ただしデフォルトの開始オフセットしか利用できません。

利用例

  基本
ファイル foo を圧縮して foo.xz を生成します。利用する圧縮レベルはデフォルト (-6) です。圧縮が成功したら foo を削除します:

    xz foo

bar.xz を伸長して bar を得ます。伸長処理に成功しても bar.xz は削除しません:

    xz -dk bar.xz

プリセット -4e (-4 --extreme) を用いて baz.tar.xz を生成します。これはたとえばデフォルトの -6 に比べて処理速度は低下しますが、圧縮時や伸長時のメモリ消費は少なくて済みます (それぞれ 48 MiB と 5 MiB)：

    tar cf - baz | xz -4e > baz.tar.xz

圧縮されたファイルや未圧縮のファイルを混在させ、ただ 1 つのコマンドを使って標準出力を行うことができます:

    xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt

  複数ファイルの並行圧縮処理
GNU および *BSD の find(1) や xargs(1) では、複数ファイルを並行処理により圧縮することができます:

    find . -type f \! -name '*.xz' -print0 \
        | xargs -0r -P4 -n16 xz -T1

xargs(1) に対する -P オプションが、xz 処理に対する並行処理数を設定しています。-n オプションの最適値は、どれだけのファイルを圧縮するかによって変わります。ファイル数がほんの数個である場合、おそらくこの値は 1 が適切です。ファイル数が数万のレベルなら 100 以上が適切であり、これによって xargs(1) が最終的に作り出す xz プロセスを抑えられます。

xz に対してオプション -T1 を指定していますが、これは強制的にシングルスレッドモードにするためです。並行処理数の制御のために、既に xargs(1) が使用されているからです。

  ロボットモード
複数ファイルを圧縮したことによって、合計で何バイト分が保存されたかを計算します:

    xz --robot --list *.xz | awk '/^totals/{print $5-$4}'

スクリプト実行の際には、利用している xz が最新版であるかどうかを確認したい場合があります。以下の sh(1) スクリプトでは、xz ツールのバージョン番号が最低でも 5.0.0 であるかどうかを確認しています。この方法は --robot オプションに対応していない古いベータ版に対しても利用できます:

    if ! eval "$(xz --robot --version 2> /dev/null)" ||
            [ "$XZ_VERSION" -lt 50000002 ]; then
        echo "Your xz is too old."
    fi
    unset XZ_VERSION LIBLZMA_VERSION

XZ_OPT を利用して伸長時のメモリ利用制限を設定します。ただしすでに設定されていた場合、その設定が増えることはありません:

    NEWLIM=$((123 << 20))  # 123 MiB
    OLDLIM=$(xz --robot --info-memory | cut -f3)
    if [ $OLDLIM -eq 0 -o $OLDLIM -gt $NEWLIM ]; then
        XZ_OPT="$XZ_OPT --memlimit-decompress=$NEWLIM"
        export XZ_OPT
    fi

  カスタム圧縮フィルターチェーン
カスタムフィルターチェーンを利用する一番簡単な方法は LZMA2 プリセットを用いることです。プリセットには、圧縮設定の中から有用な設定を組み合わせて、その一部を割り当てているため、それを使うのが簡単です。

オプション -0 ... -9, --extreme のところで説明した一覧表内の CompCPU カラムは、LZMA2 プリセット値をカスタマイズする際に活用できます。上で説明済の 2 つの表から、関連するところを抜粋したものが以下です:

    プリセット | CompCPU
    -0 | 0
    -1 | 1
    -2 | 2
    -3 | 3
    -4 | 4
    -5 | 5
    -6 | 6
    -5e | 7
    -6e | 8

効率よく圧縮するためには、ある程度大きな (たとえば 32 MiB 程度の) 辞書が必要であることがわかっているとします。一方で xz -8 の指定時よりも速く処理がしたいとします。その場合は CompCPU 値が低い (たとえば 1 であるような) プリセットを使えば、より大きな辞書を利用するように調整ができます:

    xz --lzma2=preset=1,dict=32MiB foo.tar

ファイルによっては、上のコマンドの実行により、圧縮効率が著しく改善されて xz -6 よりも高速処理される場合があります。ただし CompCPU 値を低くしたとしても、大きな辞書を使ったことが効果を発揮するようなファイルは限られることは強調しておきます。大きな辞書を用いた効果が発揮される状況は、おそらく最低数メガバイトの総量で、似通ったファイルを含むアーカイブである場合です。辞書サイズは、個々のファイルに比べれば十分に大きなサイズにする必要があります。そうしておけば、LZMA2 が並んだファイルの類似性に対して効果を発揮する処理を行ってくれます。

仮に圧縮時や伸長時のメモリ利用を大きな値とするのが有効であり、また圧縮するファイルが最低でも数 100 メガバイトあるなら、xz -9 が利用する辞書サイズ 64 MiB よりもさらに大きなサイズを利用するのが効果的かもしれません:

    xz -vv --lzma2=dict=192MiB big_foo.tar

上の利用例に示しているように -vv (--verbose --verbose) を用いると、圧縮および伸長におけるメモリ必要量が確認できます。なお伸長ファイルサイズよりも大きな辞書を利用すると、メモリを無駄に消費します。したがって上のコマンドは、容量が少ないファイルに対しては効果が期待できません。

圧縮時間は問題にならないこともあります。しかし伸長時のメモリ利用量は低く抑えるべきです。たとえば埋め込みシステムでは、ファイル伸長時のメモリ利用は極力低く抑えたいところです。以下のコマンドでは、基本として -6e (-6 --extreme) を利用し、辞書サイズは 64 KiB と小さくしています。XZ Embedded を利用すると (だからこそ --check=crc32 を用いるのですが)、伸長処理によるファイル生成の際には 100 KiB のメモリ利用に抑えられます。

    xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo

できるだけ多くのバイトを圧縮したい場合は、リテラルコンテキスト (lc) ビット値と、ポジションビット (pb) を調整するのが有効になる場合があります。リテラルポジションビット (lp) の調整も有効かもしれませんが、通常は lc と pb の方が重要です。たとえばソースコードアーカイブと言えば、ほとんどが US-ASCII テキストであるため、以下に示すように処理すれば、xz -6e の処理よりもほんの少しだけ (0.1 % 程度) 小さくなります (lc=4 を除いた処理も試してください):

    xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar

特定のファイルタイプに対しては、LZMA2 に別のフィルターを加えることで、圧縮処理が改善することがあります。たとえば x86-32 や x86-64 の共有ライブラリに対しては x86 BCJ フィルターを使うことがこれにあたります:

    xz --x86 --lzma2 libfoo.so

フィルターオプションの並びは重要です。--x86 が --lzma2 の後ろに指定されると xz はエラーを表示します。この理由は LZMA2 の後ろにフィルターを置くことはできないためであり、さらに x86 BCJ フィルターはチェーン内の最終フィルターにすることもできないからです。

LZMA2 にデルタフィルターを合わせて利用すると、ビットマップイメージに対しては良好な結果が得られます。この結果は通常、PNG を上回るはずです。PNG には単純なデルタよりも高度なフィルターがいくつかありますが、実際の圧縮にあたっては Deflate が用いられています。

イメージデータは非圧縮形式で保存する必要があります。たとえば非圧縮の TIFF データなどです。デルタフィルターの距離パラメーターは、イメージ内におけるピクセルあたりのバイト数にマッチするように設定されています。たとえば 24 ビット RGB ビットマップには dist=3 が必要です。また LZMA2 に対しては pb=0 を指定して 3 バイト並びに対応させるのが適切です:

    xz --delta=dist=3 --lzma2=pb=0 foo.tiff

複数のイメージが 1 つのアーカイブ (たとえば .tar) にまとめられているときは、個々のイメージのピクセルあたりのバイト数が同一である場合に限って、デルタフィルターは同様に動作します。

関連項目
xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)

XZ Utils: <https://tukaani.org/xz/>
埋め込み XZ: <https://tukaani.org/xz/embedded.html>
LZMA SDK: <http://7-zip.org/sdk.html>