xz, unxz, xzcat, lzma, unlzma, lzcat - Comprime ou descomprime arquivos .xz e .lzma
SINTAXE
xz [opção...] [arquivo...]
ALIASES DE COMANDO
unxz é equivalente a xz --descomprimir.
xzcat é equivalente a xz --descomprimir --saída-padrão.
lzma é equivalente a xz --formato=lzma.
unlzma é equivalente a xz --formato=lzma --descomprimir.
lzcat é equivalente a xz --formato=lzma --descomprimir --saída-padrão.
Quando estiver escrevendo scripts que precisam descompactar arquivos, é recomendável sempre usar o nome xz com argumentos apropriados (xz -d ou xz -dc) em vez dos nomes unxz e xzcat.
DESCRIÇÃO
xz é uma ferramenta de compressão de dados de propósito geral com sintaxe de linha de comando semelhante a gzip(1) e bzip2(1). O formato de arquivo nativo é o formato .xz, mas o formato .lzma legado usado pelo LZMA Utils e fluxos de dados compactados brutos sem cabeçalhos de formato de contêiner também são suportados. Além disso, a descompactação do formato .lz usado por lzip também é suportada.
xz comprime ou descompacta cada arquivo de acordo com o modo de operação selecionado. Se nenhum arquivo for fornecido ou o arquivo for -, xz lê da entrada padrão e grava os dados processados na saída padrão. xz se recusará (exibirá um erro e ignorará o arquivo) a gravar dados compactados na saída padrão se for um terminal. Da mesma forma, xz se recusará a ler dados compactados da entrada padrão se for um terminal.
A menos que --saída-padrão seja especificado, os arquivos diferentes de - são gravados em um novo arquivo cujo nome é derivado do nome do arquivo de origem:
Ao comprimir, o sufixo do formato de arquivo de destino (.xz ou .lzma) é anexado ao nome do arquivo de origem para obter o nome do arquivo de destino.
Ao descompactar, o sufixo .xz, .lzma ou .lz é removido do nome do arquivo para obter o nome do arquivo de destino. xz também reconhece os sufixos .txz e .tlz e os substitui pelo sufixo .tar.
Se o arquivo de destino já existir, um erro será exibido e o arquivo será ignorado.
A menos que esteja gravando na saída padrão, xz exibirá um aviso e ignorará o arquivo se alguma das seguintes condições se aplicar:
O arquivo não é um arquivo regular. Links simbólicos não são seguidos e, portanto, não são considerados arquivos regulares.
O arquivo tem mais de um link físico.
O arquivo tem os bits setuid, setgid ou sticky definidos.
O modo de operação está definido como comprimir e o arquivo já tem um sufixo do formato de arquivo de destino (.xz ou .txz ao comprimir para o formato .xz, e .lzma ou .tlz ao comprimir para o formato .lzma).
O modo de operação está definido como descompactar e o arquivo não tem um sufixo de nenhum dos formatos de arquivo suportados (.xz, .txz, .lzma, .tlz ou .lz).
Após comprimir ou descomprimir o arquivo com sucesso, o xz copia o proprietário, grupo, permissões, hora de acesso e hora de modificação do arquivo de origem para o arquivo de destino. Se a cópia do grupo falhar, as permissões são modificadas para que o arquivo de destino não fique acessível a usuários que não tinham permissão para acessar o arquivo de origem. O xz ainda não oferece suporte à cópia de outros metadados, como listas de controle de acesso ou atributos estendidos.
Depois que o arquivo de destino é fechado com sucesso, o arquivo de origem é removido, a menos que --keep tenha sido especificado. O arquivo de origem nunca é removido se a saída for gravada na saída padrão ou se ocorrer um erro.
Enviar SIGINFO ou SIGUSR1 para o processo xz faz com que ele imprima informações de progresso na saída de erro padrão. Isso tem apenas utilidade limitada, pois, quando a saída de erro padrão é um terminal, o uso de --verbose exibirá um indicador de progresso atualizado automaticamente.
Uso de memória
O uso de memória do xz varia de algumas centenas de kilobytes a vários gigabytes, dependendo das configurações de compressão. As configurações usadas ao comprimir um arquivo determinam os requisitos de memória do descompressor. Normalmente, o descompressor precisa de 5% a 20% da quantidade de memória que o compressor precisou ao criar o arquivo. Por exemplo, a descompressão de um arquivo criado com xz -9 requer atualmente 65 MB de memória. Ainda assim, é possível ter arquivos .xz que exigem vários gigabytes de memória para serem descompactados.
Especialmente os usuários de sistemas mais antigos podem achar a possibilidade de uso de memória muito grande incômoda. Para evitar surpresas desagradáveis, o xz tem um limitador de uso de memória integrado, que está desativado por padrão. Embora alguns sistemas operacionais forneçam maneiras de limitar o uso de memória de processos, confiar nisso não foi considerado flexível o suficiente (por exemplo, usar ulimit(1) para limitar a memória virtual tende a prejudicar mmap(2)).
O limitador de uso de memória pode ser habilitado com a opção de linha de comando --memlimit=limit. Frequentemente, é mais conveniente habilitar o limitador por padrão, definindo a variável de ambiente XZ_DEFAULTS, por exemplo, XZ_DEFAULTS=--memlimit=150MiB. É possível definir os limites separadamente para compressão e descompressão, usando --memlimit-compress=limit e --memlimit-decompress=limit. Usar essas duas opções fora de XZ_DEFAULTS raramente é útil, porque uma única execução de xz não pode fazer compressão e descompressão e --memlimit=limit (ou -M limit) é mais curto para digitar na linha de comando.
Se o limite de uso de memória especificado for excedido ao descomprimir, o xz exibirá um erro e a descompressão do arquivo falhará. Se o limite for excedido ao comprimir, o xz tentará reduzir as configurações para que o limite não seja mais excedido (exceto ao usar --format=raw ou --no-adjust). Dessa forma, a operação não falhará, a menos que o limite seja muito pequeno. A redução das configurações é feita em etapas que não correspondem às predefinições do nível de compressão, por exemplo, se o limite for apenas um pouco menor do que a quantidade necessária para xz -9, as configurações serão reduzidas apenas um pouco, não até xz -8.
Concatenção e preenchimento com arquivos .xz
É possível concatenar arquivos .xz diretamente. O xz irá descompactar esses arquivos como se fossem um único arquivo .xz.
É possível inserir preenchimento entre as partes concatenadas ou após a última parte. O preenchimento deve consistir em bytes nulos e o tamanho do preenchimento deve ser um múltiplo de quatro bytes. Isso pode ser útil, por exemplo, se o arquivo .xz for armazenado em uma mídia que mede os tamanhos dos arquivos em blocos de 512 bytes.
A concatenação e o preenchimento não são permitidos com arquivos .lzma ou fluxos brutos.
OPÇÕES
Sufixos e valores especiais para inteiros
Na maioria dos lugares onde um argumento inteiro é esperado, um sufixo opcional é suportado para indicar facilmente inteiros grandes. Não deve haver espaço entre o inteiro e o sufixo.
KiB Multiplica o inteiro por 1.024 (2^10). Ki, k, kB, K e KB são aceitos como sinônimos para KiB.
MiB Multiplica o inteiro por 1.048.576 (2^20). Mi, m, M e MB são aceitos como sinônimos para MiB.
GiB Multiplica o inteiro por 1.073.741.824 (2^30). Gi, g, G e GB são aceitos como sinônimos para GiB.
O valor especial max pode ser usado para indicar o valor inteiro máximo suportado pela opção.
Modo de operação
Se várias opções de modo de operação forem fornecidas, a última terá efeito.
-z, --compress
Comprimir. Este é o modo de operação padrão quando nenhuma opção de modo de operação é especificada e nenhum outro modo de operação é implícito pelo nome do comando (por exemplo, unxz implica --decompress).
Após a compressão bem-sucedida, o arquivo de origem é removido, a menos que a gravação seja feita na saída padrão ou --keep seja especificado.
-d, --decompress, --uncompress
Descompactar. Após a descompactação bem-sucedida, o arquivo de origem é removido, a menos que a gravação seja feita na saída padrão ou --keep seja especificado.
-t, --test
Testar a integridade dos arquivos compactados. Esta opção é equivalente a --decompress --stdout, exceto que os dados descompactados são descartados em vez de serem gravados na saída padrão. Nenhum arquivo é criado ou removido.
-l, --list
Imprimir informações sobre arquivos compactados. Nenhuma saída descompactada é produzida e nenhum arquivo é criado ou removido. No modo de listagem, o programa não pode ler os dados compactados da entrada padrão ou de outras fontes não buscáveis.
A listagem padrão mostra informações básicas sobre os arquivos, um arquivo por linha. Para obter informações mais detalhadas, use também a opção --verbose. Para obter ainda mais informações, use --verbose duas vezes, mas observe que isso pode ser lento, porque obter todas as informações extras requer muitos acessos. A largura da saída detalhada excede 80 caracteres, portanto, canalizar a saída para, por exemplo, less -S pode ser conveniente se o terminal não for largo o suficiente.
A saída exata pode variar entre as versões do xz e diferentes locais. Para saída legível por máquina, --robot --list deve ser usado.
Modificadores de operação
-k, --keep
Não exclua os arquivos de entrada.
Desde o xz 5.2.6, esta opção também faz com que o xz compacte ou descompacte mesmo que a entrada seja um link simbólico para um arquivo regular, tenha mais de um link físico ou tenha os bits setuid, setgid ou sticky definidos. Os bits setuid, setgid e sticky não são copiados para o arquivo de destino. Em versões anteriores, isso era feito apenas com --force.
-f, --force
Esta opção tem vários efeitos:
Se o arquivo de destino já existir, exclua-o antes de compactar ou descompactar.
Compacte ou descompacte mesmo que a entrada seja um link simbólico para um arquivo regular, tenha mais de um link físico ou tenha os bits setuid, setgid ou sticky definidos. Os bits setuid, setgid e sticky não são copiados para o arquivo de destino.
Quando usado com --decompress --stdout e o xz não consegue reconhecer o tipo do arquivo de origem, copie o arquivo de origem como está para a saída padrão. Isso permite que o xzcat --force seja usado como cat(1) para arquivos que não foram compactados com xz. Observe que, no futuro, o xz pode suportar novos formatos de arquivo compactados, o que pode fazer com que o xz descompacte mais tipos de arquivos em vez de copiá-los como estão para a saída padrão. --format=format pode ser usado para restringir o xz para descompactar apenas um único formato de arquivo.
-c, --stdout, --to-stdout
Escreva os dados compactados ou descompactados para a saída padrão em vez de um arquivo. Isso implica --keep.
--single-stream
Descompacte apenas o primeiro fluxo .xz e ignore silenciosamente quaisquer dados de entrada restantes que sigam o fluxo. Normalmente, esses dados extras fazem com que o xz exiba um erro.
O xz nunca descompacta mais de um fluxo de arquivos .lzma ou fluxos brutos, mas esta opção ainda faz com que o xz ignore os possíveis dados restantes após o arquivo .lzma ou fluxo bruto.
Esta opção não tem efeito se o modo de operação não for --decompress ou --test.
Desde o xz 5.7.1alpha, --single-stream implica --keep.
--no-sparse
Desabilite a criação de arquivos esparsos. Por padrão, se estiver descompactando para um arquivo regular, o xz tentará tornar o arquivo esparso se os dados descompactados contiverem longas sequências de zeros binários. Também funciona ao gravar na saída padrão, desde que a saída padrão esteja conectada a um arquivo regular e certas condições adicionais sejam atendidas para torná-lo seguro. Criar arquivos esparsos pode economizar espaço em disco e acelerar a descompactação, reduzindo a quantidade de E/S de disco.
-S .suf, --suffix=.suf
Ao compactar, use .suf como o sufixo para o arquivo de destino em vez de .xz ou .lzma. Se não estiver gravando na saída padrão e o arquivo de origem já tiver o sufixo .suf, um aviso será exibido e o arquivo será ignorado.
Ao descompactar, reconheça arquivos com o sufixo .suf, além de arquivos com os sufixos .xz, .txz, .lzma, .tlz ou .lz. Se o arquivo de origem tiver o sufixo .suf, o sufixo é removido para obter o nome do arquivo de destino.
Quando comprimir ou descomprimir fluxos brutos (--format=raw), o sufixo deve sempre ser especificado, a menos que esteja escrevendo para a saída padrão, porque não há sufixo padrão para fluxos brutos.
--files[=file]
Leia os nomes dos arquivos a serem processados do arquivo; se o arquivo for omitido, os nomes dos arquivos serão lidos da entrada padrão. Os nomes dos arquivos devem ser terminados com o caractere de nova linha. Um hífen (-) é considerado um nome de arquivo regular; não significa entrada padrão. Se os nomes dos arquivos também forem fornecidos como argumentos de linha de comando, eles serão processados antes dos nomes dos arquivos lidos do arquivo.
--files0[=file]
Isso é idêntico a --files[=file], exceto que cada nome de arquivo deve ser terminado com o caractere nulo.
Formato de arquivo básico e opções de compressão
-F format, --format=format
Especifique o formato de arquivo para comprimir ou descomprimir:
auto Este é o padrão. Ao comprimir, auto é equivalente a xz. Ao descomprimir, o formato do arquivo de entrada é detectado automaticamente. Observe que os fluxos brutos (criados com --format=raw) não podem ser detectados automaticamente.
xz Comprima para o formato de arquivo .xz ou aceite apenas arquivos .xz ao descomprimir.
lzma, sozinho
Comprima para o formato de arquivo .lzma ou aceite apenas arquivos .lzma ao descomprimir. O nome alternativo sozinho é fornecido para compatibilidade com o LZMA Utils.
lzip Aceite apenas arquivos .lz ao descomprimir. A compressão não é suportada.
Os formatos de arquivo .lz versão 0 e 1 são suportados. Os arquivos da versão 0 foram produzidos pelo lzip 1.3 e versões anteriores. Esses arquivos não são comuns, mas podem ser encontrados em arquivos, pois alguns pacotes de origem foram lançados nesse formato. As pessoas podem ter arquivos pessoais antigos nesse formato também. O suporte de descompressão para o formato da versão 0 foi removido no lzip 1.18. O lzip 1.4 e versões posteriores criam arquivos no formato da versão 1.
raw Comprima ou descompacte um fluxo bruto (sem cabeçalhos). Isso é apenas para usuários avançados. Para decodificar fluxos brutos, você precisa usar --format=raw e especificar explicitamente a cadeia de filtros, que normalmente seriam armazenados nos cabeçalhos do contêiner.
-C check, --check=check
Especifique o tipo de verificação de integridade. A verificação é calculada a partir dos dados descomprimidos e armazenada no arquivo .xz. Esta opção só tem efeito ao comprimir para o formato .xz; o formato .lzma não suporta verificações de integridade. A verificação de integridade (se houver) é verificada quando o arquivo .xz é descomprimido.
Tipos de verificação suportados:
none Não calcule nenhuma verificação de integridade. Geralmente, isso não é uma boa ideia. Isso pode ser útil quando a integridade dos dados já é verificada por outros meios.
crc32 Calcule CRC32 usando o polinômio do IEEE-802.3 (Ethernet).
crc64 Calcule CRC64 usando o polinômio do ECMA-182. Este é o padrão, pois é ligeiramente melhor do que CRC32 na detecção de arquivos corrompidos e a diferença de velocidade é insignificante.
sha256 Calcula SHA-256. Isso é um pouco mais lento que CRC32 e CRC64.
A integridade dos cabeçalhos .xz é sempre verificada com CRC32. Não é possível alterar ou desativar isso.
--ignore-check
Não verifica a integridade dos dados compactados durante a descompactação. Os valores CRC32 nos cabeçalhos .xz ainda serão verificados normalmente.
Não use esta opção a menos que saiba o que está fazendo. Razões possíveis para usar esta opção:
Tentar recuperar dados de um arquivo .xz corrompido.
Acelerar a descompactação. Isso é mais importante com SHA-256 ou com arquivos que foram compactados de forma muito eficiente. Recomenda-se não usar esta opção para este fim, a menos que a integridade do arquivo seja verificada externamente de alguma outra forma.
-0 ... -9
Seleciona um nível de predefinição de compactação. O padrão é -6. Se vários níveis de predefinição forem especificados, o último terá efeito. Se uma cadeia de filtro personalizada já foi especificada, definir um nível de predefinição de compactação limpa a cadeia de filtro personalizada.
As diferenças entre as predefinições são mais significativas do que com gzip(1) e bzip2(1). As configurações de compactação selecionadas determinam os requisitos de memória do descompactador, portanto, usar um nível de predefinição muito alto pode dificultar a descompactação do arquivo em um sistema antigo com pouca RAM. Especificamente, não é uma boa ideia usar -9 para tudo, como é frequentemente feito com gzip(1) e bzip2(1).
-0 ... -3
Estas são predefinições um tanto rápidas. -0 às vezes é mais rápido que gzip -9 enquanto compacta muito melhor. Os níveis mais altos geralmente têm velocidade comparável ao bzip2(1) com taxa de compactação comparável ou melhor, embora os resultados dependam muito do tipo de dados que estão sendo compactados.
-4 ... -6
Boa a muito boa compactação, mantendo o uso de memória do descompactador razoável, mesmo para sistemas antigos. -6 é o padrão, que geralmente é uma boa escolha para distribuir arquivos que precisam ser descompactados até mesmo em sistemas com apenas 16 MiB de RAM. (-5e ou -6e também podem valer a pena serem considerados. Veja --extreme.)
-7 ... -9
Estas são como -6, mas com requisitos de memória mais altos para o compactador e o descompactador. São úteis apenas ao compactar arquivos maiores que 8 MiB, 16 MiB e 32 MiB, respectivamente.
No mesmo hardware, a velocidade de descompactação é aproximadamente um número constante de bytes de dados compactados por segundo. Em outras palavras, quanto melhor a compactação, mais rápida será a descompactação. Isso também significa que a quantidade de saída não compactada produzida por segundo pode variar muito.
A seguinte tabela resume as características das predefinições:
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
Descrição das colunas:
DictSize é o tamanho do dicionário LZMA2. É um desperdício de memória usar um dicionário maior que o tamanho do arquivo não compactado. É por isso que é bom evitar o uso dos presets -7...-9 quando não houver necessidade real. Em -6 e níveis inferiores, a quantidade de memória desperdiçada geralmente é baixa o suficiente para não importar.
CompCPU é uma representação simplificada das configurações LZMA2 que afetam a velocidade de compressão. O tamanho do dicionário também afeta a velocidade, portanto, embora CompCPU seja o mesmo para os níveis -6...-9, níveis mais altos ainda tendem a ser um pouco mais lentos. Para obter velocidades ainda mais lentas e, assim, possivelmente, uma melhor taxa de compressão, consulte --extreme.
CompMem contém os requisitos de memória do compressor no modo de thread único. Pode variar ligeiramente entre as versões do xz.
DecMem contém os requisitos de memória do descompressor. Ou seja, as configurações de compressão determinam os requisitos de memória do descompressor. O uso exato de memória do descompressor é ligeiramente superior ao tamanho do dicionário LZMA2, mas os valores na tabela foram arredondados para o próximo MiB inteiro.
Os requisitos de memória do modo multi-thread são significativamente maiores do que os do modo de thread único. Com o valor padrão de --block-size, cada thread precisa de 3*3*DictSize mais CompMem ou DecMem. Por exemplo, quatro threads com o preset -6 precisam de 660–670 MiB de memória.
-e, --extreme
Use uma variante mais lenta do nível de preset de compressão selecionado (-0...-9) para, com sorte, obter uma taxa de compressão um pouco melhor, mas, com má sorte, isso também pode piorá-la. O uso de memória do descompressor não é afetado, mas o uso de memória do compressor aumenta um pouco nos níveis de preset -0...-3.
Como existem dois presets com tamanhos de dicionário de 4 MiB e 8 MiB, os presets -3e e -5e usam configurações ligeiramente mais rápidas (CompCPU mais baixo) do que -4e e -6e, respectivamente. Dessa forma, nenhum dos presets é idêntico.
Preset 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 exemplo, existem um total de quatro presets que usam um dicionário de 8 MiB, cuja ordem, do mais rápido para o mais lento, é -5, -6, -5e e -6e.
--fast
--best São aliases um tanto enganosos para -0 e -9, respectivamente. Eles são fornecidos apenas para compatibilidade com versões anteriores do LZMA Utils. Evite usar essas opções.
--block-size=size
Ao comprimir para o formato .xz, divida os dados de entrada em blocos de tamanho bytes. Os blocos são compactados independentemente uns dos outros, o que ajuda no multi-threading e torna possível a descompressão de acesso aleatório limitado. Essa opção é normalmente usada para substituir o tamanho de bloco padrão no modo multi-thread, mas essa opção também pode ser usada no modo de thread único.
Em modo multi-thread, aproximadamente três vezes o tamanho em bytes serão alocados em cada thread para armazenar em buffer os dados de entrada e saída. O tamanho padrão é três vezes o tamanho do dicionário LZMA2 ou 1 MiB, o que for maior. Tipicamente, um bom valor é 2 a 4 vezes o tamanho do dicionário LZMA2 ou pelo menos 1 MiB. Usar um tamanho menor que o tamanho do dicionário LZMA2 é um desperdício de RAM porque, então, o buffer do dicionário LZMA2 nunca será totalmente utilizado. Em modo multi-thread, os tamanhos dos blocos são armazenados nos cabeçalhos dos blocos. Essa informação de tamanho é necessária para a descompressão multi-thread.
Em modo single-thread, nenhum split de bloco é feito por padrão. Definir essa opção não afeta o uso de memória. Nenhuma informação de tamanho é armazenada nos cabeçalhos dos blocos, portanto, os arquivos criados em modo single-thread não serão idênticos aos arquivos criados em modo multi-thread. A falta de informação de tamanho também significa que o xz não poderá descomprimir os arquivos em modo multi-thread.
--block-list=items
Ao comprimir para o formato .xz, inicie um novo bloco com uma cadeia de filtros opcional após os intervalos dados de dados não comprimidos.
Os itens são uma lista separada por vírgulas. Cada item consiste em um número de cadeia de filtros opcional entre 0 e 9 seguido por dois pontos (:) e um tamanho obrigatório de dados não comprimidos. Omitir um item (duas ou mais vírgulas consecutivas) é uma forma abreviada de usar o tamanho e os filtros do item anterior.
Se o arquivo de entrada for maior que a soma dos tamanhos em itens, o último item será repetido até o final do arquivo. Um valor especial de 0 pode ser usado como o último tamanho para indicar que o restante do arquivo deve ser codificado como um único bloco.
Uma cadeia de filtros alternativa para cada bloco pode ser especificada em combinação com as opções --filters1=filters ... --filters9=filters. Essas opções definem cadeias de filtros com um identificador entre 1 e 9. A cadeia de filtros 0 pode ser usada para se referir à cadeia de filtros padrão, que é a mesma que não especificar uma cadeia de filtros. O identificador da cadeia de filtros pode ser usado antes do tamanho não comprimido, seguido por dois pontos (:). Por exemplo, se alguém especificar --block-list=1:2MiB,3:2MiB,2:4MiB,,2MiB,0:4MiB, os blocos serão criados usando:
A cadeia de filtros especificada por --filters1 e 2 MiB de entrada
A cadeia de filtros especificada por --filters3 e 2 MiB de entrada
A cadeia de filtros especificada por --filters2 e 4 MiB de entrada
A cadeia de filtros especificada por --filters2 e 4 MiB de entrada
A cadeia de filtros padrão e 2 MiB de entrada
A cadeia de filtros padrão e 4 MiB de entrada para cada bloco até o final da entrada.
Se alguém especificar um tamanho que exceda o tamanho do bloco do codificador (seja o valor padrão em modo thread ou o valor especificado com --block-size=size), o codificador criará blocos adicionais mantendo as fronteiras especificadas em itens. Por exemplo, se alguém especificar --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB e o arquivo de entrada for 80 MiB, serão obtidos 11 blocos: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 e 1 MiB.
No modo multi-thread, os tamanhos dos blocos são armazenados nos cabeçalhos dos blocos. Isso não é feito no modo single-thread, portanto, a saída codificada não será idêntica à do modo multi-thread.
--flush-timeout=tempo
Ao comprimir, se mais de tempo milissegundos (um inteiro positivo) se passaram desde
o último flush e a leitura de mais dados de entrada bloquearia, todos os dados de entrada
pendentes são liberados do codificador e disponibilizados no fluxo de saída. Isso pode ser
útil se o xz for usado para comprimir dados que são transmitidos por uma rede. Valores de
timeout pequenos tornam os dados disponíveis no receptor com um pequeno atraso, mas valores
de timeout grandes fornecem uma melhor taxa de compressão.
Este recurso está desabilitado por padrão. Se esta opção for especificada mais de uma vez, a última terá efeito. O valor de timeout especial de 0 pode ser usado para desabilitar explicitamente este recurso.
Este recurso não está disponível em sistemas não POSIX.
Este recurso ainda é experimental. Atualmente, o xz não é adequado para descomprimir o fluxo em tempo real devido à forma como o xz faz o buffer.
--no-sync
Não sincronize o arquivo de destino e seu diretório com o dispositivo de armazenamento antes de remover o arquivo de origem. Isso pode melhorar o desempenho se o xz for usado para comprimir ou descomprimir muitos arquivos pequenos. No entanto, se o sistema travar logo após a exclusão, é possível que o arquivo de destino não tenha sido gravado no dispositivo de armazenamento, mas a operação de exclusão tenha sido realizada. Nesse caso, nem o arquivo de origem original nem o arquivo de destino estarão disponíveis.
Esta opção tem efeito apenas quando o xz for remover o arquivo de origem. Em outros casos, a sincronização nunca é feita.
A sincronização e a opção --no-sync foram adicionadas no xz 5.7.1alpha.
--memlimit-compress=limite
Defina um limite de uso de memória para a compressão. Se esta opção for especificada várias vezes, a última terá efeito.
Se as configurações de compressão excederem o limite, o xz tentará ajustar as configurações para baixo para que o limite não seja mais excedido e exibirá um aviso de que o ajuste automático foi feito. Os ajustes são feitos nesta ordem: reduzindo o número de threads, alternando para o modo single-thread, mesmo que um único thread no modo multi-thread exceda o limite e, finalmente, reduzindo o tamanho do dicionário LZMA2.
Ao comprimir com --format=raw ou se --no-adjust foi especificado, apenas o número de threads
pode ser reduzido, pois isso pode ser feito sem afetar a saída comprimida.
Se o limite não puder ser atingido, mesmo com os ajustes descritos acima, um erro será exibido e o xz será encerrado com o código de saída 1.
O limite pode ser especificado de várias maneiras:
O limite pode ser um valor absoluto em bytes. Usar um sufixo inteiro como MiB pode ser útil. Exemplo: --memlimit-compress=80MiB
O limite pode ser especificado como uma porcentagem da memória física total (RAM). Isso pode ser útil, especialmente ao definir a variável de ambiente XZ_DEFAULTS em um script de inicialização de shell que é compartilhado entre diferentes computadores. Dessa forma, o limite é automaticamente maior em sistemas com mais memória. Exemplo: --memlimit-compress=70%
O limite pode ser redefinido para seu valor padrão definindo-o como 0. Atualmente, isso é equivalente a definir o limite como máximo (sem limite de uso de memória).
Para xz de 32 bits, existe um caso especial: se o limite exceder 4020 MiB, o limite é definido como 4020 MiB. Em MIPS32, 2000 MiB são usados em vez disso. (Os valores 0 e máximo não são afetados por isso. Um recurso semelhante não existe para descompressão.) Isso pode ser útil quando um executável de 32 bits tem acesso a um espaço de endereço de 4 GiB (2 GiB em MIPS32), ao mesmo tempo em que, esperamos, não causa problemas em outras situações.
Veja também a seção Uso de memória.
--memlimit-decompress=limite
Define um limite de uso de memória para descompressão. Isso também afeta o modo --list. Se a operação não for possível sem exceder o limite, o xz exibirá um erro e a descompressão do arquivo falhará. Veja --memlimit-compress=limite para as possíveis maneiras de especificar o limite.
--memlimit-mt-decompress=limite
Define um limite de uso de memória para descompressão multi-thread. Isso só pode afetar o número de threads; isso nunca fará com que o xz se recuse a descompactar um arquivo. Se o limite for muito baixo para permitir qualquer multi-threading, o limite será ignorado e o xz continuará no modo de thread único. Observe que, se também --memlimit-decompress for usado, ele sempre se aplicará aos modos de thread único e multi-thread, e, portanto, o limite efetivo para multi-threading nunca será maior que o limite definido com --memlimit-decompress.
Em contraste com as outras opções de limite de uso de memória, --memlimit-mt-decompress=limite tem um limite padrão específico do sistema. xz --info-memory pode ser usado para ver o valor atual.
Esta opção e seu valor padrão existem porque, sem nenhum limite, o descompactador de threads pode acabar alocando uma quantidade insana de memória com alguns arquivos de entrada. Se o limite padrão for muito baixo em seu sistema, sinta-se à vontade para aumentar o limite, mas nunca defina-o como um valor maior do que a quantidade de RAM utilizável, pois com arquivos de entrada apropriados, o xz tentará usar essa quantidade de memória, mesmo com um pequeno número de threads. Ficar sem memória ou usar o espaço de troca não melhorará o desempenho da descompressão.
Veja --memlimit-compress=limite para as possíveis maneiras de especificar o limite. Definir o limite como 0 redefine o limite para o valor padrão específico do sistema.
-M limite, --memlimit=limite, --memory=limite
Isto é equivalente a especificar --memlimit-compress=limite --memlimit-decompress=limite --memlimit-mt-decompress=limite.
--no-adjust
Exibe um erro e sai se o limite de uso de memória não puder ser atendido sem ajustar as configurações que afetam a saída compactada. Ou seja, isso impede que o xz altere o codificador do modo multithread para o modo single-thread e que reduza o tamanho do dicionário LZMA2. Mesmo quando esta opção é usada, o número de threads pode ser reduzido para atender ao limite de uso de memória, pois isso não afetará a saída compactada.
O ajuste automático é sempre desativado ao criar streams brutos (--format=raw).
-T threads, --threads=threads
Especifica o número de threads de trabalho a serem usados. Definir threads para um valor especial 0 faz com que o xz use até o número de threads suportados pelos processadores do sistema. O número real de threads pode ser menor que threads se o arquivo de entrada não for grande o suficiente para o threading com as configurações fornecidas ou se o uso de mais threads exceder o limite de uso de memória.
Os compressores single-thread e multithread produzem saídas diferentes. O compressor single-thread fornecerá o menor tamanho de arquivo, mas apenas a saída do compressor multithread pode ser descompactada usando vários threads. Definir threads para 1 usará o modo single-thread. Definir threads para qualquer outro valor, incluindo 0, usará o compressor multithread, mesmo que o sistema suporte apenas um thread de hardware. (O xz 2.x usava o modo single-thread nesta situação.)
Para usar o modo multithread com apenas um thread, defina threads para +1. O prefixo + não tem efeito com valores diferentes de 1. Um limite de uso de memória ainda pode fazer com que o xz mude para o modo single-thread, a menos que --no-adjust seja usado. O suporte para o prefixo + foi adicionado no xz 5.4.0.
Se um número automático de threads foi solicitado e nenhum limite de uso de memória foi especificado, então um limite suave específico do sistema será usado para possivelmente limitar o número de threads. É um limite suave no sentido de que é ignorado se o número de threads se tornar um, portanto, um limite suave nunca impedirá que o xz compacte ou descompacte. Este limite suave padrão não fará com que o xz mude do modo multithread para o modo single-thread. Os limites ativos podem ser vistos com xz --info-memory.
Atualmente, o único método de threading é dividir a entrada em blocos e compactá-los independentemente uns dos outros. O tamanho padrão do bloco depende do nível de compressão e pode ser substituído com a opção --block-size=size.
A descompactação multithread só funciona em arquivos que contêm vários blocos com informações de tamanho nos cabeçalhos dos blocos. Todos os arquivos grandes o suficiente compactados no modo multithread atendem a essa condição, mas os arquivos compactados no modo single-thread não, mesmo que --block-size=size tenha sido usado.
O valor padrão para threads é 0. No xz 5.4.x e versões anteriores, o padrão é 1.
Cadeias de filtro de compressor personalizadas
Uma cadeia de filtro personalizada permite especificar as configurações de compactação em detalhes, em vez de depender das configurações associadas aos predefinições. Quando uma cadeia de filtro personalizada é especificada, as opções de predefinição (-0 ... -9 e --extreme) anteriores na linha de comando são ignoradas. Se uma opção de predefinição for especificada após uma ou mais opções de cadeia de filtro personalizada, a nova predefinição entrará em vigor e as opções de cadeia de filtro personalizada especificadas anteriormente serão ignoradas.
Uma cadeia de filtros é comparável ao uso de pipes na linha de comando. Ao comprimir, a entrada não comprimida é enviada para o primeiro filtro, cuja saída é enviada para o próximo filtro (se houver). A saída do último filtro é gravada no arquivo comprimido. O número máximo de filtros na cadeia é quatro, mas normalmente uma cadeia de filtros tem apenas um ou dois filtros.
Muitos filtros têm limitações sobre onde podem estar na cadeia de filtros: alguns filtros só podem funcionar como o último filtro na cadeia, alguns apenas como um filtro que não é o último, e alguns funcionam em qualquer posição na cadeia. Dependendo do filtro, essa limitação é inerente ao design do filtro ou existe para evitar problemas de segurança.
Uma cadeia de filtros personalizada pode ser especificada de duas maneiras diferentes. As opções `--filters=filters` e `--filters1=filters ... --filters9=filters` permitem especificar uma cadeia de filtros inteira em uma única opção usando a sintaxe de string de filtro liblzma. Alternativamente, uma cadeia de filtros pode ser especificada usando uma ou mais opções de filtro individuais na ordem em que são desejadas na cadeia de filtros. Ou seja, a ordem das opções de filtro individuais é significativa! Ao decodificar fluxos brutos (`--format=raw`), a cadeia de filtros deve ser especificada na mesma ordem em que foi especificada ao comprimir. Qualquer opção de filtro ou predefinição individual especificada antes da opção de cadeia completa (`--filters=filters`) será esquecida. Filtros individuais especificados após a opção de cadeia completa irão redefinir a cadeia de filtros.
Tanto a opção de cadeia completa quanto as opções de filtro individuais aceitam opções específicas do filtro como uma lista separada por vírgulas. Vírgulas extras nas opções são ignoradas. Cada opção tem um valor padrão, portanto, especifique apenas aquelas que você deseja alterar.
Para ver a cadeia de filtros e opções completas, use xz -vv (ou seja, use --verbose duas vezes). Isso também funciona para visualizar as opções da cadeia de filtros usadas pelas predefinições.
`--filters=filters`
Especifica a cadeia de filtros completa ou uma predefinição em uma única opção. Cada filtro pode ser separado por espaços ou dois hífens (--). filters pode precisar ser colocado entre aspas na linha de comando do shell para que seja analisado como uma única opção. Para denotar opções, use : ou =. Uma predefinição pode ser prefixada com um - e seguida por zero ou mais sinalizadores. O único sinalizador suportado é e para aplicar as mesmas opções de --extreme.
`--filters1=filters ... --filters9=filters`
Especifica até nove cadeias de filtros adicionais que podem ser usadas com --block-list.
Por exemplo, ao comprimir um arquivo com arquivos executáveis seguidos por arquivos de texto, a parte executável pode usar uma cadeia de filtros com um filtro BCJ e a parte de texto apenas o filtro LZMA2.
--filters-help
Exibe uma mensagem de ajuda descrevendo como especificar predefinições e cadeias de filtros personalizadas nas opções --filters e --filters1=filters ... --filters9=filters, e sai com sucesso.
--lzma1[=opções]
--lzma2[=opções]
Adiciona um filtro LZMA1 ou LZMA2 à cadeia de filtros. Esses filtros só podem ser usados como o último filtro na cadeia.
LZMA1 é um filtro legado, que é suportado quase exclusivamente devido ao formato de arquivo .lzma legado, que suporta apenas LZMA1. LZMA2 é uma versão atualizada de LZMA1 para corrigir alguns problemas práticos do LZMA1. O formato .xz usa LZMA2 e não suporta LZMA1. A velocidade e a taxa de compressão de LZMA1 e LZMA2 são praticamente as mesmas.
LZMA1 e LZMA2 compartilham o mesmo conjunto de opções:
preset=predefinição
Redefine todas as opções de LZMA1 ou LZMA2 para a predefinição. A predefinição consiste em um inteiro, que pode ser seguido por modificadores de predefinição de uma única letra. O inteiro pode variar de 0 a 9, correspondendo às opções de linha de comando -0 ... -9. O único modificador suportado é atualmente e, que corresponde a --extreme. Se nenhuma predefinição for especificada, os valores padrão das opções LZMA1 ou LZMA2 serão obtidos da predefinição 6.
dict=tamanho
O tamanho do dicionário (buffer de histórico) indica quantos bytes dos dados não compactados processados recentemente são mantidos na memória. O algoritmo tenta encontrar sequências de bytes repetidas nos dados não compactados e substituí-las por referências aos dados atualmente no dicionário. Quanto maior o dicionário, maior a chance de encontrar uma correspondência. Portanto, aumentar o tamanho do dicionário geralmente melhora a taxa de compressão, mas um dicionário maior que o arquivo não compactado é um desperdício de memória.
O tamanho típico do dicionário varia de 64 KiB a 64 MiB. O mínimo é 4 KiB. O máximo para compressão é atualmente 1,5 GiB (1536 MiB). O descompactador já suporta dicionários com até um byte a menos de 4 GiB, que é o máximo para os formatos de fluxo LZMA1 e LZMA2.
O tamanho do dicionário e o localizador de correspondências (mf) juntos determinam o uso de memória do codificador LZMA1 ou LZMA2. O mesmo (ou maior) tamanho de dicionário é necessário para descompactar o que foi usado ao compactar, portanto, o uso de memória do decodificador é determinado pelo tamanho do dicionário usado ao compactar. Os cabeçalhos .xz armazenam o tamanho do dicionário como 2^n ou 2^n + 2^(n-1), portanto, esses tamanhos são um tanto preferidos para compressão. Outros tamanhos serão arredondados quando armazenados nos cabeçalhos .xz.
lc=lc
Especifica o número de bits de contexto literal. O mínimo é 0 e o máximo é 4; o padrão é 3. Além disso, a soma de lc e lp não deve exceder 4.
Todos os bytes que não podem ser codificados como correspondências são codificados como literais. Ou seja, os literais são simplesmente bytes de 8 bits que são codificados um de cada vez.
A codificação literal faz a suposição de que os bits lc mais significativos do byte não compactado anterior se correlacionam com o próximo byte. Por exemplo, no texto em inglês típico, uma letra maiúscula é frequentemente seguida por uma letra minúscula, e uma letra minúscula geralmente é seguida por outra letra minúscula. No conjunto de caracteres US-ASCII, os três bits mais significativos são 010 para letras maiúsculas e 011 para letras minúsculas. Quando lc é pelo menos 3, a codificação literal pode aproveitar essa propriedade nos dados não compactados.
O valor padrão (3) geralmente é bom. Se você deseja compressão máxima, teste lc=4. Às vezes, isso ajuda um pouco e, às vezes, piora a compressão. Se piorar, teste lc=2 também.
lp=lp Especifique o número de bits de posição literal. O mínimo é 0 e o máximo é 4; o padrão é 0.
Lp afeta o tipo de alinhamento nos dados descomprimidos que é assumido ao codificar literais. Consulte pb abaixo para obter mais informações sobre o alinhamento.
pb=pb Especifique o número de bits de posição. O mínimo é 0 e o máximo é 4; o padrão é 2.
Pb afeta o tipo de alinhamento nos dados descomprimidos que é assumido em geral. O padrão significa alinhamento de quatro bytes (2^pb=2^2=4), que geralmente é uma boa escolha quando não há uma estimativa melhor.
Quando o alinhamento é conhecido, definir pb de acordo pode reduzir um pouco o tamanho do arquivo. Por exemplo, com arquivos de texto que têm alinhamento de um byte (US-ASCII, ISO-8859-*, UTF-8), definir pb=0 pode melhorar ligeiramente a compressão. Para texto UTF-16, pb=1 é uma boa escolha. Se o alinhamento for um número ímpar, como 3 bytes, pb=0 pode ser a melhor escolha.
Embora o alinhamento assumido possa ser ajustado com pb e lp, LZMA1 e LZMA2 ainda favorecem ligeiramente o alinhamento de 16 bytes. Pode valer a pena levar isso em consideração ao projetar formatos de arquivo que provavelmente serão frequentemente compactados com LZMA1 ou LZMA2.
mf=mf O localizador de correspondências tem um grande efeito na velocidade do codificador, no uso de memória e na taxa de compressão. Geralmente, os localizadores de correspondências de Cadeia Hash são mais rápidos do que os localizadores de correspondências de Árvore Binária. O padrão depende da predefinição: 0 usa hc3, 1–3 usa hc4 e o restante usa bt4.
Os seguintes localizadores de correspondências são suportados. As fórmulas de uso de memória abaixo são aproximações aproximadas, que são mais próximas da realidade quando dict é uma potência de dois.
hc3 Cadeia Hash com hashing de 2 e 3 bytes
Valor mínimo para nice: 3
Uso de memória:
dict * 7,5 (se dict <= 16 MiB);
dict * 5,5 + 64 MiB (se dict > 16 MiB)
hc4 Cadeia Hash com hashing de 2, 3 e 4 bytes
Valor mínimo para nice: 4
Uso de memória:
dict * 7,5 (se dict <= 32 MiB);
dict * 6,5 (se dict > 32 MiB)
bt2 Árvore Binária com hashing de 2 bytes
Valor mínimo para nice: 2
Uso de memória: dict * 9,5
bt3 Árvore Binária com hashing de 2 e 3 bytes
Valor mínimo para nice: 3
Uso de memória:
dict * 11,5 (se dict <= 16 MiB);
dict * 9,5 + 64 MiB (se dict > 16 MiB)
bt4 Árvore Binária com hashing de 2, 3 e 4 bytes
Valor mínimo para nice: 4
Uso de memória:
dict * 11,5 (se dict <= 32 MiB);
dict * 10,5 (se dict > 32 MiB)
mode=mode
O modo de compressão especifica o método para analisar os dados produzidos pelo localizador de correspondências. Os modos suportados são rápido e normal. O padrão é rápido para os predefinidos 0–3 e normal para os predefinidos 4–9.
Normalmente, o modo rápido é usado com localizadores de correspondências de Cadeia Hash e o modo normal com localizadores de correspondências de Árvore Binária. É também o que os predefinidos fazem.
nice=nice
Especifique o que é considerado um comprimento "bom" para uma correspondência. Uma vez que uma correspondência de pelo menos nice bytes é encontrada, o algoritmo para de procurar por correspondências possivelmente melhores.
O valor de nice pode ser de 2 a 273 bytes. Valores mais altos tendem a fornecer uma melhor taxa de compressão à custa da velocidade. O padrão depende do predefinido.
depth=depth
Especifique a profundidade máxima de pesquisa no localizador de correspondências. O padrão é o valor especial de 0, que faz com que o compressor determine uma profundidade razoável a partir de mf e nice.
Uma profundidade razoável para Cadeias Hash é de 4–100 e de 16–1000 para Árvores Binárias. Usar valores muito altos para depth pode tornar o codificador extremamente lento com alguns arquivos. Evite definir a profundidade acima de 1000, a menos que você esteja preparado para interromper a compressão caso demore muito.
Ao decodificar fluxos brutos (--format=raw), LZMA2 precisa apenas do tamanho do dicionário. LZMA1 precisa também de lc, lp e pb.
--x86[=options]
--arm[=options]
--armthumb[=options]
--arm64[=options]
--powerpc[=options]
--ia64[=options]
--sparc[=options]
--riscv[=options]
Adicione um filtro de desvio/chamada/salto (BCJ) à cadeia de filtros. Esses filtros só podem ser usados como um filtro não final na cadeia de filtros.
Um filtro BCJ converte endereços relativos no código de máquina em seus equivalentes absolutos. Isso não altera o tamanho dos dados, mas aumenta a redundância, o que pode ajudar o LZMA2 a produzir arquivos .xz 0–15% menores. Os filtros BCJ são sempre reversíveis, portanto, usar um filtro BCJ para o tipo errado de dados não causa perda de dados, embora possa tornar a taxa de compressão um pouco pior. Os filtros BCJ são muito rápidos e usam uma quantidade insignificante de memória.
Esses filtros BCJ têm problemas conhecidos relacionados à taxa de compressão:
Alguns tipos de arquivos que contêm código executável (por exemplo, arquivos de objeto, bibliotecas estáticas e módulos do kernel Linux) têm os endereços nas instruções preenchidos com valores de preenchimento. Esses filtros BCJ ainda farão a conversão de endereço, o que piorará a compressão com esses arquivos.
Se um filtro BCJ for aplicado a um arquivo, é possível que ele torne a taxa de compressão pior do que não usar um filtro BCJ. Por exemplo, se houver executáveis semelhantes ou até idênticos, filtrar provavelmente tornará os arquivos menos semelhantes e, portanto, a compressão será pior. O conteúdo de arquivos não executáveis no mesmo arquivo também pode importar. Na prática, é preciso tentar com e sem um filtro BCJ para ver qual é melhor em cada situação.
Diferentes conjuntos de instruções têm alinhamentos diferentes: o arquivo executável deve ser alinhado a um múltiplo desse valor nos dados de entrada para que o filtro funcione.
Filtro Alinhamento Notas x86 1 32 bits ou 64 bits x86 ARM 4 ARM-Thumb 2 ARM64 4 O alinhamento de 4096 bytes é o ideal PowerPC 4 Apenas big endian IA-64 16 Itanium SPARC 4 RISC-V 2
Como os dados filtrados por BCJ geralmente são compactados com LZMA2, a taxa de compressão pode ser ligeiramente melhorada se as opções LZMA2 forem configuradas para corresponder ao alinhamento do filtro BCJ selecionado. Exemplos:
O filtro IA-64 tem alinhamento de 16 bytes, portanto, pb=4, lp=4, lc=0 é bom com LZMA2 (2^4=16).
O código RISC-V tem alinhamento de 2 bytes ou 4 bytes, dependendo se o arquivo contém
instruções compactadas de 16 bits (a extensão C). Quando as instruções de 16 bits são usadas,
pb=2, lp=1, lc=3 ou pb=1, lp=1, lc=3 são boas opções. Quando as instruções de 16 bits não estão presentes,
pb=2, lp=2, lc=2 é a melhor opção. O comando readelf -h pode ser usado para verificar se "RVC" aparece na
linha "Flags".
ARM64 sempre tem alinhamento de 4 bytes, portanto, pb=2, lp=2, lc=2 é a melhor opção.
O filtro x86 é uma exceção. Geralmente, é bom manter as configurações padrão do LZMA2
(pb=2, lp=0, lc=3) ao compactar executáveis x86.
Todos os filtros BCJ suportam as mesmas opções:
start=offset
Especifique o deslocamento inicial que é usado ao converter entre endereços relativos e absolutos.
O deslocamento deve ser um múltiplo do alinhamento do filtro (veja a tabela acima). O padrão é zero.
Na prática, o valor padrão é bom; especificar um deslocamento personalizado é quase nunca útil.
--delta[=options]
Adicione o filtro Delta à cadeia de filtros. O filtro Delta só pode ser usado como um filtro não final
na cadeia de filtros.
Atualmente, apenas o cálculo delta byte a byte simples é suportado. Pode ser útil ao compactar, por exemplo,
imagens bitmap não compactadas ou áudio PCM não compactado. No entanto, algoritmos de uso específico podem
fornecer resultados significativamente melhores do que Delta + LZMA2. Isso é especialmente verdadeiro com áudio,
que é compactado mais rapidamente e melhor, por exemplo, com flac(1).
Opções suportadas:
dist=distance
Especifique a distância do cálculo delta em bytes. distance deve ser de 1 a 256.
O padrão é 1.
Por exemplo, com dist=2 e entrada de oito bytes A1 B1 A2 B3 A3 B5 A4 B7, a saída será
A1 B1 01 02 01 02 01 02.
Outras opções
-q, --quiet
Suprime avisos e notificações. Especifique duas vezes para suprimir erros também. Esta opção não tem
efeito no status de saída. Ou seja, mesmo que um aviso tenha sido suprimido, o status de saída para indicar
um aviso ainda é usado.
-v, --verbose
Seja detalhado. Se a saída de erro padrão estiver conectada a um terminal, o xz exibirá um indicador de progresso.
Especificar --verbose duas vezes fornecerá ainda mais saída detalhada.
O indicador de progresso mostra as seguintes informações:
A porcentagem de conclusão é mostrada se o tamanho do arquivo de entrada for conhecido. Ou seja, a porcentagem
não pode ser mostrada em pipes.
Quantidade de dados compactados produzidos (compactando) ou consumidos (descompactando).
Quantidade de dados não compactados consumidos (compactando) ou produzidos (descompactando).
Taxa de compressão, que é calculada dividindo-se a quantidade de dados compactados processados até o momento pela quantidade de dados não compactados processados até o momento.
Velocidade de compressão ou descompressão. Isso é medido como a quantidade de dados não compactados consumidos (compressão) ou produzidos (descompressão) por segundo. É exibido após alguns segundos desde que o xz começou a processar o arquivo.
Tempo decorrido no formato M:SS ou H:MM:SS.
O tempo restante estimado é exibido somente quando o tamanho do arquivo de entrada é conhecido e alguns segundos já se passaram desde que o xz começou a processar o arquivo. O tempo é exibido em um formato menos preciso que nunca tem dois pontos, por exemplo, 2 min 30 s.
Quando a saída de erro padrão não é um terminal, --verbose fará com que o xz imprima o nome do arquivo, tamanho compactado, tamanho não compactado, taxa de compressão e, possivelmente, também a velocidade e o tempo decorrido em uma única linha na saída de erro padrão após compactar ou descompactar o arquivo. A velocidade e o tempo decorrido são incluídos apenas quando a operação levou pelo menos alguns segundos. Se a operação não foi concluída, por exemplo, devido à interrupção do usuário, também a porcentagem de conclusão é impressa se o tamanho do arquivo de entrada for conhecido.
-Q, --no-warn
Não defina o status de saída para 2, mesmo que uma condição que merece um aviso tenha sido detectada. Esta opção não afeta o nível de verbosidade, portanto, tanto --quiet quanto --no-warn devem ser usados para não exibir avisos e não alterar o status de saída.
--robot
Imprima as mensagens em um formato que possa ser analisado por máquina. Isso tem como objetivo facilitar a criação de front-ends que desejam usar o xz em vez do liblzma, o que pode ser o caso com vários scripts. A saída com esta opção habilitada deve ser estável entre as versões do xz. Consulte a seção MODO ROBÔ para obter detalhes.
--info-memory
Exiba, em formato legível por humanos, quanta memória física (RAM) e quantos threads de processador o xz acha que o sistema tem e os limites de uso de memória para compressão e descompressão e saia com sucesso.
-h, --help
Exiba uma mensagem de ajuda descrevendo as opções mais usadas e saia com sucesso.
-H, --long-help
Exiba uma mensagem de ajuda descrevendo todos os recursos do xz e saia com sucesso
-V, --version
Exiba o número da versão do xz e do liblzma em um formato legível por humanos. Para obter saída que possa ser analisada por máquina, especifique --robot antes de --version.
MODO ROBÔ
O modo robô é ativado com a opção --robot. Isso torna a saída do xz mais fácil de ser analisada por outros programas. Atualmente, --robot é suportado apenas em conjunto com --list, --filters-help, --info-memory e --version. Ele será suportado para compressão e descompressão no futuro.
Modo de lista
xz --robot --list usa saída separada por tabulações. A primeira coluna de cada linha tem uma string que indica o tipo de informação encontrada nessa linha:
name Esta é sempre a primeira linha ao iniciar a listagem de um arquivo. A segunda coluna da linha
é o nome do arquivo.
file Esta linha contém informações gerais sobre o arquivo .xz. Esta linha é sempre impressa
após a linha de nome.
stream Este tipo de linha é usado apenas quando --verbose foi especificado. Existem tantas linhas de stream
quantos streams existem no arquivo .xz.
block Este tipo de linha é usado apenas quando --verbose foi especificado duas vezes. Existem tantas linhas de bloco
quantos blocos existem no arquivo .xz. As linhas de bloco são mostradas após todas as linhas de stream; diferentes tipos de linha não são intercalados.
summary
Este tipo de linha é usado apenas quando --verbose foi especificado duas vezes. Esta linha é impressa após todas as linhas de bloco. Como a linha de arquivo, a linha de resumo contém informações gerais sobre o arquivo .xz.
totals Esta é sempre a última linha da saída da lista. Mostra as contagens e os tamanhos totais.
As colunas das linhas de arquivo: ### Número de streams no arquivo ### Número total de blocos no(s) stream(s) ### Tamanho compactado do arquivo ### Tamanho descomprimido do arquivo ### Taxa de compressão, por exemplo, 0,123. Se a taxa for superior a 9,999, três hífens (---) são exibidos em vez da taxa. ### Lista separada por vírgulas dos nomes de verificação de integridade. As seguintes strings são usadas para os tipos de verificação conhecidos: Nenhum, CRC32, CRC64 e SHA-256. Para tipos de verificação desconhecidos, Unknown-N é usado, onde N é o ID de Verificação como um número decimal (um ou dois dígitos). ### Tamanho total do preenchimento de stream no arquivo
As colunas das linhas de stream: ### Número do stream (o primeiro stream é 1) ### Número de blocos no stream ### Deslocamento de início compactado ### Deslocamento de início descomprimido ### Tamanho compactado (não inclui o preenchimento do stream) ### Tamanho descomprimido ### Taxa de compressão ### Nome da verificação de integridade Tamanho do preenchimento do stream
As colunas das linhas de bloco: ### Número do stream que contém este bloco ### Número do bloco em relação ao início do stream (o primeiro bloco é 1) ### Número do bloco em relação ao início do arquivo ### Deslocamento de início compactado em relação ao início do arquivo ### Deslocamento de início descomprimido em relação ao início do arquivo ### Tamanho compactado total do bloco (inclui cabeçalhos) ### Tamanho descomprimido ### Taxa de compressão Nome da verificação de integridade
Se --verbose foi especificado duas vezes, colunas adicionais são incluídas nas linhas de bloco. Essas não são exibidas com um único --verbose, porque obter essas informações requer muitos acessos e pode, portanto, ser lento: Valor da verificação de integridade em hexadecimal Tamanho do cabeçalho do bloco Sinalizadores do bloco: c indica que o tamanho compactado está presente e u indica que o tamanho descomprimido está presente. Se o sinalizador não estiver definido, um hífen (-) é mostrado para manter o comprimento da string fixo. Novos sinalizadores podem ser adicionados ao final da string no futuro. Tamanho dos dados compactados reais no bloco (isso exclui o cabeçalho do bloco, o preenchimento do bloco e os campos de verificação) Quantidade de memória (em bytes) necessária para descomprimir este bloco com esta versão do xz Cadeia de filtros. Observe que a maioria das opções usadas no momento da compressão não pode ser conhecida, porque apenas as opções necessárias para a descompressão são armazenadas nos cabeçalhos .xz.
As colunas das linhas de resumo: ### Quantidade de memória (em bytes) necessária para descompactar este arquivo com esta versão do xz ### sim ou não, indicando se todos os cabeçalhos de bloco têm tanto o tamanho compactado quanto o tamanho descompactado armazenados neles Desde o xz 5.1.2alpha: ### Versão mínima do xz necessária para descompactar o arquivo
As colunas da linha de totais: ### Número de fluxos ### Número de blocos ### Tamanho compactado ### Tamanho descompactado ### Taxa de compressão média ### Lista separada por vírgulas dos nomes das verificações de integridade que estavam presentes nos arquivos ### Tamanho do preenchimento do fluxo ### Número de arquivos. Isso está aqui para manter a ordem das colunas anteriores a mesma que nas linhas de arquivos.
Se --verbose foi especificado duas vezes, colunas adicionais são incluídas na linha de totais: ### Quantidade máxima de memória (em bytes) necessária para descompactar os arquivos com esta versão do xz ### sim ou não, indicando se todos os cabeçalhos de bloco têm tanto o tamanho compactado quanto o tamanho descompactado armazenados neles Desde o xz 5.1.2alpha: ### Versão mínima do xz necessária para descompactar o arquivo
Versões futuras podem adicionar novos tipos de linha e novas colunas podem ser adicionadas aos tipos de linha existentes, mas as colunas existentes não serão alteradas.
### Ajuda para filtros
### xz --robot --filters-help imprime os filtros suportados no seguinte formato:
### filter:option=<value>,option=<value>...
### filter Nome do filtro
### option Nome de uma opção específica do filtro
### value Os valores numéricos estão em intervalos <mín-máx>. As opções de valor de string são mostradas entre < > e separadas por um caractere |.
Cada filtro é impresso em sua própria linha.
### Informações sobre o limite de memória
### xz --robot --info-memory imprime uma única linha com várias colunas separadas por tabulações:
### Quantidade total de memória física (RAM) em bytes.
### Limite de uso de memória para compressão em bytes (--memlimit-compress). Um valor especial de 0 indica a configuração padrão, que, para o modo de thread único, é o mesmo que nenhum limite.
### Limite de uso de memória para descompressão em bytes (--memlimit-decompress). Um valor especial de 0 indica a configuração padrão, que, para o modo de thread único, é o mesmo que nenhum limite.
### Desde o xz 5.3.4alpha: Uso de memória para descompressão multi-thread em bytes (--memlimit-mt-decompress). Isso nunca é zero, pois um valor padrão específico do sistema mostrado na coluna 5 é usado se nenhum limite foi especificado explicitamente. Isso também nunca é maior que o valor na coluna 3, mesmo que um valor maior tenha sido especificado com --memlimit-mt-decompress.
### Desde xz 5.3.4alpha: Um limite de uso de memória padrão específico do sistema que é usado para limitar o número de threads ao comprimir com um número automático de threads (--threads=0) e nenhum limite de uso de memória especificado (--memlimit-compress). Isso também é usado como o valor padrão para --memlimit-mt-decompress.
### Desde xz 5.3.4alpha: Número de threads de processador disponíveis.
No futuro, a saída de xz --robot --info-memory pode ter mais colunas, mas nunca mais do que uma única linha.
Versão
xz --robot --version imprime o número da versão de xz e liblzma no seguinte formato:
XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS
X Versão principal.
YYY Versão secundária. Números pares são estáveis. Números ímpares são versões alfa ou beta.
ZZZ Nível de patch para versões estáveis ou apenas um contador para versões de desenvolvimento.
S Estabilidade. 0 é alfa, 1 é beta e 2 é estável. S deve ser sempre 2 quando YYY for par.
XYYYZZZS são os mesmos em ambas as linhas se xz e liblzma forem da mesma versão do XZ Utils.
Exemplos: 4.999.9beta é 49990091 e 5.0.0 é 50000002.
## STATUS DE SAÍDA
0 Tudo está bem.
1 Ocorreu um erro.
2 Algo que merece um aviso ocorreu, mas nenhum erro real ocorreu.
Avisos (não erros) impressos no erro padrão não afetam o status de saída.
AMBIENTE
xz analisa listas separadas por espaços de opções das variáveis de ambiente XZ_DEFAULTS e XZ_OPT, nesta ordem, antes de analisar as opções da linha de comando. Observe que apenas opções são analisadas das variáveis de ambiente; todos os itens que não são opções são ignorados silenciosamente. A análise é feita com getopt_long(3), que também é usado para os argumentos da linha de comando.
Aviso: Ao definir essas variáveis de ambiente, está-se efetivamente modificando programas e scripts que executam xz. Na maioria das vezes, é seguro definir limites de uso de memória, número de threads e opções de compressão por meio das variáveis de ambiente. No entanto, algumas opções podem quebrar scripts. Um exemplo óbvio é --help, que faz com que xz exiba o texto de ajuda em vez de comprimir ou descomprimir um arquivo. Exemplos mais sutis são --quiet e --verbose. Em muitos casos, funciona bem habilitar o indicador de progresso usando --verbose, mas em algumas situações as mensagens extras criam problemas. O nível de verbosidade também afeta o comportamento de --list.
XZ_DEFAULTS
Opções padrão específicas do usuário ou do sistema. Normalmente, isso é definido em um script de inicialização do shell para habilitar o limitador de uso de memória do xz por padrão ou definir o número padrão de threads. Excluindo scripts de inicialização do shell e casos especiais semelhantes, os scripts nunca devem definir ou cancelar a definição de XZ_DEFAULTS.
XZ_OPT Isso é para passar opções para xz quando não é possível definir as opções diretamente na linha de comando xz. Este é o caso quando xz é executado por um script ou ferramenta, por exemplo, GNU [tar]({filename}../../tar)(1):
XZ_OPT=-2v tar caf foo.tar.xz foo
Scripts podem usar XZ_OPT, por exemplo, para definir opções de compressão padrão específicas do script. Ainda assim, é recomendável permitir que os usuários substituam XZ_OPT, se isso for razoável. Por exemplo, em scripts sh(1), pode-se usar algo como isto:
XZ_OPT=${XZ_OPT-"-7e"}
export XZ_OPT
COMPATIBILIDADE COM LZMA UTILS
A sintaxe da linha de comando de xz é praticamente um superconjunto de lzma, unlzma e lzcat, conforme encontrado no LZMA Utils 4.32.x. Na maioria dos casos, é possível substituir o LZMA Utils por XZ Utils sem quebrar scripts existentes. No entanto, existem algumas incompatibilidades que, às vezes, podem causar problemas.
Níveis de predefinição de compressão
A numeração dos níveis de predefinição de compressão não é idêntica em xz e LZMA Utils. A diferença mais importante é como os tamanhos do dicionário são mapeados para diferentes predefinições. O tamanho do dicionário é aproximadamente igual ao uso de memória do descompressor.
Nível 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
As diferenças no tamanho do dicionário também afetam o uso de memória do compressor, mas existem algumas outras diferenças entre LZMA Utils e XZ Utils, o que torna a diferença ainda maior:
Nível 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
O nível de predefinição padrão no LZMA Utils é -7, enquanto no XZ Utils é -6, portanto, ambos usam um dicionário de 8 MiB por padrão.
Arquivos .lzma transmitidos vs. não transmitidos
O tamanho do arquivo não compactado pode ser armazenado no cabeçalho .lzma. O LZMA Utils faz isso ao compactar arquivos regulares. A alternativa é marcar que o tamanho não compactado é desconhecido e usar um marcador de fim de carga útil para indicar onde o descompressor deve parar. O LZMA Utils usa este método quando o tamanho não compactado não é conhecido, o que é o caso, por exemplo, em pipelines.
O xz oferece suporte à descompactação de arquivos .lzma com ou sem um marcador de fim de carga útil, mas todos os arquivos .lzma
criados pelo xz usarão o marcador de fim de carga útil e terão o tamanho não compactado marcado como desconhecido no
cabeçalho .lzma. Isso pode ser um problema em algumas situações incomuns. Por exemplo, um
descompactador .lzma em um dispositivo embarcado pode funcionar apenas com arquivos que têm um tamanho não compactado conhecido. Se
você encontrar esse problema, precisará usar o LZMA Utils ou o LZMA SDK para criar arquivos .lzma com um tamanho não compactado conhecido.
Arquivos .lzma não suportados
O formato .lzma permite valores de lc até 8 e valores de lp até 4. As ferramentas LZMA podem descompactar arquivos com qualquer lc e lp, mas sempre criam arquivos com lc=3 e lp=0. Criar arquivos com outros valores de lc e lp é possível com xz e com o LZMA SDK.
A implementação do filtro LZMA1 em liblzma exige que a soma de lc e lp não exceda 4. Assim, os arquivos .lzma que excedem essa limitação não podem ser descompactados com xz.
As ferramentas LZMA criam apenas arquivos .lzma que têm um tamanho de dicionário de 2^n (uma potência de 2), mas aceitam arquivos com qualquer tamanho de dicionário. liblzma aceita apenas arquivos .lzma que têm um tamanho de dicionário de 2^n ou 2^n + 2^(n-1). Isso é para diminuir os falsos positivos ao detectar arquivos .lzma.
Essas limitações não devem ser um problema na prática, pois praticamente todos os arquivos .lzma foram compactados com configurações que liblzma aceitará.
Dados extras no final do arquivo
Ao descompactar, as ferramentas LZMA ignoram silenciosamente tudo após o primeiro fluxo .lzma. Na maioria das situações, isso é um erro. Isso também significa que as ferramentas LZMA não suportam a descompactação de arquivos .lzma concatenados.
Se houver dados restantes após o primeiro fluxo .lzma, xz considera o arquivo corrompido, a menos que --single-stream seja usado. Isso pode quebrar scripts obscuros que presumiram que os dados extras no final do arquivo seriam ignorados.
NOTAS
A saída compactada pode variar
A saída compactada exata produzida a partir do mesmo arquivo de entrada não compactado pode variar entre as versões do XZ Utils, mesmo que as opções de compactação sejam idênticas. Isso ocorre porque o codificador pode ser aprimorado (mais rápido ou melhor compactação) sem afetar o formato do arquivo. A saída pode variar até mesmo entre diferentes compilações da mesma versão do XZ Utils, se opções de compilação diferentes forem usadas.
O acima significa que, uma vez que --rsyncable tenha sido implementado, os arquivos resultantes não serão necessariamente rsyncáveis, a menos que os arquivos antigo e novo tenham sido compactados com a mesma versão do xz. Esse problema pode ser resolvido se uma parte da implementação do codificador for congelada para manter a saída rsyncável estável entre as versões do xz.
Descompactadores .xz incorporados
As implementações de descompactadores .xz incorporados, como XZ Embedded, não suportam necessariamente arquivos criados com tipos de verificação de integridade diferentes de nenhum e crc32. Como o padrão é --check=crc64, você deve usar --check=none ou --check=crc32 ao criar arquivos para sistemas embarcados.
Fora dos sistemas embarcados, todos os descompactadores de formato .xz suportam todos os tipos de verificação, ou pelo menos são capazes de descompactar o arquivo sem verificar a verificação de integridade se a verificação específica não for suportada.
XZ Embedded suporta filtros BCJ, mas apenas com o deslocamento inicial padrão.
EXEMPLOS
Básico
Compacte o arquivo foo para foo.xz usando o nível de compactação padrão (-6) e remova foo se a compactação for bem-sucedida:
xz foo
Descompacte bar.xz para bar e não remova bar.xz, mesmo que a descompactação seja bem-sucedida:
xz -dk bar.xz
Crie baz.tar.xz com a predefinição -4e (-4 --extreme), que é mais lenta do que a predefinição -6, mas requer menos memória para compressão e descompressão (48 MiB e 5 MiB, respectivamente):
tar cf - baz | xz -4e > baz.tar.xz
Uma mistura de arquivos comprimidos e não comprimidos pode ser descompactada para a saída padrão com um único
comando:
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
Compressão paralela de muitos arquivos
No GNU e BSD, find(1) e xargs(1) podem ser usados para paralelizar a compressão de muitos arquivos:
find . -type f \! -name '*.xz' -print0 \
| xargs -0r -P4 -n16 xz -T1
A opção -P para xargs(1) define o número de processos xz paralelos. O melhor valor para a opção -n depende de quantos arquivos existem para serem comprimidos. Se houver apenas alguns arquivos, o valor deve ser provavelmente 1; com dezenas de milhares de arquivos, 100 ou até mais podem ser adequados para reduzir o número de processos xz que xargs(1) acabará criando.
A opção -T1 para xz está lá para forçá-lo a operar em modo de thread único, porque xargs(1) é usado para
controlar a quantidade de paralelização.
Modo robô
Calcule quantos bytes foram economizados no total após a compressão de vários arquivos:
xz --robot --list *.xz | awk '/^totals/{print $5-$4}'
Um script pode querer saber se está usando uma versão recente do xz. O seguinte script sh(1) verifica se o número da versão da ferramenta xz é pelo menos 5.0.0. Este método é compatível com versões beta antigas, que não tinham suporte para a opção --robot:
if ! eval "$(xz --robot --version 2> /dev/null)" ||
[ "$XZ_VERSION" -lt 50000002 ]; then
echo "Seu xz é muito antigo."
fi
unset XZ_VERSION LIBLZMA_VERSION
Defina um limite de uso de memória para descompressão usando XZ_OPT, mas se um limite já foi definido, não o 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
Cadeias de filtro de compressor personalizadas
O uso mais simples para cadeias de filtro personalizadas é personalizar uma predefinição LZMA2. Isso pode ser útil, porque as predefinições cobrem apenas um subconjunto das combinações de configurações de compressão potencialmente úteis.
As colunas CompCPU das tabelas das descrições das opções -0 ... -9 e --extreme
são úteis ao personalizar predefinições LZMA2. Aqui estão as partes relevantes coletadas dessas duas
tabelas:
Predefinição CompCPU -0 0 -1 1 -2 2 -3 3 -4 4 -5 5 -6 6 -5e 7 -6e 8
Se você sabe que um arquivo requer um dicionário um pouco grande (por exemplo, 32 MiB) para compactar bem, mas você deseja compactá-lo mais rapidamente do que xz -8, uma predefinição com um valor CompCPU baixo (por exemplo, 1) pode ser modificada para usar um dicionário maior:
xz --lzma2=preset=1,dict=32MiB foo.tar
Com determinados arquivos, o comando acima pode ser mais rápido que xz -6 ao mesmo tempo que comprime significativamente melhor. No entanto, deve-se enfatizar que apenas alguns arquivos se beneficiam de um dicionário grande, mantendo o valor CompCPU baixo. A situação mais óbvia, em que um dicionário grande pode ajudar muito, é um arquivo contendo arquivos muito semelhantes de pelo menos alguns megabytes cada. O tamanho do dicionário precisa ser significativamente maior do que qualquer arquivo individual para permitir que o LZMA2 aproveite ao máximo as semelhanças entre arquivos consecutivos.
Se o uso de memória muito alta do compressor e descompressor for aceitável e o arquivo a ser compactado tiver pelo menos alguns centenas de megabytes, pode ser útil usar um dicionário ainda maior do que os 64 MiB que xz -9 usaria:
xz -vv --lzma2=dict=192MiB big_foo.tar
Usar -vv (--verbose --verbose) como no exemplo acima pode ser útil para ver os requisitos de memória do compressor e descompressor. Lembre-se de que usar um dicionário maior do que o tamanho do arquivo descomprimido é um desperdício de memória, portanto, o comando acima não é útil para arquivos pequenos.
Às vezes, o tempo de compressão não importa, mas o uso de memória do descompressor precisa ser mantido baixo, por exemplo, para tornar possível descompactar o arquivo em um sistema embarcado. O seguinte comando usa -6e (-6 --extreme) como base e define o dicionário para apenas 64 KiB. O arquivo resultante pode ser descompactado com o XZ Embedded (é por isso que há --check=crc32) usando cerca de 100 KiB de memória.
xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo
Se você quiser extrair o máximo de bytes possível, ajustar o número de bits de contexto literal (lc) e o número de bits de posição (pb) às vezes pode ajudar. Ajustar o número de bits de posição literal (lp) também pode ajudar, mas geralmente lc e pb são mais importantes. Por exemplo, um arquivo de código-fonte contém principalmente texto US-ASCII, então algo como o seguinte pode fornecer um arquivo ligeiramente menor (como 0,1%) do que xz -6e (tente também sem lc=4):
xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar
Usar outro filtro em conjunto com o LZMA2 pode melhorar a compressão com certos tipos de arquivo. Por exemplo, para compactar uma biblioteca compartilhada x86-32 ou x86-64 usando o filtro x86 BCJ:
xz --x86 --lzma2 libfoo.so
Observe que a ordem das opções de filtro é significativa. Se --x86 for especificado após --lzma2, xz retornará um erro, porque não pode haver nenhum filtro após o LZMA2 e também porque o filtro x86 BCJ não pode ser usado como o último filtro na cadeia.
O filtro Delta em conjunto com o LZMA2 pode fornecer bons resultados com imagens bitmap. Ele geralmente deve superar o PNG, que tem alguns filtros mais avançados do que o delta simples, mas usa o Deflate para a compactação real.
A imagem deve ser salva em formato não compactado, por exemplo, como TIFF não compactado. O parâmetro de distância do filtro Delta é definido para corresponder ao número de bytes por pixel na imagem. Por exemplo, um bitmap RGB de 24 bits precisa de dist=3 e também é bom passar pb=0 para o LZMA2 para acomodar o alinhamento de três bytes:
xz --delta=dist=3 --lzma2=pb=0 foo.tiff
Se várias imagens foram colocadas em um único arquivo (por exemplo, .tar), o filtro Delta também funcionará, desde que todas as imagens tenham o mesmo número de bytes por pixel.
VEJA TAMBÉM
xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)
Utilitários XZ: [https://tukaani.org/xz/]
XZ Embarcado: [https://tukaani.org/xz/embedded.html]
LZMA SDK: [https://7-zip.org/sdk.html]