xz, unxz, xzcat, lzma, unlzma, lzcat: comprimir o descomprimir archivos .xz y .lzma
SINTAXIS
xz [opción...] [archivo...]
ALIASES DE COMANDOS
unxz es equivalente a xz --descomprimir.
xzcat es equivalente a xz --descomprimir --salida_estándar.
lzma es equivalente a xz --formato=lzma.
unlzma es equivalente a xz --formato=lzma --descomprimir.
lzcat es equivalente a xz --formato=lzma --descomprimir --salida_estándar.
Cuando se escriben scripts que deben descomprimir archivos, se recomienda utilizar siempre el nombre xz con los argumentos apropiados (xz -d o xz -dc) en lugar de los nombres unxz y xzcat.
DESCRIPCIÓN
xz es una herramienta de compresión de datos de propósito general con una sintaxis de línea de comandos similar a gzip(1) y bzip2(1). El formato de archivo nativo es el formato .xz, pero también se admiten el formato .lzma heredado utilizado por LZMA Utils y los flujos comprimidos sin encabezados de formato de contenedor. Además, se admite la descompresión del formato .lz utilizado por lzip.
xz comprime o descomprime cada archivo según el modo de operación seleccionado. Si no se especifican archivos
o el archivo es -, xz lee desde la entrada estándar y escribe los datos procesados en la salida estándar. xz rechazará (mostrará un error y omitirá el archivo) escribir datos comprimidos en la salida estándar si es un terminal. De manera similar, xz rechazará leer datos comprimidos desde la entrada estándar si es un terminal.
A menos que se especifique --salida_estándar, los archivos que no sean - se escriben en un archivo nuevo cuyo nombre se deriva del nombre del archivo de origen:
Cuando se comprime, el sufijo del formato de archivo de destino (.xz o .lzma) se agrega al nombre de archivo de origen para obtener el nombre de archivo de destino.
Cuando se descomprime, el sufijo .xz, .lzma o .lz se elimina del nombre de archivo para obtener el nombre de archivo de destino. xz también reconoce los sufijos .txz y .tlz, y los reemplaza con el sufijo .tar.
Si el archivo de destino ya existe, se muestra un error y el archivo se omite.
A menos que se escriba en la salida estándar, xz mostrará una advertencia y omitirá el archivo si se aplica alguna de las siguientes condiciones:
El archivo no es un archivo regular. Los enlaces simbólicos no se siguen y, por lo tanto, no se consideran archivos regulares.
El archivo tiene más de un enlace duro.
El archivo tiene los bits setuid, setgid o sticky establecidos.
El modo de operación está configurado para comprimir y el archivo ya tiene un sufijo del formato de archivo de destino (.xz o .txz al comprimir al formato .xz, y .lzma o .tlz al comprimir al formato .lzma).
El modo de operación está configurado para descomprimir y el archivo no tiene un sufijo de ninguno de los formatos de archivo admitidos (.xz, .txz, .lzma, .tlz o .lz).
Después de comprimir o descomprimir correctamente el archivo, xz copia el propietario, el grupo, los permisos, la hora de acceso y la hora de modificación del archivo de origen al archivo de destino. Si falla la copia del grupo, los permisos se modifican para que el archivo de destino no sea accesible para los usuarios que no tenían permiso para acceder al archivo de origen. xz no admite la copia de otros metadatos, como listas de control de acceso o atributos extendidos, por el momento.
Una vez que el archivo de destino se ha cerrado correctamente, el archivo de origen se elimina a menos que se especifique --keep. El archivo de origen nunca se elimina si la salida se escribe en la salida estándar o si se produce un error.
Enviar SIGINFO o SIGUSR1 al proceso xz hace que imprima información de progreso en la salida de error estándar. Esto tiene un uso limitado, ya que cuando la salida de error estándar es una terminal, el uso de --verbose mostrará un indicador de progreso de actualización automática.
Uso de memoria
El uso de memoria de xz varía desde unos pocos cientos de kilobytes hasta varios gigabytes, dependiendo de la configuración de compresión. La configuración utilizada al comprimir un archivo determina los requisitos de memoria del descompresor. Normalmente, el descompresor necesita entre el 5% y el 20% de la cantidad de memoria que necesitaba el compresor al crear el archivo. Por ejemplo, la descompresión de un archivo creado con xz -9 requiere actualmente 65 MiB de memoria. Sin embargo, es posible tener archivos .xz que requieran varios gigabytes de memoria para descomprimirlos.
Los usuarios de sistemas más antiguos pueden encontrar especialmente molesto la posibilidad de un uso de memoria muy grande. Para evitar sorpresas desagradables, xz tiene un limitador de uso de memoria integrado, que está desactivado de forma predeterminada. Si bien algunos sistemas operativos proporcionan formas de limitar el uso de memoria de los procesos, se consideró que depender de ello no era lo suficientemente flexible (por ejemplo, el uso de ulimit(1) para limitar la memoria virtual tiende a perjudicar mmap(2)).
El limitador de uso de memoria se puede habilitar con la opción de línea de comandos --memlimit=límite. A menudo, es más conveniente habilitar el limitador de forma predeterminada configurando la variable de entorno XZ_DEFAULTS, por ejemplo, XZ_DEFAULTS=--memlimit=150MiB. Es posible establecer los límites por separado para la compresión y la descompresión mediante --memlimit-compress=límite y --memlimit-decompress=límite. El uso de estas dos opciones fuera de XZ_DEFAULTS rara vez es útil porque una sola ejecución de xz no puede realizar tanto la compresión como la descompresión y --memlimit=límite (o -M límite) es más corto de escribir en la línea de comandos.
Si se excede el límite de uso de memoria especificado al descomprimir, xz mostrará un error y la descompresión del archivo fallará. Si se excede el límite al comprimir, xz intentará escalar la configuración para que el límite ya no se exceda (excepto cuando se utiliza --format=raw o --no-adjust). De esta manera, la operación no fallará a menos que el límite sea muy pequeño. La escala de la configuración se realiza en pasos que no coinciden con las configuraciones preestablecidas del nivel de compresión; por ejemplo, si el límite es solo ligeramente inferior a la cantidad requerida para xz -9, la configuración solo se reducirá un poco, no se reducirá por completo a xz -8.
Concatenación y relleno con archivos .xz
Es posible concatenar archivos .xz tal cual. xz descomprimirá dichos archivos como si fueran un único archivo .xz.
Es posible insertar relleno entre las partes concatenadas o después de la última parte. El relleno debe consistir en bytes nulos y el tamaño del relleno debe ser un múltiplo de cuatro bytes. Esto puede ser útil, por ejemplo, si el archivo .xz se almacena en un medio que mide los tamaños de archivo en bloques de 512 bytes.
La concatenación y el relleno no están permitidos con archivos .lzma o flujos sin comprimir.
OPCIONES
Sufijos de enteros y valores especiales
En la mayoría de los lugares donde se espera un argumento entero, se admite un sufijo opcional para indicar fácilmente enteros grandes. No debe haber espacio entre el entero y el sufijo.
KiB Multiplica el entero por 1.024 (2^10). Ki, k, kB, K y KB se aceptan como sinónimos de KiB.
MiB Multiplica el entero por 1.048.576 (2^20). Mi, m, M y MB se aceptan como sinónimos de MiB.
GiB Multiplica el entero por 1.073.741.824 (2^30). Gi, g, G y GB se aceptan como sinónimos de GiB.
El valor especial max se puede usar para indicar el valor entero máximo admitido por la opción.
Modo de operación
Si se proporcionan varias opciones de modo de operación, la última tiene efecto.
-z, --compress
Comprimir. Este es el modo de operación predeterminado cuando no se especifica ninguna opción de modo de operación y ningún otro modo de operación se infiere del nombre del comando (por ejemplo, unxz implica --decompress).
Después de una compresión exitosa, el archivo de origen se elimina a menos que se escriba en la salida estándar o se especifique --keep.
-d, --decompress, --uncompress
Descomprimir. Después de una descompresión exitosa, el archivo de origen se elimina a menos que se escriba en la salida estándar o se especifique --keep.
-t, --test
Probar la integridad de los archivos comprimidos. Esta opción es equivalente a --decompress --stdout, excepto que los datos descomprimidos se descartan en lugar de escribirse en la salida estándar. No se crean ni eliminan archivos.
-l, --list
Imprimir información sobre los archivos comprimidos. No se produce ninguna salida descomprimida y no se crean ni eliminan archivos. En el modo de lista, el programa no puede leer los datos comprimidos desde la entrada estándar o desde otras fuentes no buscables.
La lista predeterminada muestra información básica sobre los archivos, un archivo por línea. Para obtener información más detallada, también use la opción --verbose. Para obtener aún más información, use --verbose dos veces, pero tenga en cuenta que esto puede ser lento, ya que obtener toda la información adicional requiere muchos accesos. El ancho de la salida detallada excede los 80 caracteres, por lo que canalizar la salida a, por ejemplo, less -S puede ser conveniente si la terminal no es lo suficientemente ancha.
La salida exacta puede variar entre las diferentes versiones de xz y los distintos entornos locales. Para obtener una salida legible por máquina, se deben usar las opciones --robot y --list.
Modificadores de operación
-k, --keep
No eliminar los archivos de entrada.
Desde xz 5.2.6, esta opción también hace que xz comprima o descomprima incluso si la entrada es un enlace simbólico a un archivo regular, tiene más de un enlace duro o tiene los bits setuid, setgid o sticky activados. Los bits setuid, setgid y sticky no se copian al archivo de destino. En versiones anteriores, esto solo se hacía con --force.
-f, --force
Esta opción tiene varios efectos:
Si el archivo de destino ya existe, lo elimina antes de comprimir o descomprimir.
Comprime o descomprime incluso si la entrada es un enlace simbólico a un archivo regular, tiene más de un enlace duro o tiene los bits setuid, setgid o sticky activados. Los bits setuid, setgid y sticky no se copian al archivo de destino.
Cuando se utiliza con --decompress --stdout y xz no puede reconocer el tipo del archivo de origen, copia el archivo de origen tal cual a la salida estándar. Esto permite que xzcat --force se utilice como cat(1) para archivos que no han sido comprimidos con xz. Tenga en cuenta que, en el futuro, xz podría admitir nuevos formatos de archivos comprimidos, lo que podría hacer que xz descomprima más tipos de archivos en lugar de copiarlos tal cual a la salida estándar. La opción --format=format se puede utilizar para restringir xz a descomprimir solo un solo formato de archivo.
-c, --stdout, --to-stdout
Escribe los datos comprimidos o descomprimidos en la salida estándar en lugar de un archivo. Esto implica --keep.
--single-stream
Descomprime solo el primer flujo .xz e ignora silenciosamente los posibles datos de entrada restantes que sigan al flujo. Normalmente, esta información adicional provoca que xz muestre un error.
xz nunca descomprime más de un flujo de los archivos .lzma o de los flujos sin procesar, pero esta opción sigue haciendo que xz ignore los posibles datos posteriores al archivo .lzma o al flujo sin procesar.
Esta opción no tiene efecto si el modo de operación no es --decompress o --test.
Desde xz 5.7.1alpha, --single-stream implica --keep.
--no-sparse
Desactiva la creación de archivos dispersos. Por defecto, si se descomprime en un archivo regular, xz intenta hacer que el archivo sea disperso si los datos descomprimidos contienen secuencias largas de ceros binarios. También funciona cuando se escribe en la salida estándar, siempre y cuando la salida estándar esté conectada a un archivo regular y se cumplan ciertas condiciones adicionales para que sea seguro. La creación de archivos dispersos puede ahorrar espacio en disco y acelerar la descompresión al reducir la cantidad de E/S de disco.
-S .suf, --suffix=.suf
Cuando se comprime, utiliza .suf como sufijo para el archivo de destino en lugar de .xz o .lzma. Si no se escribe en la salida estándar y el archivo de origen ya tiene el sufijo .suf, se muestra una advertencia y el archivo se omite.
Cuando se descomprime, reconoce los archivos con el sufijo .suf además de los archivos con los sufijos .xz, .txz, .lzma, .tlz o .lz. Si el archivo de origen tiene el sufijo .suf, se elimina el sufijo para obtener el nombre del archivo de destino.
Cuando se comprimen o descomprimen flujos sin formato (--format=raw), el sufijo debe especificarse siempre, a menos que se escriba en la salida estándar, porque no existe un sufijo predeterminado para los flujos sin formato.
--files[=archivo]
Leer los nombres de archivo para procesar desde el archivo; si se omite el archivo, los nombres de archivo se leen desde la entrada estándar. Los nombres de archivo deben terminarse con el carácter de nueva línea. Un guión (-) se toma como un nombre de archivo normal; no significa entrada estándar. Si también se proporcionan nombres de archivo como argumentos de la línea de comandos, se procesan antes de los nombres de archivo leídos desde el archivo.
--files0[=archivo]
Esto es idéntico a --files[=archivo] excepto que cada nombre de archivo debe terminarse con el carácter nulo.
Opciones básicas de formato de archivo y compresión
-F formato, `--format=formato`
Especificar el formato de archivo para comprimir o descomprimir:
auto Este es el valor predeterminado. Cuando se comprime, auto es equivalente a xz. Cuando se descomprime, el formato del archivo de entrada se detecta automáticamente. Tenga en cuenta que los flujos sin formato (creados con `--format=raw`) no se pueden detectar automáticamente.
xz Comprimir en el formato de archivo .xz, o aceptar solo archivos .xz cuando se descomprime.
lzma, solo
Comprimir en el formato de archivo .lzma heredado, o aceptar solo archivos .lzma cuando se descomprime. El nombre alternativo solo se proporciona para la compatibilidad con versiones anteriores con LZMA Utils.
lzip Aceptar solo archivos .lz cuando se descomprime. La compresión no es compatible.
Los formatos de archivo .lz versión 0 y 1 son compatibles. Los archivos de la versión 0 fueron producidos por lzip 1.3 y versiones anteriores. Estos archivos no son comunes, pero se pueden encontrar en archivos como algunos paquetes de origen se lanzaron en este formato. Es posible que algunas personas tengan archivos personales antiguos en este formato. El soporte de descompresión para la versión del formato 0 se eliminó en lzip 1.18. lzip 1.4 y versiones posteriores crean archivos en la versión del formato 1.
raw Comprimir o descomprimir un flujo sin formato (sin encabezados). Esto es solo para usuarios avanzados. Para decodificar flujos sin formato, debe usar `--format=raw` y especificar explícitamente la cadena de filtros, que normalmente se habría almacenado en los encabezados del contenedor.
-C comprobación, `--check=comprobación`
Especificar el tipo de comprobación de integridad. La comprobación se calcula a partir de los datos descomprimidos y se almacena en el archivo .xz. Esta opción solo tiene efecto al comprimir en el formato .xz; el formato .lzma no admite comprobaciones de integridad. La comprobación de integridad (si la hay) se verifica cuando se descomprime el archivo .xz.
Tipos de comprobación admitidos:
none No calcular ninguna comprobación de integridad. Generalmente, esto no es una buena idea. Esto puede ser útil cuando la integridad de los datos se verifica por otros medios.
crc32 Calcular CRC32 utilizando el polinomio de IEEE-802.3 (Ethernet).
crc64 Calcular CRC64 utilizando el polinomio de ECMA-182. Este es el valor predeterminado, ya que es ligeramente mejor que CRC32 para detectar archivos dañados y la diferencia de velocidad es insignificante.
sha256 Calcula SHA-256. Esto es algo más lento que CRC32 y CRC64.
La integridad de los encabezados .xz siempre se verifica con CRC32. No es posible cambiar o desactivarlo.
--ignore-check
No verifique la integridad de los datos comprimidos durante la descompresión. Los valores CRC32 en los encabezados .xz se verificarán normalmente.
No utilice esta opción a menos que sepa lo que está haciendo. Posibles razones para utilizar esta opción:
Intentar recuperar datos de un archivo .xz corrupto.
Acelerar la descompresión. Esto es importante sobre todo con SHA-256 o con archivos que se han comprimido muy bien. No se recomienda utilizar esta opción para este propósito a menos que la integridad del archivo se verifique externamente de alguna otra manera.
-0 ... -9
Seleccione un nivel de preajuste de compresión. El valor predeterminado es -6. Si se especifican varios niveles de preajuste, el último tendrá efecto. Si ya se ha especificado una cadena de filtros personalizada, establecer un nivel de preajuste de compresión borrará la cadena de filtros personalizada.
Las diferencias entre los preajustes son más significativas que con gzip(1) y bzip2(1). Los ajustes de compresión seleccionados determinan los requisitos de memoria del descompresor, por lo que el uso de un nivel de preajuste demasiado alto puede dificultar la descompresión del archivo en un sistema antiguo con poca RAM. Específicamente, no es una buena idea utilizar ciegamente -9 para todo, como a menudo se hace con gzip(1) y bzip2(1).
-0 ... -3
Estos son preajustes algo rápidos. -0 a veces es más rápido que gzip -9 al comprimir mucho mejor. Los de nivel superior suelen tener una velocidad comparable a bzip2(1) con una relación de compresión comparable o mejor, aunque los resultados dependen mucho del tipo de datos que se comprimen.
-4 ... -6
Buena a muy buena compresión manteniendo un uso de memoria razonable para el descompresor, incluso para sistemas antiguos. -6 es el valor predeterminado, que suele ser una buena opción para distribuir archivos que deben poder descomprimirse incluso en sistemas con solo 16 MiB de RAM. (-5e o -6e también pueden ser una buena opción. Consulte --extreme).
-7 ... -9
Estos son como -6 pero con mayores requisitos de memoria para el compresor y el descompresor. Estos son útiles solo cuando se comprimen archivos de más de 8 MiB, 16 MiB y 32 MiB, respectivamente.
En el mismo hardware, la velocidad de descompresión es aproximadamente un número constante de bytes de datos comprimidos por segundo. En otras palabras, cuanto mejor sea la compresión, más rápida será la descompresión. Esto también significa que la cantidad de salida descomprimida producida por segundo puede variar mucho.
La siguiente tabla resume las características de los preajustes:
Preset 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
Descripciones de las columnas:
DictSize es el tamaño del diccionario LZMA2. Es un desperdicio de memoria usar un diccionario más grande que el tamaño del archivo descomprimido. Por eso, es bueno evitar el uso de los ajustes -7 ... -9 cuando no sea realmente necesario. En -6 y niveles inferiores, la cantidad de memoria desperdiciada suele ser lo suficientemente baja como para que no importe.
CompCPU es una representación simplificada de la configuración LZMA2 que afecta a la velocidad de compresión. El tamaño del diccionario también afecta a la velocidad, por lo que, aunque CompCPU es el mismo para los niveles -6 ... -9, los niveles más altos suelen ser un poco más lentos. Para obtener una velocidad aún mayor y, por lo tanto, posiblemente una mejor compresión, consulte --extreme.
CompMem contiene los requisitos de memoria del compresor en modo de un solo subproceso. Puede variar ligeramente entre las versiones de xz.
DecMem contiene los requisitos de memoria del descompresor. Es decir, la configuración de compresión determina los requisitos de memoria del descompresor. El uso exacto de memoria del descompresor es ligeramente superior al tamaño del diccionario LZMA2, pero los valores de la tabla se han redondeado al MiB completo más cercano.
Los requisitos de memoria del modo multi-hilo son significativamente mayores que los del modo de un solo subproceso. Con el valor predeterminado de --block-size, cada subproceso necesita 3*3*DictSize más CompMem o DecMem. Por ejemplo, cuatro subprocesos con el ajuste -6 necesitan entre 660 y 670 MiB de memoria.
-e, --extreme
Utilice una variante más lenta del ajuste de compresión seleccionado (-0 ... -9) para obtener, con suerte, una mejor relación de compresión, pero, en el peor de los casos, esto también puede empeorarla. El uso de memoria del descompresor no se ve afectado, pero el uso de memoria del compresor aumenta ligeramente en los niveles de ajuste -0 ... -3.
Dado que hay dos ajustes con tamaños de diccionario de 4 MiB y 8 MiB, los ajustes -3e y -5e utilizan ajustes ligeramente más rápidos (CompCPU más bajo) que -4e y -6e, respectivamente. De esta manera, no hay dos ajustes idénticos.
Ajuste 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
Por ejemplo, hay un total de cuatro ajustes que utilizan un diccionario de 8 MiB, cuyo orden del más rápido al más lento es -5, -6, -5e y -6e.
--fast
--best Estos son alias algo engañosos para -0 y -9, respectivamente. Se proporcionan solo para compatibilidad con versiones anteriores de LZMA Utils. Evite el uso de estas opciones.
--block-size=tamaño
Cuando se comprime al formato .xz, divide los datos de entrada en bloques de tamaño bytes. Los bloques se comprimen de forma independiente entre sí, lo que ayuda con el multi-hilo y permite la descompresión de acceso aleatorio limitado. Esta opción se utiliza normalmente para anular el tamaño de bloque predeterminado en modo multi-hilo, pero esta opción también se puede utilizar en modo de un solo subproceso.
En el modo multi-hilo, se asignarán aproximadamente tres veces más bytes en cada hilo para el almacenamiento en búfer de la entrada y la salida. El tamaño predeterminado es tres veces el tamaño del diccionario LZMA2 o 1 MiB, lo que sea mayor. Normalmente, un buen valor es de 2 a 4 veces el tamaño del diccionario LZMA2 o al menos 1 MiB. El uso de un tamaño inferior al tamaño del diccionario LZMA2 es un desperdicio de RAM porque entonces el búfer del diccionario LZMA2 nunca se utilizará por completo. En el modo multi-hilo, los tamaños de los bloques se almacenan en las cabeceras de los bloques. Esta información de tamaño es necesaria para la descompresión multi-hilo.
En el modo de un solo hilo, no se realiza la división de bloques de forma predeterminada. Establecer esta opción no afecta el uso de la memoria. No se almacena información de tamaño en las cabeceras de los bloques, por lo que los archivos creados en el modo de un solo hilo no serán idénticos a los archivos creados en el modo multi-hilo. La falta de información de tamaño también significa que xz no podrá descomprimir los archivos en el modo multi-hilo.
--block-list=elementos
Cuando se comprime al formato .xz, se inicia un nuevo bloque con una cadena de filtros personalizada opcional después de los intervalos de datos sin comprimir dados.
Los elementos son una lista separada por comas. Cada elemento consiste en un número de cadena de filtros opcional entre 0 y 9 seguido de dos puntos (:) y un tamaño requerido de datos sin comprimir. Omitir un elemento (dos o más comas consecutivas) es una forma abreviada de utilizar el tamaño y los filtros del elemento anterior.
Si el archivo de entrada es mayor que la suma de los tamaños en elementos, el último elemento se repite hasta el final del archivo. Se puede utilizar un valor especial de 0 como el último tamaño para indicar que el resto del archivo debe codificarse como un solo bloque.
Se puede especificar una cadena de filtros alternativa para cada bloque en combinación con las opciones --filters1=filtros ... --filters9=filtros. Estas opciones definen cadenas de filtros con un identificador entre 1 y 9. La cadena de filtros 0 se puede utilizar para hacer referencia a la cadena de filtros predeterminada, que es la misma que no especificar una cadena de filtros. El identificador de la cadena de filtros se puede utilizar antes del tamaño sin comprimir, seguido de dos puntos (:). Por ejemplo, si se especifica --block-list=1:2MiB,3:2MiB,2:4MiB,,2MiB,0:4MiB, entonces se crearán bloques utilizando:
La cadena de filtros especificada por --filters1 y 2 MiB de entrada
La cadena de filtros especificada por --filters3 y 2 MiB de entrada
La cadena de filtros especificada por --filters2 y 4 MiB de entrada
La cadena de filtros especificada por --filters2 y 4 MiB de entrada
La cadena de filtros predeterminada y 2 MiB de entrada
La cadena de filtros predeterminada y 4 MiB de entrada para cada bloque hasta el final de la entrada.
Si se especifica un tamaño que excede el tamaño de bloque del codificador (ya sea el valor predeterminado en el modo de subprocesos o el valor especificado con --block-size=tamaño), el codificador creará bloques adicionales manteniendo los límites especificados en elementos. Por ejemplo, si se especifica --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB y el archivo de entrada es de 80 MiB, se obtendrán 11 bloques: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 y 1 MiB.
En el modo multi-hilo, los tamaños de los bloques se almacenan en las cabeceras de los bloques. Esto no se hace en el modo de un solo hilo, por lo que la salida codificada no será idéntica a la del modo multi-hilo.
--flush-timeout=tiempo_de_espera
Al comprimir, si han pasado más de tiempo_de_espera milisegundos (un número entero positivo) desde el último vaciado y leer más datos de entrada bloquearía, todos los datos de entrada pendientes se vacían del codificador y se ponen a disposición en la secuencia de salida. Esto puede ser útil si xz se utiliza para comprimir datos que se transmiten por una red. Los valores de tiempo de espera pequeños hacen que los datos estén disponibles en el extremo receptor con un pequeño retraso, pero los valores de tiempo de espera grandes ofrecen una mejor relación de compresión.
Esta función está desactivada por defecto. Si esta opción se especifica más de una vez, la última tiene efecto. El valor de tiempo de espera especial de 0 se puede utilizar para desactivar explícitamente esta función.
Esta función no está disponible en sistemas no POSIX.
Esta función sigue siendo experimental. Actualmente, xz no es adecuado para descomprimir la secuencia en tiempo real debido a la forma en que xz realiza el almacenamiento en búfer.
--no-sync
No sincronice el archivo de destino y su directorio con el dispositivo de almacenamiento antes de eliminar el archivo de origen. Esto puede mejorar el rendimiento si se comprimen o descomprimen muchos archivos pequeños. Sin embargo, si el sistema se bloquea poco después de la eliminación, es posible que el archivo de destino no se haya escrito en el dispositivo de almacenamiento, pero la operación de eliminación sí se haya realizado. En ese caso, ni el archivo de origen original ni el archivo de destino estarán disponibles.
Esta opción solo tiene efecto cuando xz va a eliminar el archivo de origen. En otros casos, la sincronización nunca se realiza.
La sincronización y --no-sync se agregaron en xz 5.7.1alpha.
--memlimit-compress=límite
Establezca un límite de uso de memoria para la compresión. Si esta opción se especifica varias veces, la última tiene efecto.
Si la configuración de compresión excede el límite, xz intentará ajustar la configuración a la baja para que el límite ya no se exceda y mostrará un aviso de que se realizó un ajuste automático. Los ajustes se realizan en este orden: reducir el número de hilos, cambiar al modo de un solo hilo si incluso un hilo en el modo multi-hilo excede el límite y, finalmente, reducir el tamaño del diccionario LZMA2.
Cuando se comprime con --format=raw o si se ha especificado --no-adjust, solo se puede reducir el número de hilos, ya que se puede hacer sin afectar la salida comprimida.
Si el límite no se puede cumplir incluso con los ajustes descritos anteriormente, se muestra un error y xz saldrá con un código de salida de 1.
El límite se puede especificar de varias maneras:
El límite puede ser un valor absoluto en bytes. El uso de un sufijo entero como MiB puede ser útil. Ejemplo: --memlimit-compress=80MiB
El límite se puede especificar como un porcentaje de la memoria física total (RAM). Esto puede ser útil, especialmente cuando se establece la variable de entorno XZ_DEFAULTS en un script de inicialización de shell que se comparte entre diferentes computadoras. De esta manera, el límite se ajusta automáticamente y es mayor en los sistemas con más memoria. Ejemplo: --memlimit-compress=70%
El límite se puede restablecer a su valor predeterminado estableciéndolo en 0. Actualmente, esto es equivalente a establecer el límite en máximo (sin límite de uso de memoria).
Para xz de 32 bits, existe un caso especial: si el límite supera los 4020 MiB, el límite se establece en 4020 MiB. En MIPS32 se utiliza 2000 MiB en su lugar. (Los valores 0 y máximo no se ven afectados por esto. No existe una característica similar para la descompresión). Esto puede ser útil cuando un ejecutable de 32 bits tiene acceso a un espacio de direcciones de 4 GiB (2 GiB en MIPS32) y, con suerte, no causa problemas en otras situaciones.
Consulte también la sección Uso de memoria.
--memlimit-decompress=límite
Establece un límite de uso de memoria para la descompresión. Esto también afecta al modo --list. Si la operación no es posible sin exceder el límite, xz mostrará un error y la descompresión del archivo fallará. Consulte --memlimit-compress=límite para conocer las posibles formas de especificar el límite.
--memlimit-mt-decompress=límite
Establece un límite de uso de memoria para la descompresión multi-hilo. Esto solo puede afectar al número de hilos; nunca hará que xz se niegue a descomprimir un archivo. Si el límite es demasiado bajo para permitir cualquier multi-hilo, el límite se ignora y xz continúa en modo de un solo hilo. Tenga en cuenta que si también se utiliza --memlimit-decompress, siempre se aplicará tanto al modo de un solo hilo como al modo multi-hilo, por lo que el límite efectivo para el multi-hilo nunca será mayor que el límite establecido con --memlimit-decompress.
En contraste con las otras opciones de límite de uso de memoria, --memlimit-mt-decompress=límite tiene un límite predeterminado específico del sistema. Se puede utilizar xz --info-memory para ver el valor actual.
Esta opción y su valor predeterminado existen porque, sin ningún límite, el descompresor con subprocesos podría terminar asignando una cantidad ridícula de memoria con algunos archivos de entrada. Si el límite predeterminado es demasiado bajo en su sistema, siéntase libre de aumentar el límite, pero nunca lo establezca en un valor mayor que la cantidad de RAM utilizable, ya que con los archivos de entrada apropiados, xz intentará utilizar esa cantidad de memoria incluso con un número bajo de hilos. Quedarse sin memoria o usar la memoria virtual no mejorará el rendimiento de la descompresión.
Consulte --memlimit-compress=límite para conocer las posibles formas de especificar el límite. Establecer el límite en 0 restablece el límite al valor predeterminado específico del sistema.
-M límite, --memlimit=límite, --memory=límite
Esto es equivalente a especificar --memlimit-compress=límite --memlimit-decompress=límite --memlimit-mt-decompress=límite.
--no-adjust
Muestra un error y sale si no se puede cumplir el límite de uso de memoria sin ajustar la configuración que afecta a la salida comprimida. Es decir, esto evita que xz cambie el codificador del modo multihilo al modo de un solo hilo y que reduzca el tamaño del diccionario LZMA2. Incluso cuando se utiliza esta opción, el número de hilos puede reducirse para cumplir con el límite de uso de memoria, ya que esto no afectará a la salida comprimida.
El ajuste automático siempre está desactivado al crear flujos sin formato (--format=raw).
-T threads, --threads=threads
Especifica el número de hilos de trabajo a utilizar. Establecer threads en un valor especial 0 hace que xz utilice hasta tantos hilos como los que admite el procesador o los procesadores del sistema. El número real de hilos puede ser menor que threads si el archivo de entrada no es lo suficientemente grande como para el multihilo con la configuración dada o si el uso de más hilos excedería el límite de uso de memoria.
Los compresores de un solo hilo y multihilo producen una salida diferente. El compresor de un solo hilo dará el tamaño de archivo más pequeño, pero solo la salida del compresor multihilo se puede descomprimir utilizando múltiples hilos. Establecer threads en 1 utilizará el modo de un solo hilo. Establecer threads en cualquier otro valor, incluido 0, utilizará el compresor multihilo, incluso si el sistema solo admite un hilo de hardware. (xz 2.x utilizaba el modo de un solo hilo en esta situación).
Para utilizar el modo multihilo con solo un hilo, establezca threads en +1. El prefijo + no tiene ningún efecto con otros valores. Un límite de uso de memoria aún puede hacer que xz cambie al modo de un solo hilo a menos que se utilice --no-adjust. El soporte para el prefijo + se añadió en xz 5.4.0.
Si se ha solicitado un número automático de hilos y no se ha especificado ningún límite de uso de memoria, entonces se utilizará un límite suave específico del sistema para limitar posiblemente el número de hilos. Es un límite suave en el sentido de que se ignora si el número de hilos se convierte en uno, por lo que un límite suave nunca detendrá la compresión o descompresión de xz. Este límite suave predeterminado no hará que xz cambie del modo multihilo al modo de un solo hilo. Los límites activos se pueden ver con xz --info-memory.
Actualmente, el único método de multihilo es dividir la entrada en bloques y comprimirlos de forma independiente entre sí. El tamaño de bloque predeterminado depende del nivel de compresión y se puede anular con la opción --block-size=size.
La descompresión multihilo solo funciona en archivos que contienen varios bloques con información de tamaño en los encabezados de los bloques. Todos los archivos lo suficientemente grandes comprimidos en modo multihilo cumplen esta condición, pero los archivos comprimidos en modo de un solo hilo no, incluso si se ha utilizado --block-size=size.
El valor predeterminado para threads es 0. En xz 5.4.x y versiones anteriores, el valor predeterminado es 1.
Cadenas de filtro de compresor personalizadas
Una cadena de filtro personalizada permite especificar la configuración de compresión en detalle en lugar de confiar en la configuración asociada a los preajustes. Cuando se especifica una cadena de filtro personalizada, las opciones de preajuste (-0 ... -9 y --extreme) que aparecen antes en la línea de comandos se olvidan. Si se especifica una opción de preajuste después de una o más opciones de cadena de filtro personalizada, el nuevo preajuste tiene efecto y las opciones de cadena de filtro personalizada especificadas anteriormente se olvidan.
Una cadena de filtros es comparable al uso de tuberías en la línea de comandos. Al comprimir, la
entrada sin comprimir se envía al primer filtro, cuya salida se envía al siguiente filtro (si lo hay). La salida del
último filtro se escribe en el archivo comprimido. El número máximo de filtros en la cadena es
cuatro, pero normalmente una cadena de filtros tiene solo uno o dos filtros.
Muchos filtros tienen limitaciones sobre dónde pueden estar en la cadena de filtros: algunos filtros solo pueden funcionar como el último filtro en la cadena, algunos solo como un filtro que no sea el último, y algunos funcionan en cualquier posición de la cadena. Dependiendo del filtro, esta limitación es inherente al diseño del filtro o existe para evitar problemas de seguridad.
Se puede especificar una cadena de filtros personalizada de dos maneras diferentes. Las opciones --filters=filtros y
--filters1=filtros ... --filters9=filtros permiten especificar una cadena de filtros completa en una sola opción
utilizando la sintaxis de cadena de filtros de liblzma. Alternativamente, se puede especificar una cadena de filtros utilizando
una o más opciones de filtro individuales en el orden deseado en la cadena de filtros. Es decir,
el orden de las opciones de filtro individuales es significativo. Al decodificar flujos sin formato (--format=raw), la cadena de filtros debe especificarse en el mismo orden en que se especificó al comprimir. Cualquier opción de filtro o preajuste individual especificada antes de la opción de cadena completa (--filters=filtros) se olvidará. Los filtros individuales especificados después de la opción de cadena completa
restablecerán la cadena de filtros.
Tanto la opción de cadena completa como las opciones de filtro individuales aceptan opciones específicas del filtro como una lista separada por comas. Las comas adicionales en las opciones se ignoran. Cada opción tiene un valor predeterminado, así que especifique solo las que desea cambiar.
Para ver toda la cadena de filtros y las opciones, utilice xz -vv (es decir, utilice --verbose dos veces). Esto también funciona para ver las opciones de la cadena de filtros utilizadas por los preajustes.
--filters=filtros
Especifique la cadena de filtros completa o un preajuste en una sola opción. Cada filtro se puede separar por espacios o dos guiones (--). Es posible que deba citar filtros en el shell para que se analice como una sola opción. Para denotar opciones, utilice : o =. Un preajuste puede tener como prefijo un - seguido de cero o más indicadores. El único indicador admitido es e para aplicar las mismas opciones que --extreme.
--filters1=filtros ... --filters9=filtros
Especifique hasta nueve cadenas de filtros adicionales que se pueden utilizar con --block-list.
Por ejemplo, al comprimir un archivo con archivos ejecutables seguidos de archivos de texto, la parte ejecutable podría utilizar una cadena de filtros con un filtro BCJ y la parte de texto solo el filtro LZMA2.
--filters-help
Muestra un mensaje de ayuda que describe cómo especificar los ajustes preestablecidos y las cadenas de filtros personalizadas en las opciones --filters y --filters1=filters ... --filters9=filters, y sale con éxito.
--lzma1[=options]
--lzma2[=options]
Añade un filtro LZMA1 o LZMA2 a la cadena de filtros. Estos filtros solo se pueden utilizar como el último filtro de la cadena.
LZMA1 es un filtro heredado, que se admite casi exclusivamente debido al formato de archivo .lzma heredado, que solo admite LZMA1. LZMA2 es una versión actualizada de LZMA1 para corregir algunos problemas prácticos de LZMA1. El formato .xz utiliza LZMA2 y no admite LZMA1. La velocidad y la relación de compresión de LZMA1 y LZMA2 son prácticamente las mismas.
LZMA1 y LZMA2 comparten el mismo conjunto de opciones:
preset=preset
Restablece todas las opciones de LZMA1 o LZMA2 al ajuste preestablecido. El ajuste preestablecido consiste en un número entero, al que puede seguir un modificador de ajuste preestablecido de una sola letra. El número entero puede estar entre 0 y 9, lo que coincide con las opciones de línea de comandos -0 ... -9. El único modificador admitido actualmente es e, que coincide con --extreme. Si no se especifica ningún ajuste preestablecido, los valores predeterminados de las opciones de LZMA1 o LZMA2 se toman del ajuste preestablecido 6.
dict=size
El tamaño del diccionario (búfer de historial) indica cuántos bytes de los datos descomprimidos procesados recientemente se mantienen en la memoria. El algoritmo intenta encontrar secuencias de bytes repetidas (coincidencias) en los datos descomprimidos y reemplazarlas con referencias a los datos que se encuentran actualmente en el diccionario. Cuanto mayor sea el diccionario, mayor será la probabilidad de encontrar una coincidencia. Por lo tanto, aumentar el tamaño del diccionario generalmente mejora la relación de compresión, pero un diccionario mayor que el archivo descomprimido es un desperdicio de memoria.
El tamaño típico del diccionario oscila entre 64 KiB y 64 MiB. El mínimo es 4 KiB. El máximo para la compresión es actualmente de 1,5 GiB (1536 MiB). El descompresor ya admite diccionarios de hasta un byte menos de 4 GiB, que es el máximo para los formatos de flujo LZMA1 y LZMA2.
El tamaño del diccionario y el buscador de coincidencias (mf) determinan juntos el uso de memoria del codificador LZMA1 o LZMA2. Se requiere el mismo tamaño de diccionario (o mayor) para la descompresión que se utilizó al comprimir, por lo que el uso de memoria del decodificador está determinado por el tamaño del diccionario utilizado al comprimir. Los encabezados .xz almacenan el tamaño del diccionario como 2^n o 2^n + 2^(n-1), por lo que estos tamaños son algo preferibles para la compresión. Otros tamaños se redondearán al almacenarlos en los encabezados .xz.
lc=lc Especifica el número de bits de contexto literal. El mínimo es 0 y el máximo es 4; el valor predeterminado es 3. Además, la suma de lc y lp no debe exceder los 4.
Todos los bytes que no se pueden codificar como coincidencias se codifican como literales. Es decir, los literales son simplemente bytes de 8 bits que se codifican de uno en uno.
La codificación literal hace la suposición de que los bits lc más significativos del byte descomprimido anterior se correlacionan con el siguiente byte. Por ejemplo, en el texto en inglés típico, una letra mayúscula suele ir seguida de una letra minúscula, y una letra minúscula suele ir seguida de otra letra minúscula. En el conjunto de caracteres US-ASCII, los tres bits más significativos son 010 para las letras mayúsculas y 011 para las letras minúsculas. Cuando lc es al menos 3, la codificación literal puede aprovechar esta propiedad en los datos descomprimidos.
El valor predeterminado (3) suele ser bueno. Si desea la máxima compresión, pruebe con lc=4. A veces ayuda un poco y, a veces, empeora la compresión. Si la empeora, también pruebe con lc=2.
lp=lp Especifica el número de bits de posición literal. El mínimo es 0 y el máximo es 4; el valor predeterminado es 0.
Lp afecta al tipo de alineación en los datos descomprimidos que se asume al codificar los literales. Consulte pb a continuación para obtener más información sobre la alineación.
pb=pb Especifica el número de bits de posición. El mínimo es 0 y el máximo es 4; el valor predeterminado es 2.
Pb afecta al tipo de alineación en los datos descomprimidos que se asume en general. El valor predeterminado significa una alineación de cuatro bytes (2^pb=2^2=4), que a menudo es una buena opción cuando no hay una mejor suposición.
Cuando se conoce la alineación, establecer pb en consecuencia puede reducir ligeramente el tamaño del archivo. Por ejemplo, con archivos de texto que tienen una alineación de un byte (US-ASCII, ISO-8859-*, UTF-8), establecer pb=0 puede mejorar ligeramente la compresión. Para el texto UTF-16, pb=1 es una buena opción. Si la alineación es un número impar como 3 bytes, pb=0 podría ser la mejor opción.
Aunque la alineación supuesta se puede ajustar con pb y lp, LZMA1 y LZMA2 siguen favoreciendo ligeramente una alineación de 16 bytes. Puede que valga la pena tenerlo en cuenta al diseñar formatos de archivo que probablemente se comprimirán a menudo con LZMA1 o LZMA2.
mf=mf El buscador de coincidencias tiene un gran efecto en la velocidad del codificador, el uso de la memoria y la relación de compresión. Por lo general, los buscadores de coincidencias de cadena hash son más rápidos que los buscadores de coincidencias de árbol binario. El valor predeterminado depende del preajuste: 0 utiliza hc3, 1-3 utilizan hc4 y el resto utilizan bt4.
Los siguientes buscadores de coincidencias son compatibles. Las fórmulas de uso de memoria que se indican a continuación son aproximaciones aproximadas, que se acercan más a la realidad cuando dict es una potencia de dos.
hc3 Cadena hash con hashing de 2 y 3 bytes
Valor mínimo para nice: 3
Uso de memoria:
dict * 7,5 (si dict <= 16 MiB);
dict * 5,5 + 64 MiB (si dict > 16 MiB)
hc4 Cadena hash con hashing de 2, 3 y 4 bytes
Valor mínimo para nice: 4
Uso de memoria:
dict * 7,5 (si dict <= 32 MiB);
dict * 6,5 (si dict > 32 MiB)
bt2 Árbol binario con hashing de 2 bytes
Valor mínimo para nice: 2
Uso de memoria: dict * 9,5
bt3 Árbol binario con hashing de 2 y 3 bytes
Valor mínimo para nice: 3
Uso de memoria:
dict * 11,5 (si dict <= 16 MiB);
dict * 9,5 + 64 MiB (si dict > 16 MiB)
bt4 Árbol binario con hashing de 2, 3 y 4 bytes
Valor mínimo para nice: 4
Uso de memoria:
dict * 11,5 (si dict <= 32 MiB);
dict * 10,5 (si dict > 32 MiB)
mode=mode
El modo de compresión especifica el método para analizar los datos producidos por el buscador de coincidencias. Los modos admitidos son rápido y normal. El valor predeterminado es rápido para los preajustes 0–3 y normal para los preajustes 4–9.
Por lo general, rápido se utiliza con los buscadores de coincidencias de cadena hash y normal con los buscadores de coincidencias de árbol binario. Esto es también lo que hacen los preajustes.
nice=nice
Especifique qué se considera una longitud agradable para una coincidencia. Una vez que se encuentra una coincidencia de al menos nice bytes, el algoritmo deja de buscar posibles coincidencias mejores.
Nice puede ser de 2 a 273 bytes. Los valores más altos tienden a dar una mejor relación de compresión a expensas de la velocidad. El valor predeterminado depende del preajuste.
depth=depth
Especifique la profundidad máxima de búsqueda en el buscador de coincidencias. El valor predeterminado es el valor especial de 0, que hace que el compresor determine una profundidad razonable a partir de mf y nice.
Una profundidad razonable para las cadenas hash es de 4 a 100 y de 16 a 1000 para los árboles binarios. El uso de valores muy altos para la profundidad puede hacer que el codificador sea extremadamente lento con algunos archivos. Evite establecer la profundidad por encima de 1000 a menos que esté preparado para interrumpir la compresión en caso de que tarde demasiado.
Cuando se decodifican flujos brutos (--format=raw), LZMA2 solo necesita el tamaño del diccionario. LZMA1 necesita también lc, lp y pb.
--x86[=options]
--arm[=options]
--armthumb[=options]
--arm64[=options]
--powerpc[=options]
--ia64[=options]
--sparc[=options]
--riscv[=options]
Agregue un filtro de bifurcación/llamada/salto (BCJ) a la cadena de filtros. Estos filtros solo se pueden usar como un filtro que no sea el último en la cadena de filtros.
Un filtro BCJ convierte las direcciones relativas en el código de máquina a sus contrapartes absolutas. Esto no cambia el tamaño de los datos, pero aumenta la redundancia, lo que puede
ayudar a LZMA2 a producir archivos .xz de un 0-15 % más pequeños. Los filtros BCJ siempre son reversibles, por lo que
el uso de un filtro BCJ para el tipo de datos incorrecto no causa ninguna pérdida de datos, aunque puede
hacer que la relación de compresión sea ligeramente peor. Los filtros BCJ son muy rápidos y utilizan una cantidad insignificante de memoria.
Estos filtros BCJ tienen problemas conocidos relacionados con la relación de compresión:
Algunos tipos de archivos que contienen código ejecutable (por ejemplo, archivos de objeto, bibliotecas estáticas y módulos del kernel de Linux) tienen las direcciones en las instrucciones rellenadas con valores de relleno. Estos filtros BCJ seguirán realizando la conversión de direcciones, lo que hará que la compresión sea peor con estos archivos.
Si se aplica un filtro BCJ en un archivo, es posible que esto empeore la relación de compresión en comparación con no usar un filtro BCJ. Por ejemplo, si hay archivos ejecutables similares o incluso idénticos, entonces el filtrado probablemente hará que los archivos sean menos similares y, por lo tanto, la compresión será peor. El contenido de los archivos no ejecutables en el mismo archivo también puede importar. En la práctica, uno tiene que probar con y sin un filtro BCJ para ver cuál es mejor en cada situación.
Diferentes conjuntos de instrucciones tienen diferentes alineaciones: el archivo ejecutable debe estar alineado a un múltiplo de este valor en los datos de entrada para que el filtro funcione.
Filtro Alineación Notas x86 1 32 bits o 64 bits x86 ARM 4 ARM-Thumb 2 ARM64 4 Una alineación de 4096 bytes es la mejor PowerPC 4 Solo big endian IA-64 16 Itanium SPARC 4 RISC-V 2
Dado que los datos filtrados por BCJ suelen comprimirse con LZMA2, la relación de compresión podría mejorarse ligeramente si las opciones de LZMA2 se establecen para que coincidan con la alineación del filtro BCJ seleccionado. Ejemplos:
El filtro IA-64 tiene una alineación de 16 bytes, por lo que pb=4, lp=4, lc=0 es bueno con LZMA2 (2^4=16).
El código RISC-V tiene una alineación de 2 bytes o 4 bytes, dependiendo de si el archivo contiene
instrucciones comprimidas de 16 bits (la extensión C). Cuando se utilizan instrucciones de 16 bits,
pb=2, lp=1, lc=3 o pb=1, lp=1, lc=3 son buenas opciones. Cuando no hay instrucciones de 16 bits,
pb=2, lp=2, lc=2 es la mejor opción. Se puede utilizar readelf -h para comprobar si "RVC" aparece en la
línea "Flags".
ARM64 siempre tiene una alineación de 4 bytes, por lo que pb=2, lp=2, lc=2 es la mejor opción.
El filtro x86 es una excepción. Suele ser mejor utilizar los valores predeterminados de LZMA2
(pb=2, lp=0, lc=3) al comprimir archivos ejecutables x86.
Todos los filtros BCJ admiten las mismas opciones:
start=offset
Especifica el desplazamiento de inicio que se utiliza al convertir entre direcciones relativas y absolutas. El desplazamiento debe ser un múltiplo de la alineación del filtro (consulte la tabla anterior). El valor predeterminado es cero. En la práctica, el valor predeterminado es bueno; especificar un desplazamiento personalizado casi nunca es útil.
--delta[=options]
Añade el filtro Delta a la cadena de filtros. El filtro Delta solo se puede utilizar como filtro que no sea el último en la cadena de filtros.
Actualmente, solo se admite el cálculo delta de bytes simple. Puede ser útil al comprimir, por ejemplo, imágenes de mapa de bits sin comprimir o audio PCM sin comprimir. Sin embargo, los algoritmos de propósito especial pueden dar resultados significativamente mejores que Delta + LZMA2. Esto es especialmente cierto con el audio, que se comprime más rápido y mejor, por ejemplo, con flac(1).
Opciones admitidas:
dist=distance
Especifica la distancia del cálculo delta en bytes. distance debe ser de 1 a 256. El valor predeterminado es 1.
Por ejemplo, con dist=2 y una entrada de ocho bytes A1 B1 A2 B3 A3 B5 A4 B7, la salida
será A1 B1 01 02 01 02 01 02.
Otras opciones
-q, --quiet
Suprime las advertencias y los avisos. Especifique esto dos veces para suprimir también los errores. Esta opción no tiene ningún efecto en el estado de salida. Es decir, incluso si se suprimió una advertencia, el estado de salida para indicar una advertencia sigue utilizándose.
-v, --verbose
Sea detallado. Si la salida estándar está conectada a un terminal, xz mostrará un indicador de progreso. Especificar --verbose dos veces dará una salida aún más detallada.
El indicador de progreso muestra la siguiente información:
El porcentaje de finalización se muestra si se conoce el tamaño del archivo de entrada. Es decir, el porcentaje no se puede mostrar en las canalizaciones.
Cantidad de datos comprimidos generados (durante la compresión) o consumidos (durante la descompresión).
Cantidad de datos no comprimidos consumidos (durante la compresión) o generados (durante la descompresión).
Relación de compresión, que se calcula dividiendo la cantidad de datos comprimidos procesados hasta el momento por la cantidad de datos no comprimidos procesados hasta el momento.
Velocidad de compresión o descompresión. Esto se mide como la cantidad de datos no comprimidos consumidos (compresión) o generados (descompresión) por segundo. Se muestra después de que hayan transcurrido unos segundos desde que xz comenzó a procesar el archivo.
Tiempo transcurrido en el formato M:SS o H:MM:SS.
El tiempo restante estimado se muestra solo cuando se conoce el tamaño del archivo de entrada y ya han pasado un par de segundos desde que xz comenzó a procesar el archivo. El tiempo se muestra en un formato menos preciso que nunca tiene dos puntos, por ejemplo, 2 min 30 s.
Cuando la salida estándar de error no es una terminal, --verbose hará que xz imprima el nombre del archivo, el tamaño comprimido, el tamaño no comprimido, la relación de compresión y, posiblemente, también la velocidad y el tiempo transcurrido en una sola línea a la salida estándar de error después de comprimir o descomprimir el archivo. La velocidad y el tiempo transcurrido se incluyen solo cuando la operación tardó al menos unos segundos. Si la operación no se completó, por ejemplo, debido a una interrupción del usuario, también se imprime el porcentaje de finalización si se conoce el tamaño del archivo de entrada.
-Q, --no-warn
No establezca el estado de salida en 2, incluso si se detectó una condición que merece una advertencia. Esta opción no afecta al nivel de verbosidad, por lo que tanto --quiet como --no-warn deben usarse para no mostrar las advertencias y para no alterar el estado de salida.
--robot
Imprima los mensajes en un formato que pueda ser analizado por una máquina. Esto tiene como objetivo facilitar la creación de interfaces que deseen utilizar xz en lugar de liblzma, lo que puede ser el caso de varios scripts. La salida con esta opción habilitada tiene como objetivo ser estable entre las versiones de xz. Consulte la sección MODO ROBOT para obtener más detalles.
--info-memory
Muestre, en un formato legible por humanos, cuánta memoria física (RAM) y cuántos subprocesos de procesador cree que el sistema tiene xz, y los límites de uso de memoria para la compresión y descompresión, y salga correctamente.
-h, --help
Muestre un mensaje de ayuda que describa las opciones más utilizadas y salga correctamente.
-H, --long-help
Muestre un mensaje de ayuda que describa todas las funciones de xz y salga correctamente.
-V, --version
Muestre el número de versión de xz y liblzma en un formato legible por humanos. Para obtener una salida que pueda ser analizada por una máquina, especifique --robot antes de --version.
MODO ROBOT
El modo robot se activa con la opción --robot. Esto hace que la salida de xz sea más fácil de analizar por otros programas. Actualmente, --robot solo es compatible con --list, --filters-help, --info-memory y --version. Se admitirá para la compresión y descompresión en el futuro.
Modo de lista
xz --robot --list utiliza una salida separada por tabulaciones. La primera columna de cada línea tiene una cadena que indica el tipo de información que se encuentra en esa línea:
name Esta es siempre la primera línea al comenzar a listar un archivo. La segunda columna de la línea
es el nombre del archivo.
file Esta línea contiene información general sobre el archivo .xz. Esta línea siempre se imprime
después de la línea "name".
stream Este tipo de línea se utiliza solo cuando se especificó --verbose. Hay tantas líneas "stream"
como flujos en el archivo .xz.
block Este tipo de línea se utiliza solo cuando se especificó --verbose. Hay tantas líneas "block"
como bloques en el archivo .xz. Las líneas "block" se muestran después de todas las líneas "stream"; los diferentes tipos de líneas no se intercalan.
summary
Este tipo de línea se utiliza solo cuando se especificó --verbose dos veces. Esta línea se imprime después de todas las líneas "block". Al igual que la línea "file", la línea "summary" contiene información general sobre el archivo .xz.
totals Esta línea es siempre la última línea de la salida de la lista. Muestra los recuentos y
tamaños totales.
Las columnas de las líneas "file": ### Número de flujos en el archivo ### Número total de bloques en los flujos ### Tamaño comprimido del archivo ### Tamaño descomprimido del archivo ### Relación de compresión, por ejemplo, 0.123. Si la relación es mayor que 9.999, se muestran tres guiones (---) en lugar de la relación. ### Lista separada por comas de los nombres de verificación de integridad. Se utilizan las siguientes cadenas para los tipos de verificación conocidos: None, CRC32, CRC64 y SHA-256. Para los tipos de verificación desconocidos, se utiliza Unknown-N, donde N es el ID de verificación como un número decimal (de uno o dos dígitos). ### Tamaño total del relleno de flujo en el archivo
Las columnas de las líneas "stream": ### Número de flujo (el primer flujo es 1) ### Número de bloques en el flujo ### Desplazamiento de inicio comprimido ### Desplazamiento de inicio descomprimido ### Tamaño comprimido (no incluye el relleno de flujo) ### Tamaño descomprimido ### Relación de compresión ### Nombre de la verificación de integridad Tamaño del relleno de flujo
Las columnas de las líneas "block": ### Número del flujo que contiene este bloque ### Número de bloque en relación con el inicio del flujo (el primer bloque es 1) ### Número de bloque en relación con el inicio del archivo ### Desplazamiento de inicio comprimido en relación con el inicio del archivo ### Desplazamiento de inicio descomprimido en relación con el inicio del archivo ### Tamaño comprimido total del bloque (incluye los encabezados) ### Tamaño descomprimido ### Relación de compresión Nombre de la verificación de integridad
Si se especificó --verbose dos veces, se incluyen columnas adicionales en las líneas "block". Estas no se muestran con un solo --verbose, porque obtener esta información requiere muchos accesos y puede ser lento: Valor de la verificación de integridad en formato hexadecimal Tamaño del encabezado del bloque Banderas del bloque: c indica que el tamaño comprimido está presente, y u indica que el tamaño descomprimido está presente. Si la bandera no está establecida, se muestra un guion (-) para mantener la longitud de la cadena fija. Se pueden agregar nuevas banderas al final de la cadena en el futuro. Tamaño de los datos comprimidos reales en el bloque (esto excluye el encabezado del bloque, el relleno del bloque y los campos de verificación) Cantidad de memoria (en bytes) requerida para descomprimir este bloque con esta versión de xz Cadena de filtros. Tenga en cuenta que la mayoría de las opciones utilizadas en el momento de la compresión no se pueden conocer, porque solo se almacenan en los encabezados del archivo .xz las opciones que se necesitan para la descompresión.
Las columnas de las líneas de resumen: ### Cantidad de memoria (en bytes) requerida para descomprimir este archivo con esta versión de xz sí o no, indicando si todos los encabezados de los bloques tienen tanto el tamaño comprimido como el tamaño descomprimido almacenados en ellos Desde xz 5.1.2alpha: ### Versión mínima de xz requerida para descomprimir el archivo
Las columnas de la línea de totales: ### Número de flujos ### Número de bloques ### Tamaño comprimido ### Tamaño descomprimido ### Relación de compresión promedio ### Lista separada por comas de los nombres de las verificaciones de integridad que estaban presentes en los archivos ### Tamaño del relleno del flujo ### Número de archivos. Esto se incluye para mantener el orden de las columnas anteriores igual que en las líneas de archivo.
Si se especificó --verbose dos veces, se incluyen columnas adicionales en la línea de totales: Cantidad máxima de memoria (en bytes) requerida para descomprimir los archivos con esta versión de xz sí o no, indicando si todos los encabezados de los bloques tienen tanto el tamaño comprimido como el tamaño descomprimido almacenados en ellos Desde xz 5.1.2alpha: Versión mínima de xz requerida para descomprimir el archivo
Las versiones futuras pueden agregar nuevos tipos de líneas y se pueden agregar nuevas columnas a los tipos de líneas existentes, pero las columnas existentes no se modificarán.
Ayuda de filtros
xz --robot --filters-help imprime los filtros admitidos en el siguiente formato:
filtro:opción=<valor>,opción=<valor>...
filtro Nombre del filtro
opción Nombre de una opción específica del filtro
valor Los rangos de valores numéricos aparecen como <min-max>. Las opciones de valor de cadena se muestran entre < > y se separan con el carácter |.
Cada filtro se imprime en su propia línea.
### Información sobre el límite de memoria
xz --robot --info-memory imprime una sola línea con varias columnas separadas por tabulaciones:
### Cantidad total de memoria física (RAM) en bytes.
### Límite de uso de memoria para la compresión en bytes (--memlimit-compress). Un valor especial de 0 indica la configuración predeterminada, que para el modo de un solo subproceso es el mismo que no tener límite.
### Límite de uso de memoria para la descompresión en bytes (--memlimit-decompress). Un valor especial de 0 indica la configuración predeterminada, que para el modo de un solo subproceso es el mismo que no tener límite.
### Desde xz 5.3.4alpha: Uso de memoria para la descompresión multihilo en bytes (--memlimit-mt-decompress). Esto nunca es cero porque se utiliza un valor predeterminado específico del sistema que se muestra en la columna 5 si no se ha especificado explícitamente ningún límite. Tampoco es mayor que el valor de la columna 3, incluso si se ha especificado un valor mayor con --memlimit-mt-decompress.
### Desde xz 5.3.4alpha: Un límite de uso de memoria predeterminado específico del sistema que se utiliza para
limitar la cantidad de hilos cuando se comprime con un número automático de hilos (--threads=0) y no
se ha especificado un límite de uso de memoria (--memlimit-compress). Esto también se utiliza como el valor predeterminado para --memlimit-mt-decompress.
### Desde xz 5.3.4alpha: Número de hilos de procesador disponibles.
En el futuro, la salida de xz --robot --info-memory puede tener más columnas, pero nunca más de una sola línea.
Versión
xz --robot --version imprime el número de versión de xz y liblzma en el siguiente formato:
XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS
X Versión principal.
YYY Versión secundaria. Los números pares son estables. Los números impares son versiones alfa o beta.
ZZZ Nivel de parche para las versiones estables o simplemente un contador para las versiones de desarrollo.
S Estabilidad. 0 es alfa, 1 es beta y 2 es estable. S siempre debe ser 2 cuando YYY sea
par.
XYYYZZZS son los mismos en ambas líneas si xz y liblzma provienen de la misma versión de XZ Utils.
Ejemplos: 4.999.9beta es 49990091 y 5.0.0 es 50000002.
ESTADO DE SALIDA
0 Todo está bien.
1 Ocurrió un error.
2 Ocurrió algo que merece una advertencia, pero no ocurrieron errores reales.
Los avisos (que no son advertencias ni errores) impresos en la salida estándar no afectan el estado de salida.
ENTORNO
xz analiza listas separadas por espacios de opciones de las variables de entorno XZ_DEFAULTS y XZ_OPT,
en este orden, antes de analizar las opciones de la línea de comandos. Tenga en cuenta que solo se analizan las opciones de las variables de entorno; todas las opciones que no lo son se ignoran en silencio. El análisis se realiza con getopt_long(3), que también se utiliza para los argumentos de la línea de comandos.
Advertencia: al establecer estas variables de entorno, se está modificando efectivamente los programas y scripts que ejecutan xz. En la mayoría de los casos, es seguro establecer los límites de uso de memoria, el número de hilos y las opciones de compresión a través de las variables de entorno. Sin embargo, algunas opciones pueden romper scripts. Un ejemplo obvio es --help, que hace que xz muestre el texto de ayuda en lugar de comprimir o descomprimir un archivo. Ejemplos más sutiles son --quiet y --verbose. En muchos casos, funciona bien habilitar el indicador de progreso mediante --verbose, pero en algunas situaciones, los mensajes adicionales crean problemas. El nivel de verbosidad también afecta el comportamiento de --list.
XZ_DEFAULTS
Opciones predeterminadas específicas del usuario o del sistema. Por lo general, esto se establece en un script de inicialización de shell para habilitar el limitador de uso de memoria de xz de forma predeterminada o establecer el número predeterminado de hilos. Excluyendo los scripts de inicialización de shell y casos especiales similares, los scripts nunca deben establecer o anular XZ_DEFAULTS.
XZ_OPT Esto es para pasar opciones a xz cuando no es posible establecer las opciones directamente en la línea de comandos de xz. Este es el caso cuando xz se ejecuta mediante un script o herramienta, por ejemplo, GNU [tar]({filename}../../tar)(1):
XZ_OPT=-2v tar caf foo.tar.xz foo
Los scripts pueden usar XZ_OPT, por ejemplo, para establecer opciones de compresión predeterminadas específicas del script. Sigue siendo recomendable permitir que los usuarios anulen XZ_OPT si es razonable. Por ejemplo, en los scripts [sh]({filename}../../sh)(1), se puede usar algo como esto:
XZ_OPT=${XZ_OPT-"-7e"}
export XZ_OPT
COMPATIBILIDAD CON LZMA UTILS
La sintaxis de la línea de comandos de xz es prácticamente un superconjunto de lzma, unlzma y lzcat, tal como se encuentra en LZMA Utils 4.32.x. En la mayoría de los casos, es posible reemplazar LZMA Utils con XZ Utils sin interrumpir los scripts existentes. Sin embargo, existen algunas incompatibilidades que a veces pueden causar problemas.
Niveles de preajuste de compresión
La numeración de los niveles de preajuste de compresión no es idéntica en xz y LZMA Utils. La diferencia más importante es cómo se asignan los tamaños de diccionario a diferentes preajustes. El tamaño del diccionario es aproximadamente igual al uso de memoria del descompresor.
Nivel xz LZMA Utils -0 256 KiB N/A -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
Las diferencias en el tamaño del diccionario también afectan al uso de memoria del compresor, pero existen otras diferencias entre LZMA Utils y XZ Utils, lo que hace que la diferencia sea aún mayor:
Nivel xz LZMA Utils 4.32.x -0 3 MiB N/A -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
El nivel de preajuste predeterminado en LZMA Utils es -7, mientras que en XZ Utils es -6, por lo que ambos utilizan un diccionario de 8 MiB de forma predeterminada.
Archivos .lzma con transmisión y sin transmisión
El tamaño del archivo descomprimido se puede almacenar en la cabecera .lzma. LZMA Utils hace esto cuando comprime archivos regulares. La alternativa es indicar que el tamaño descomprimido es desconocido y utilizar un marcador de fin de carga útil para indicar dónde debe detenerse el descompresor. LZMA Utils utiliza este método cuando el tamaño descomprimido es desconocido, lo que ocurre, por ejemplo, en las canalizaciones.
xz admite la descompresión de archivos .lzma con o sin un marcador de fin de carga útil, pero todos los archivos .lzma creados por xz utilizarán el marcador de fin de carga útil y tendrán el tamaño descomprimido marcado como desconocido en la cabecera .lzma. Esto puede ser un problema en algunas situaciones poco comunes. Por ejemplo, un descompresor .lzma en un dispositivo integrado podría funcionar solo con archivos que tengan un tamaño descomprimido conocido. Si te encuentras con este problema, deberás utilizar LZMA Utils o LZMA SDK para crear archivos .lzma con un tamaño descomprimido conocido.
Archivos .lzma no compatibles
El formato .lzma permite valores de lc de hasta 8 y valores de lp de hasta 4. LZMA Utils puede descomprimir archivos con cualquier valor de lc y lp, pero siempre crea archivos con lc=3 y lp=0. Crear archivos con otros valores de lc y lp es posible con xz y con el SDK de LZMA.
La implementación del filtro LZMA1 en liblzma requiere que la suma de lc y lp no supere el valor de 4. Por lo tanto, los archivos .lzma que superan este límite no se pueden descomprimir con xz.
LZMA Utils crea solo archivos .lzma que tienen un tamaño de diccionario de 2^n (una potencia de 2), pero acepta archivos con cualquier tamaño de diccionario. liblzma acepta solo archivos .lzma que tienen un tamaño de diccionario de 2^n o 2^n + 2^(n-1). Esto se hace para disminuir los falsos positivos al detectar archivos .lzma.
Estas limitaciones no deberían ser un problema en la práctica, ya que prácticamente todos los archivos .lzma se han comprimido con configuraciones que liblzma aceptará.
Datos basura al final
Al descomprimir, LZMA Utils ignora silenciosamente todo lo que haya después del primer flujo .lzma. En la mayoría de las situaciones, esto es un error. Esto también significa que LZMA Utils no admite la descompresión de archivos .lzma concatenados.
Si hay datos restantes después del primer flujo .lzma, xz considera que el archivo está dañado a menos que se haya utilizado la opción --single-stream. Esto puede romper scripts oscuros que han asumido que se ignora la basura final.
NOTAS
La salida comprimida puede variar
La salida comprimida exacta que se produce a partir del mismo archivo de entrada no comprimido puede variar entre las diferentes versiones de XZ Utils, incluso si las opciones de compresión son idénticas. Esto se debe a que el codificador se puede mejorar (más rápido o con una mejor compresión) sin afectar el formato del archivo. La salida puede variar incluso entre diferentes compilaciones de la misma versión de XZ Utils, si se utilizan diferentes opciones de compilación.
Lo anterior significa que una vez que se haya implementado la opción --rsyncable, los archivos resultantes no serán necesariamente rsyncables a menos que tanto los archivos antiguos como los nuevos se hayan comprimido con la misma versión de xz. Este problema se puede solucionar si se congela una parte de la implementación del codificador para mantener una salida rsyncable estable entre las versiones de xz.
Descompresores .xz integrados
Las implementaciones de descompresores .xz integrados, como XZ Embedded, no admiten necesariamente archivos creados con tipos de verificación de integridad distintos de none y crc32. Dado que el valor predeterminado es --check=crc64, debe utilizar --check=none o --check=crc32 al crear archivos para sistemas integrados.
Fuera de los sistemas integrados, todos los descompresores de formato .xz admiten todos los tipos de verificación, o al menos pueden descomprimir el archivo sin verificar la verificación de integridad si la verificación particular no es compatible.
XZ Embedded admite los filtros BCJ, pero solo con el desplazamiento inicial predeterminado.
EJEMPLOS
Conceptos básicos
Comprima el archivo foo en foo.xz utilizando el nivel de compresión predeterminado (-6) y elimine foo si la compresión tiene éxito:
xz foo
Descomprima bar.xz en bar y no elimine bar.xz, incluso si la descompresión tiene éxito:
xz -dk bar.xz
Cree baz.tar.xz con el ajuste preestablecido -4e (-4 --extreme), que es más lento que el predeterminado -6, pero requiere menos memoria para la compresión y descompresión (48 MiB y 5 MiB, respectivamente):
tar cf - baz | xz -4e > baz.tar.xz
Una mezcla de archivos comprimidos y descomprimidos se puede descomprimir a la salida estándar con un solo
comando:
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
Compresión paralela de muchos archivos
En GNU y BSD, find(1) y xargs(1) se pueden usar para paralelizar la compresión de muchos archivos:
find . -type f \! -name '*.xz' -print0 \
| xargs -0r -P4 -n16 xz -T1
La opción -P de xargs(1) establece el número de procesos xz paralelos. El mejor valor para la opción -n depende de cuántos archivos haya que comprimir. Si solo hay un par de archivos, el valor probablemente debería ser 1; con decenas de miles de archivos, 100 o incluso más pueden ser apropiados para reducir el número de procesos xz que xargs(1) eventualmente creará.
La opción -T1 para xz está ahí para forzarlo a un modo de un solo hilo, porque xargs(1) se usa para controlar la cantidad de paralelización.
Modo robot
Calcule cuántos bytes se han guardado en total después de comprimir varios archivos:
xz --robot --list *.xz | awk '/^totals/{print $5-$4}'
Un script puede querer saber si está usando una versión lo suficientemente nueva de xz. El siguiente script sh(1) verifica que el número de versión de la herramienta xz sea al menos 5.0.0. Este método es compatible con las versiones beta antiguas, que no admitían la opción --robot:
if ! eval "$(xz --robot --version 2> /dev/null)" ||
[ "$XZ_VERSION" -lt 50000002 ]; then
echo "Su xz es demasiado antiguo."
fi
unset XZ_VERSION LIBLZMA_VERSION
Establezca un límite de uso de memoria para la descompresión utilizando XZ_OPT, pero si ya se ha establecido un límite, no lo aumente:
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
Cadenas de filtro de compresor personalizadas
El uso más simple de las cadenas de filtro personalizadas es personalizar un ajuste preestablecido de LZMA2. Esto puede ser útil, porque los ajustes preestablecidos cubren solo un subconjunto de las combinaciones de configuración de compresión potencialmente útiles.
Las columnas CompCPU de las tablas de las descripciones de las opciones -0 ... -9 y --extreme son útiles cuando se personalizan los ajustes preestablecidos de LZMA2. Aquí están las partes relevantes recopiladas de esas dos tablas:
Preset CompCPU -0 0 -1 1 -2 2 -3 3 -4 4 -5 5 -6 6 -5e 7 -6e 8
Si sabe que un archivo requiere un diccionario algo grande (por ejemplo, 32 MiB) para comprimirse bien, pero desea comprimirlo más rápido de lo que xz -8 haría, se puede modificar un ajuste preestablecido con un valor CompCPU bajo (por ejemplo, 1) para usar un diccionario más grande:
xz --lzma2=preset=1,dict=32MiB foo.tar
Con ciertos archivos, el comando anterior puede ser más rápido que xz -6 y al mismo tiempo comprimir mejor. Sin embargo, debe enfatizarse que solo algunos archivos se benefician de un diccionario grande, manteniendo bajo el valor de CompCPU. La situación más obvia en la que un diccionario grande puede ayudar mucho es un archivo que contiene archivos muy similares de al menos unos pocos megabytes cada uno. El tamaño del diccionario debe ser significativamente mayor que cualquier archivo individual para permitir que LZMA2 aproveche al máximo las similitudes entre los archivos consecutivos.
Si se permite un uso muy alto de la memoria del compresor y el descompresor, y el archivo que se está comprimiendo tiene al menos varios cientos de megabytes, puede ser útil usar un diccionario aún más grande que los 64 MiB que usaría xz -9:
xz -vv --lzma2=dict=192MiB big_foo.tar
Usar -vv (--verbose --verbose) como en el ejemplo anterior puede ser útil para ver los requisitos de memoria del compresor y el descompresor. Recuerde que usar un diccionario más grande que el tamaño del archivo sin comprimir es un desperdicio de memoria, por lo que el comando anterior no es útil para archivos pequeños.
A veces, el tiempo de compresión no importa, pero el uso de memoria del descompresor debe mantenerse bajo, por ejemplo, para que sea posible descomprimir el archivo en un sistema integrado. El siguiente comando usa -6e (-6 --extreme) como base y establece el diccionario en solo 64 KiB. El archivo resultante se puede descomprimir con XZ Embedded (por eso hay --check=crc32) usando aproximadamente 100 KiB de memoria.
xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo
Si desea extraer la mayor cantidad de bytes posible, ajustar el número de bits de contexto literal (lc) y el número de bits de posición (pb) a veces puede ayudar. Ajustar el número de bits de posición literal (lp) también puede ayudar, pero generalmente lc y pb son más importantes. Por ejemplo, un archivo de código fuente contiene principalmente texto US-ASCII, por lo que algo como lo siguiente podría dar un archivo ligeramente (como 0.1%) más pequeño que xz -6e (también pruebe sin lc=4):
xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar
Usar otro filtro junto con LZMA2 puede mejorar la compresión con ciertos tipos de archivos. Por ejemplo, para comprimir una biblioteca compartida x86-32 o x86-64 usando el filtro x86 BCJ:
xz --x86 --lzma2 libfoo.so
Tenga en cuenta que el orden de las opciones del filtro es significativo. Si se especifica --x86 después de --lzma2, xz dará un error, porque no puede haber ningún filtro después de LZMA2, y también porque el filtro x86 BCJ no se puede usar como el último filtro en la cadena.
El filtro Delta junto con LZMA2 puede dar buenos resultados con imágenes de mapa de bits. Generalmente debería superar a PNG, que tiene algunos filtros más avanzados que el delta simple, pero utiliza Deflate para la compresión real.
La imagen debe guardarse en formato no comprimido, por ejemplo, como TIFF no comprimido. El parámetro de distancia del filtro Delta se establece para que coincida con el número de bytes por píxel en la imagen. Por ejemplo, un mapa de bits RGB de 24 bits necesita dist=3, y también es bueno pasar pb=0 a LZMA2 para adaptarse a la alineación de tres bytes:
xz --delta=dist=3 --lzma2=pb=0 foo.tiff
Si se han incluido varias imágenes en un único archivo (por ejemplo, .tar), el filtro Delta también funcionará, siempre y cuando todas las imágenes tengan el mismo número de bytes por píxel.
VÉASE TAMBIÉN
xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)
Utilidades XZ: [https://tukaani.org/xz/]
XZ Embedded: [https://tukaani.org/xz/embedded.html]
LZMA SDK: [https://7-zip.org/sdk.html]