メモリ利用¶

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

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

-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 に指定します。

-C check, --check=check

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

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

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

--ignore-check

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

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

-0 ... -9

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

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

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

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

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

-e, --extreme

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

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

たとえば 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 を指定する方法はいくつかあります。

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 は共通しています。

生の (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 フィルターには、圧縮率に関して以下のような問題があります。

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

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

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

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

--delta[=options]

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

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

サポートされている options：

その他のオプション¶

-q, --quiet

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

-v, --verbose

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

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

標準エラー出力先が端末ではない場合、--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 を指定します。

バージョン¶

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 行のカラム：

stream 行のカラム：

block 行のカラム：

--verbose が 2 重に指定された場合、block 行にはさらに以下のカラムが出力されます。これは --verbose が 1 つだけ指定された際には表示されません。この情報取得にあたってはさらにシークを必要とするため、その分だけ処理が遅くなります。

summary 行のカラム：

totals 行のカラム：

--verbose が 2 重に指定され totals 行にカラムが追加された場合：

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

圧縮プリセットレベル¶

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

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

デフォルトのプリセットレベルは 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 つの表から、関連するところを抜粋したものが以下です:

効率よく圧縮するためには、ある程度大きな (たとえば 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) にまとめられているときは、個々のイメージのピクセルあたりのバイト数が同一である場合に限って、デルタフィルターは同様に動作します。