xz-utils (5.4.5)
Browse
Usage
VersionsXZ(1) XZ Utils XZ(1)
NOME
xz, unxz, xzcat, lzma, unlzma, lzcat - Compacta ou descompacta arquivos .xz e .lzma
SINOPSE
xz [opção...] [arquivo...]
COMANDOS APELIDOS
unxz é equivalente a xz --decompress.
xzcat é equivalente a xz --decompress --stdout.
lzma é equivalente a xz --format=lzma.
unlzma é equivalente a xz --format=lzma --decompress.
lzcat é equivalente a xz --format=lzma --decompress --stdout.
Ao escrever scripts que precisam descompactar arquivos, é recomendável sempre usar o nome xz com os argumentos
apropriados (xz -d ou xz -dc) em vez dos nomes unxz e xzcat.
DESCRIÇÃO
xz é uma ferramenta de compactação de dados de uso geral com sintaxe de linha de comando semelhante ao gzip(1) e
ao bzip2(1). O formato de arquivo nativo é o formato .xz, mas o formato legado .lzma usado por LZMA Utils e
fluxos compactados brutos sem cabeçalhos de formato de contêiner também são suportados. Além disso, a descom‐
pactação do formato .lz usado por lzip é suportada.
xz compacta ou descompacta cada arquivo de acordo com o modo de operação selecionado. Se nenhum arquivo for
fornecido ou arquivo for -, xz lê da entrada padrão e grava os dados processados na saída padrão. xz recusará
(exibirá um erro e ignorará o arquivo) para 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 --stdout seja especificado, arquivos diferentes de - são gravados em um novo arquivo cujo nome é de‐
rivado do nome arquivo de origem:
• Ao compactar, 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 des‐
tino. 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 arquivo será ignorado.
A menos que grave na saída padrão, xz exibirá um aviso e pulará o arquivo se qualquer um dos seguintes se
aplicar:
• Arquivo não é um arquivo normal. Links simbólicos não são seguidos e, portanto, não são considerados arquivos
comuns.
• Arquivo tem mais de um link físico.
• File tem setuid, setgid ou sticky bit definido.
• O modo de operação está definido para compactar e o arquivo já possui um sufixo do formato de arquivo de des‐
tino (.xz ou .txz ao compactar para o formato .xz e .lzma ou .tlz ao compactar para o formato .lzma).
• O modo de operação está definido para descompactar e o arquivo não possui um sufixo de nenhum dos formatos de
arquivo suportados (.xz, .txz, .lzma, .tlz , ou .lz).
Depois de compactar ou descompactar com êxito o arquivo, o xz copia o dono, grupo, permissões, horário de acesso
e horário de modificação do arquivo de origem para o arquivo de destino. Se a cópia do grupo falhar, as per‐
missões serão modificadas para que o arquivo de destino não se torne acessível a usuários que não têm permissão
para acessar o arquivo de origem. xz ainda não oferece suporte à cópia de outros metadados, como listas de cont‐
role de acesso ou atributos estendidos.
Depois que o arquivo de destino for fechado com êxito, o arquivo de origem será 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 ocor‐
rer um erro.
O envio de SIGINFO ou SIGUSR1 para o processo do xz faz com que ele imprima informações de andamento para erro
padrão. Isso tem uso limitado, pois quando o erro padrão é um terminal, usar --verbose exibirá um indicador de
progresso de atualização automática.
Uso de memória
O uso de memória de xz varia de algumas centenas de kilobytes a vários gigabytes, dependendo das configurações de
compactação. As configurações usadas ao compactar um arquivo determinam os requisitos de memória do descompacta‐
dor. Normalmente, o descompactador precisa de 5 % a 20 % da quantidade de memória que o compactador precisou ao
criar o arquivo. Por exemplo, descompactar um arquivo criado com xz -9 atualmente requer 65 MiB de memória. Ainda
assim, é possível ter arquivos .xz que requerem vários gigabytes de memória para descompactar.
Especialmente os usuários de sistemas mais antigos podem achar irritante a possibilidade de uso de memória muito
grande. Para evitar surpresas desconfortáveis, o xz possui um limitador de uso de memória embutido, que está
desabilitado por padrão. Embora alguns sistemas operacionais forneçam maneiras de limitar o uso de memória dos
processos, confiar nele 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 ativado com a opção de linha de comando --memlimit=limite. Geralmente é
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 compactação e descompactação us‐
ando --memlimit-compress=limite e --memlimit-decompress=limite. Usar essas duas opções fora de XZ_DEFAULTS rara‐
mente é útil porque uma única execução de xz não pode fazer compactação e descompactação e --memlimit=limite (ou
-M limite ) é mais curto para digitar na linha de comando.
Se o limite de uso de memória especificado for excedido durante a descompactação, xz exibirá um erro e a descom‐
pactação do arquivo falhará. Se o limite for excedido durante a compactaçã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 escala das configurações é feita em etapas que não corre‐
spondem às predefinições do nível de compactação, por exemplo, se o limite for apenas um pouco menor que o valor
necessário para xz -9, as configurações serão reduzidas apenas um pouco , não até xz -8.
Concatenação e preenchimento com arquivos .xz
É possível concatenar arquivos .xz como estão. xz irá descompactar tais 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 consi‐
stir 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 tamanhos de arquivo em blocos de 512 bytes.
Concatenação e preenchimento não são permitidos com arquivos .lzma ou fluxos brutos.
OPÇÕES
Sufixos inteiros e valores especiais
Na maioria dos lugares onde um argumento inteiro é esperado, um sufixo opcional é suportado para indicar facil‐
mente números inteiros grandes. Não deve haver espaço entre o número 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 de KiB.
MiB Multiplica o número inteiro por 1.048.576 (2^20). Mi, m, M e MB são aceitos como sinônimos de MiB.
GiB Multiplica o número inteiro por 1.073.741.824 (2^30). Gi, g, G e GB são aceitos como sinônimos de 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 dadas, a última entrará em vigor.
-z, --compress
Compacta. Este é o modo de operação padrão quando nenhuma opção de modo de operação é especificada e nen‐
hum outro modo de operação está implícito no nome do comando (por exemplo, unxz implica em --decompress).
-d, --decompress, --uncompress
Descompacta.
-t, --test
Testa a integridade de 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
Imprime informações sobre arquivos compactados. Nenhuma saída descompactada é produzida e nenhum arquivo é
criado ou removido. No modo de lista, o programa não pode ler os dados compactados da entrada padrão ou de
outras fontes não pesquisáveis.
A listagem padrão mostra informações básicas sobre 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 muitas buscas.
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 tiver largura o suficiente.
A saída exata pode variar entre versões xz e localidades diferentes. Para saída legível por máquina, --ro‐
bot --list deve ser usado.
Modificadores de operação
-k, --keep
Não exclui os arquivos de entrada.
Desde xz 5.2.6, esta opção também faz xz compactar ou descompactar mesmo se a entrada for um link
simbólico para um arquivo comum, tiver mais de um link físico ou tiver o setuid, setgid ou sticky bit
definir. Os bits setuid, setgid e sticky não são copiados para o arquivo de destino. Nas versões anteri‐
ores, isso era feito apenas com --force.
-f, --force
Esta opção tem vários efeitos:
• Se o arquivo de destino já existir, o exclui antes de compactar ou descompactar.
• Compacta ou descompacta, mesmo que a entrada seja um link simbólico para um arquivo normal, tenha mais
de um link físico ou tenha setuid, setgid ou sticky bit definido. Os bits setuid, setgid e sticky não
são copiados para o arquivo de destino.
• Quando usado com --decompress --stdout e xz não consegue reconhecer o tipo do arquivo de origem, copia
o arquivo de origem como está na saída padrão. Isso permite que xzcat --force seja usado como cat(1)
para arquivos que não foram compactados com xz. Observe que, no futuro, o xz pode oferecer suporte a
novos formatos de arquivo compactado, o que pode fazer com que o xz descompacte mais tipos de arquivos
em vez de copiá-los como na saída padrão. --format=formato pode ser usado para restringir xz para de‐
scompactar apenas um único formato de arquivo.
-c, --stdout, --to-stdout
Grava os dados compactados ou descompactados na saída padrão em vez de em um arquivo. Isso implica em
--keep.
--single-stream
Descompacta apenas o primeiro fluxo de .xz e ignora silenciosamente possíveis dados de entrada restantes
após o fluxo. Normalmente, esse restante posterior sem uso faz com que xz exiba um erro.
xz nunca descompacta mais de um fluxo de arquivos .lzma ou fluxos brutos, mas esta opção ainda faz xz ig‐
norar os possíveis dados posteriores 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.
--no-sparse
Desativa a criação de arquivos esparsos. Por padrão, ao descompactar em um arquivo normal, xz tenta tornar
o arquivo esparso se os dados descompactados contiverem longas sequências de zeros binários. Ele também
funciona ao gravar na saída padrão, desde que a saída padrão esteja conectada a um arquivo normal e certas
condições adicionais sejam atendidas para torná-la segura. A criação de arquivos esparsos pode economizar
espaço em disco e acelerar a descompactação, reduzindo a quantidade de E/S do disco.
-S .suf, --suffix=.suf
Ao compactar, usa .suf como sufixo para o arquivo de destino em vez de .xz ou .lzma. Se não estiver gra‐
vando 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, reconhece arquivos com o sufixo .suf além de arquivos com o sufixo .xz, .txz, .lzma, .tlz
ou .lz . Se o arquivo de origem tiver o sufixo .suf, o sufixo será removido para obter o nome do arquivo
de destino.
Ao compactar ou descompactar fluxos brutos (--format=raw), o sufixo sempre deve ser especificado, a menos
que seja gravado na saída padrão, porque não há sufixo padrão para fluxos brutos.
--files[=arquivo]
Lê os nomes dos arquivos a serem processados em arquivo; se arquivo for omitido, os nomes dos arquivos
serão lidos da entrada padrão. Os nomes de arquivo devem terminar com o caractere de nova linha. Um traço
(-) é considerado um nome de arquivo regular; não significa entrada padrão. Se os nomes de arquivo forem
fornecidos também como argumentos de linha de comando, eles serão processados antes da leitura dos nomes
de arquivo de arquivo.
--files0[=arquivo]
Isso é idêntico a --files[=arquivo], exceto que cada nome de arquivo deve ser finalizado com o caractere
nulo.
Opções básicas de formato de arquivo e de compactação
-F formato, --format=formato
Especifica o formato de arquivo para compactar ou descompactar:
auto Este é o padrão. Ao compactar, auto é equivalente a xz. Ao descompactar, o formato do arquivo de
entrada é detectado automaticamente. Observe que os fluxos brutos (criados com --format=raw) não
podem ser detectados automaticamente.
xz Compacta no formato de arquivo .xz ou aceite apenas arquivos .xz ao descompactar.
lzma, alone
Compacta no formato de arquivo legado .lzma ou aceite apenas arquivos .lzma ao descompactar. O nome
alternativo alone é fornecido para compatibilidade com versões anteriores do LZMA Utils.
lzip Aceita apenas arquivos .lz ao descompactar. Sem suporte a compactação.
O formato .lz versão 0 e a versão não estendida 1 são suportados. Os arquivos da versão 0 foram
produzidos por lzip 1.3 e anteriores. Esses arquivos não são comuns, mas podem ser encontrados em
arquivos compactados, pois alguns pacotes de origem foram lançados nesse formato. As pessoas também
podem ter arquivos pessoais antigos neste formato. O suporte de descompactação para o formato
versão 0 foi removido em lzip 1.18.
lzip 1.4 e posteriores criam arquivos no formato versão 1. A extensão do marcador de descarga de
sincronização para o formato versão 1 foi adicionada em lzip 1.6. Esta extensão raramente é usada e
não é suportada por xz (diagnosticada como entrada corrompida).
raw Compacta ou descompacta um fluxo bruto (sem cabeçalhos). Isso é destinado apenas a usuários
avançados. Para decodificar fluxos brutos, você precisa usar --format=raw e especificar explicita‐
mente a cadeia de filtros, que normalmente seria armazenada nos cabeçalhos do contêiner.
-C verificação, --check=verificação
Especifica o tipo de verificação de integridade. A verificação é calculada a partir dos dados descompacta‐
dos e armazenados no arquivo .xz. Esta opção tem efeito somente ao compactar no formato .xz; o formato
.lzma não oferece suporte a verificações de integridade. A verificação de integridade (se for o caso) é
verificada quando o arquivo .xz é descompactado.
Tipos de verificação suportados:
none Não calcula uma verificação de integridade. Isso geralmente é uma má ideia. Pode ser útil quando a
integridade dos dados é verificada por outros meios.
crc32 Calcula CRC32 usando o polinômio do IEEE-802.3 (Ethernet).
crc64 Calcula CRC64 usando o polinômio de ECMA-182. Este é o padrão, pois é um pouco melhor que o CRC32
na detecção de arquivos danificados e a diferença de velocidade é insignificante.
sha256 Calcula SHA-256. Isso é um pouco mais lento do que CRC32 e CRC64.
A integridade dos cabeçalhos de .xz é sempre verificada com CRC32. Não é possível alterá-la ou de‐
sativá-la.
--ignore-check
Não confere a verificação de integridade dos dados compactados ao descompactar. Os valores CRC32 nos
cabeçalhos .xz ainda serão conferidos normalmente.
Não use esta opção a menos que saiba o que está fazendo. Possíveis razões para usar esta opção:
• Tentativa de recuperar dados de um arquivo .xz corrompido.
• Acelerar a descompactação. Isso é importante principalmente com SHA-256 ou com arquivos extremamente
bem compactados. É recomendável não usar essa opção para essa finalidade, 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, especi‐
ficar 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 con‐
figuraçõ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 cegamente -9 para tudo como costuma acontecer com
gzip(1) e bzip2(1).
-0 ... -3
Estas são predefinições um tanto rápidas. -0 às vezes é mais rápida que gzip -9 ao mesmo tempo que
compacta muito melhor. As mais altas 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
Compactação boa a muito boa, mantendo o uso de memória do descompactador razoável mesmo para sis‐
temas antigos. -6 é o padrão, que geralmente é uma boa escolha para distribuir arquivos que pre‐
cisam ser descompactáveis, mesmo em sistemas com apenas 16 MiB de RAM. (-5e ou -6e também vale a
pena considerar. Veja --extreme.)
-7 ... -9
Eles são como -6, mas com requisitos de memória de compressor e descompressor mais altos. Eles 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 descom‐
pactação. Isso também significa que a quantidade de saída não compactada produzida por segundo pode variar
muito.
A tabela a seguir resume os recursos das predefinições:
Predefinição DicTam 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ções das colunas:
• DicTam é o tamanho do dicionário LZMA2. É desperdício de memória usar um dicionário maior que o tamanho
do arquivo descompactado. É por isso que é bom evitar usar as predefinições -7 ... -9 quando não há
real necessidade deles. Em -6 e inferior, a quantidade de memória desperdiçada geralmente é baixa o su‐
ficiente para não importar.
• CompCPU é uma representação simplificada das configurações LZMA2 que afetam a velocidade de com‐
pactação. O tamanho do dicionário também afeta a velocidade, portanto, embora o CompCPU seja o mesmo
para os níveis -6 ... -9, níveis mais altos ainda tendem a ser um pouco mais lentos. Para obter uma
compactação ainda mais lenta e possivelmente melhor, consulte --extreme.
• CompMem contém os requisitos de memória do compactador no modo de thread única.Pode variar ligeiramente
entre as versões xz. Os requisitos de memória de alguns dos futuros modos de várias threads (multi‐
thread) podem ser dramaticamente maiores do que os do modo de thread única.
• DecMem contém os requisitos de memória do descompactador. Ou seja, as configurações de compactação de‐
terminam os requisitos de memória do descompactador. O uso exato da memória do descompactador é um
pouco maior do que o tamanho do dicionário LZMA2, mas os valores na tabela foram arredondados para o
próximo MiB completo.
-e, --extreme
Usa uma variante mais lenta do nível de predefinição de compactação selecionado (-0 ... -9) para obter uma
taxa de compactação um pouco melhor, mas, com azar, isso também pode piorar. O uso da memória do descom‐
pressor não é afetado, mas o uso da memória do compactador aumenta um pouco nos níveis de predefinição -0
... -3.
Como existem duas predefinições com tamanhos de dicionário 4 MiB e 8 MiB, as predefinições -3e e -5e usam
configurações um pouco mais rápidas (CompCPU inferior) do que -4e e -6e, respectivamente. Dessa forma, não
há duas predefinições idênticas.
Predefinição DicTam 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, há um total de quatro predefinições que usam o dicionário 8 MiB, cuja ordem do mais rápido ao
mais lento é -5, -6, -5e e -6e.
--fast
--best Esses são apelidos um tanto enganosos para -0 e -9, respectivamente. Eles são fornecidos apenas para com‐
patibilidade com versões anteriores do LZMA Utils. Evite usar essas opções.
--block-size=tamanho
Ao compactar para o formato .xz, divida os dados de entrada em blocos de tamanho bytes. Os blocos são com‐
pactados independentemente uns dos outros, o que ajuda no multi-threading e torna possível a descom‐
pactação limitada de acesso aleatório. Essa opção normalmente é usada para substituir o tamanho de bloco
padrão no modo multi-thread, mas também pode ser usada em thread única.
No modo multi-thread, cerca de três vezes tamanho bytes serão alocados em cada thread para armazenar em
buffer a entrada e a saída. O tamanho padrão é três vezes o tamanho do dicionário LZMA2 ou 1 MiB, o que
for maior. Normalmente, um bom valor é 2–4 vezes o tamanho do dicionário LZMA2 ou pelo menos 1 MiB. Usar
tamanho menor que o tamanho do dicionário LZMA2 é um desperdício de RAM porque o buffer do dicionário
LZMA2 nunca será totalmente usado. Os tamanhos dos blocos são armazenados nos cabeçalhos dos blocos, que
uma versão futura do xz usará para descompactação em multi-thread.
No modo de thread única, nenhuma divisão de bloco é feita por padrão. Definir essa opção não afeta o uso
da memória. Nenhuma informação de tamanho é armazenada nos cabeçalhos dos blocos, portanto, os arquivos
criados no modo de thread única não serão idênticos aos arquivos criados no modo multi-thread. A falta de
informações de tamanho também significa que uma versão futura do xz não poderá descompactar os arquivos no
modo multi-thread.
--block-list=tamanhos
Ao compactar para o formato .xz, inicia um novo bloco após os intervalos fornecidos de dados não compacta‐
dos.
Os tamanhos não compactados dos blocos são especificados como uma lista separada por vírgulas. Omitir um
tamanho (duas ou mais vírgulas consecutivas) é uma forma abreviada de usar o tamanho do bloco anterior.
Se o arquivo de entrada for maior que a soma de tamanhos, o último valor em tamanhos é repetido até o fi‐
nal do arquivo. Um valor especial de 0 pode ser usado como o último valor para indicar que o restante do
arquivo deve ser codificado como um único bloco.
Se alguém especificar tamanhos que excedam o tamanho do bloco do codificador (seja o valor padrão no modo
em threads ou o valor especificado com --block-size=tamanho), o codificador criará blocos adicionais en‐
quanto mantém o limites especificados em tamanhos. Por exemplo, se alguém especificar --block-size=10MiB
--block-list=5MiB,10MiB,8MiB,12MiB,24MiB e o arquivo de entrada for 80 MiB, obterá 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 de thread única, portanto, a saída codificada não será idêntica à do modo multi-thread.
--flush-timeout=tempo_limite
Ao compactar, se mais de tempo_limite milissegundos (um número inteiro positivo) se passaram desde a lib‐
eração anterior e a leitura de mais entrada seria bloqueada, todos os dados de entrada pendentes serão
liberados do codificador e disponibilizados no fluxo de saída. Isso pode ser útil se xz for usado para
compactar dados transmitidos por uma rede. Valores tempo_limite pequenos tornam os dados disponíveis na
extremidade receptora com um pequeno atraso, mas valores tempo_limite grandes oferecem melhor taxa de com‐
pactação.
Esse recurso está desabilitado por padrão. Se esta opção for especificada mais de uma vez, a última terá
efeito. O valor especial tempo_limite de 0 pode ser usado para desabilitar explicitamente esse recurso.
Este recurso não está disponível em sistemas não-POSIX.
Este recurso ainda é experimental. Atualmente, xz não é adequado para descompactar o fluxo em tempo real
devido à forma como xz faz o buffer.
--memlimit-compress=limite
Define um limite de uso de memória para compactação. Se esta opção for especificada várias vezes, a última
entrará em vigor.
Se as configurações de compactação excederem o limite, 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 encadeamentos, alternando para o modo sigle-thread se até
mesmo uma thread no modo multi-thread exceder o limite e, finalmente, reduzindo o tamanho do dicionário
LZMA2.
Ao compactar com --format=raw ou se --no-adjust tiver sido especificado, apenas o número de threads pode
ser reduzido, pois isso pode ser feito sem afetar a saída compactada.
Se o limite não puder ser alcançado mesmo com os ajustes descritos acima, um erro será exibido e xz sairá
com status 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 equivale a
definir limite como max (sem limite de uso de memória).
Para xz de 32 bits, há um caso especial: se o limite estiver acima de 4020 MiB, o limite é definido como
4020 MiB. No MIPS32 2000 MiB é usado em seu lugar. (Os valores 0 e max não são afetados por isso. Um re‐
curso semelhante não existe para descompactação.) Isso pode ser útil quando um executável de 32 bits tem
acesso a espaço de endereço de 4 GiB (2 GiB no MIPS32) enquanto espero não causar danos em outras
situações.
Consulte também a seção Uso de memória.
--memlimit-decompress=limite
Define um limite de uso de memória para descompactação. Isso também afeta o modo --list. Se a operação não
for possível sem exceder o limite, xz exibirá um erro e a descompactação do arquivo falhará. Consulte
--memlimit-compress=limite para possíveis maneiras de especificar o limite.
--memlimit-mt-decompress=limite
Define um limite de uso de memória para descompactação multi-thread. Isso pode afetar apenas o número de
threads; isso nunca fará com que xz se recuse a descompactar um arquivo. Se limite for muito baixo para
permitir qualquer multi-thread, o limite será ignorado e xz continuará no modo de thread única. Observe
que se --memlimit-decompress também for usado, ele sempre se aplicará aos modos de thread única 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
padrão limite 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 qualquer limite, o descompactador usando 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 para um valor
maior que a quantidade de RAM utilizável, pois com os arquivos de entrada apropriados xz tentará usar essa
quantidade de memória mesmo com um baixo número de threads. Ficar sem memória ou trocar não melhorará o
desempenho da descompactação.
Consulte --memlimit-compress=limite para possíveis maneiras de especificar o limite. Definir limite como 0
redefine limite para o valor padrão específico do sistema.
-M limite, --memlimit=limite, --memory=limite
Isso é equivalente a especificar --memlimit-compress=limite --memlimit-decompress=limite --memlimit-mt-de‐
compress=limite.
--no-adjust
Exibe um erro e saia 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 evita que xz alterne o codificador do modo multi-thread para o
modo encadeado único e 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 com‐
pactada.
O ajuste automático é sempre desativado ao criar fluxos 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 xz use tantos threads quanto o(s) processador(es) no suporte do sistema. O número real de encadea‐
mentos pode ser menor que threads se o arquivo de entrada não for grande o suficiente para subdividir em
threads com as configurações fornecidas ou se o uso de mais threads exceder o limite de uso de memória.
Os compactadores usando thread única e várias threads produzem saídas diferentes. O compactador de thread
única fornecerá o menor tamanho de arquivo, mas apenas a saída do compactador de várias threads pode ser
descompactada usando várias threads. Definir threads como 1 usará o modo de thread única. Definir threads
para qualquer outro valor, incluindo 0, usará o compressor de várias threads, mesmo que o sistema tenha
suporte a apenas uma thread de hardware. (xz 5.2.x usou o modo de thread única nesta situação.)
Para usar o modo de várias threads com apenas uma thread, defina threads como +1. O prefixo + não tem
efeito com valores diferentes de 1. Um limite de uso de memória ainda pode fazer xz alternar para o modo
de thread única, 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, um
limite flexível padrão específico do sistema será usado para possivelmente limitar o número de threads. É
um limite flexível no sentido de que é ignorado se o número de threads se tornar um, portanto, um limite
flexível nunca impedirá xz de compactar ou descompactar. Este limite flexível padrão não fará com que xz
alterne do modo de várias threads para o modo de thread única. Os limites ativos podem ser vistos com xz
--info-memory.
Atualmente, o único método de threading é dividir a entrada em blocos e comprimi-los independentemente um
do outro. O tamanho padrão do bloco depende do nível de compactação e pode ser substituído com a opção
--block-size=tamanho.
A descompactação em threads funciona apenas 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 de várias
thread atendem a essa condição, mas os arquivos compactados no modo de thread única não atendem, mesmo se
--block-size=tamanho tiver sido usado.
Cadeias de filtro de compressor personalizadas
Uma cadeia de filtro personalizada permite especificar as configurações de compactação em detalhes, em vez de
confiar nas configurações associadas às predefinições. Quando uma cadeia de filtro personalizada é especificada,
as opções predefinidas (-0 ... -9 e --extreme) anteriores na linha de comando são esquecidas. Se uma opção pre‐
definida for especificada após uma ou mais opções de cadeia de filtros personalizados, a nova predefinição en‐
trará em vigor e as opções de cadeia de filtros personalizados especificadas anteriormente serão esquecidas.
Uma cadeia de filtro é comparável à tubulação na linha de comando. Ao compactar, a entrada descompactada vai para
o primeiro filtro, cuja saída vai para o próximo filtro (se houver). A saída do último filtro é gravada no ar‐
quivo compactado. 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 podem funcionar apenas
como o último filtro na cadeia, alguns apenas como filtro não-último e alguns funcionam em qualquer posição na
cadeia. Dependendo do filtro, essa limitação é inerente ao projeto do filtro ou existe para evitar problemas de
segurança.
Uma cadeia de filtro personalizada é especificada usando uma ou mais opções de filtro na ordem desejada na cadeia
de filtro. Ou seja, a ordem das opções de filtro é significativa! Ao decodificar fluxos brutos (--format=raw), a
cadeia de filtros é especificada na mesma ordem em que foi especificada durante a compactação.
Os filtros usam opções específicas do filtro como uma lista separada por vírgulas. As vírgulas extras em opções
são ignoradas. Cada opção tem um valor padrão, portanto, você precisa especificar apenas aquelas que deseja al‐
terar.
Para ver toda a cadeia de filtros e opções, use xz -vv (isto é, use --verbose duas vezes). Isso também funciona
para visualizar as opções da cadeia de filtros usadas pelas predefinições.
--lzma1[=opções]
--lzma2[=opções]
Adiciona o filtro LZMA1 ou LZMA2 à cadeia de filtros. Esses filtros podem ser usados apenas como o último
filtro na cadeia.
LZMA1 é um filtro legado, que é suportado quase exclusivamente devido ao formato de arquivo legado .lzma,
que suporta apenas LZMA1. LZMA2 é uma versão atualizada do LZMA1 para corrigir alguns problemas práticos
do LZMA1. O formato .xz usa LZMA2 e não suporta LZMA1. A velocidade de compactação e as proporções 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 predefinição. Predefinição consiste em um número
inteiro, que pode ser seguido por modificadores de predefinição de uma única letra. O inteiro pode
ser 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 nenhum preset for especificado, 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
repetidos (correspondências) nos dados não compactados e substituí-los por referências aos dados
atualmente no dicionário. Quanto maior o dicionário, maior a chance de encontrar uma corre‐
spondência. Portanto, aumentar o dicionário tamanho geralmente melhora a taxa de compactação, mas
um dicionário maior que o arquivo não compactado é um desperdício de memória.
Um tamanho de dicionário típico é de 64 KiB a 64 MiB. O mínimo é 4 KiB. O máximo para compactação é
atualmente 1,5 GiB (1536 MiB). O descompactador já oferece suporte a dicionários de até um byte a
menos de 4 GiB, que é o máximo para os formatos de fluxo LZMA1 e LZMA2.
O tamanho de dicionário e o localizador de correspondência (mf) juntos determinam o uso de memória
do codificador LZMA1 ou LZMA2. O mesmo (ou maior) tamanho de dicionário é necessário para descom‐
pactar que foi usado durante a compactação, portanto, o uso de memória do decodificador é determi‐
nado pelo tamanho do dicionário usado durante a compactação. Os cabeçalhos .xz armazenam o tamanho
de dicionário como 2^n ou 2^n + 2^(n-1), então esses tamanhos são um tanto preferidos para com‐
pactação. Outros tamanhos serão arredondados quando armazenados nos cabeçalhos .xz.
lc=lc Especifica o número de bits de contexto literais. 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, literais são simplesmente bytes de 8 bits que são codificados um de cada vez.
A codificação literal assume que os bits lc mais altos do byte não compactado anterior se correla‐
cionam com o próximo byte. Por exemplo, em um texto típico em inglês, uma letra maiúscula geral‐
mente é 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 altos são 010 para letras maiúscu‐
las 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 compactação máxima, experimente lc=4. Às vezes
ajuda um pouco, às vezes piora a compactação. Se piorar, experimente lc=2 também.
lp=lp Especifica o número de bits de posição literal. O mínimo é 0 e o máximo é 4; o padrão é 0.
Lp afeta que tipo de alinhamento nos dados não compactados é assumido ao codificar literais. Con‐
sulte pb abaixo para obter mais informações sobre alinhamento.
pb=pb Especifica o número de bits de posição. O mínimo é 0 e o máximo é 4; o padrão é 2.
Pb afeta que tipo de alinhamento nos dados não compactados é 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á melhor es‐
timativa.
Quando o alinhamento é conhecido, definir pb adequadamente pode reduzir um pouco o tamanho do ar‐
quivo. Por exemplo, com arquivos de texto com alinhamento de um byte (US-ASCII, ISO-8859-*, UTF-8),
a configuração pb=0 pode melhorar um pouco a compactação. Para texto UTF-16, pb=1 é uma boa es‐
colha. 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 em consideração ao projetar for‐
matos de arquivo que provavelmente serão compactados com LZMA1 ou LZMA2.
mf=mf O localizador de correspondência tem um efeito importante na velocidade do codificador, uso de
memória e taxa de compactação. Normalmente, os localizadores de correspondência de Hash Chain são
mais rápidos do que os localizadores de correspondência de árvore binária. O padrão depende do pre‐
definição: 0 usa hc3, 1–3 usa hc4 e o resto usa bt4.
Os seguintes localizadores de correspondência são suportados. As fórmulas de uso de memória abaixo
são aproximações aproximadas, que estão mais próximas da realidade quando dict é uma potência de
dois.
hc3 Cadeia de hashs com hashing de 2 e 3 bytes
Valor mínimo para nice: 3
Uso de memória:
dict * 7.5 (if dict <= 16 MiB);
dict * 5.5 + 64 MiB (if dict > 16 MiB)
hc4 Cadeia de hashs com hashing de 2, 3 e 4 bytes
Valor mínimo para nice: 4
Uso de memória:
dict * 7.5 (if dict <= 32 MiB);
dict * 6.5 (if 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 (if dict <= 16 MiB);
dict * 9.5 + 64 MiB (if 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 (if dict <= 32 MiB);
dict * 10.5 (if dict > 32 MiB)
mode=modo
O modo de compactação especifica o método para analisar os dados produzidos pelo localizador de
correspondência. Os modos suportados são fast e normal. O padrão é fast para predefinições 0–3 e
normal para predefinições 4–9.
Normalmente, fast é usado com localizadores de correspondência cadeia de hashs e normal com local‐
izadores de correspondência de árvore binária. Isso também é o que os predefinições fazem.
nice=nice
Especifica o que é considerado um bom comprimento para uma correspondência. Uma vez que uma corre‐
spondência de pelo menos nice bytes é encontrada, o algoritmo para de procurar correspondências
possivelmente melhores.
Nice pode ser 2–273 bytes. Valores mais altos tendem a fornecer melhor taxa de compactação em
detrimento da velocidade. O padrão depende do predefinição.
depth=profundidade
Especifica 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 um profundidade razoável de mf e nice.
Uma profundidade razoável para cadeias de hash é 4–100 e 16–1000 para árvores binárias. Usar val‐
ores muito altos para profundidade pode tornar o codificador extremamente lento com alguns ar‐
quivos. Evite definir profundidade acima de 1000 a menos que você esteja preparado para interromper
a compactação caso ela esteja demorando muito.
Ao decodificar fluxos brutos (--format=raw), o LZMA2 precisa apenas do dicionário tamanho. LZMA1 também
precisa de lc, lp e pb.
--x86[=opções]
--arm[=opções]
--armthumb[=opções]
--arm64[=opções]
--powerpc[=opções]
--ia64[=opções]
--sparc[=opções]
Adiciona um filtro de ramificação/chamada/salto (BCJ) à cadeia de filtros. Esses filtros podem ser usados
apenas como um filtro não último na cadeia de filtros.
Um filtro BCJ converte endereços relativos no código de máquina em suas contrapartes absolutas. Isso não
altera o tamanho dos dados, mas aumenta a redundância, o que pode ajudar o LZMA2 a produzir um arquivo .xz
0–15 % menor. Os filtros BCJ são sempre reversíveis, portanto, usar um filtro BCJ para o tipo errado de
dados não causa nenhuma perda de dados, embora possa piorar um pouco a taxa de compactação.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 compactação:
• Alguns tipos de arquivos contendo código executável (por exemplo, arquivos de objeto, bibliotecas
estáticas e módulos do kernel do Linux) têm os endereços nas instruções preenchidos com valores de
preenchimento. Esses filtros BCJ ainda vão fazer a conversão de endereço, o que vai piorar a com‐
pactação desses arquivos.
• Se um filtro BCJ for aplicado em um arquivo, é possível que isso torne a taxa de compactação pior do
que não usar um filtro BCJ. Por exemplo, se houver executáveis semelhantes ou mesmo idênticos, a fil‐
tragem provavelmente tornará os arquivos menos semelhantes e, portanto, a compactação será pior. O
conteúdo de arquivos não executáveis no mesmo arquivo também pode ser importante. Na prática tem que
tentar com e sem filtro BCJ para ver qual é melhor em cada situação.
Conjuntos de instruções diferentes têm alinhamento diferente: o arquivo executável deve ser alinhado a um
múltiplo desse valor nos dados de entrada para fazer o filtro funcionar.
Filtro Alinhamento Observações
x86 1 x86 32 bits ou 64 bits
ARM 4
ARM-Thumb 2
ARM64 4 Alinhamento de 4096 bytes
é melhor
PowerPC 4 Somente big endian
IA-64 16 Itanium
SPARC 4
Como os dados filtrados por BCJ geralmente são compactados com LZMA2, a taxa de compactação pode melhorar
ligeiramente se as opções de LZMA2 forem definidas para corresponder ao alinhamento do filtro BCJ sele‐
cionado. Por exemplo, com o filtro IA-64, é bom definir pb=4 ou mesmo pb=4,lp=4,lc=0 com LZMA2 (2^4=16). O
filtro x86 é uma exceção; geralmente é bom manter o alinhamento padrão de quatro bytes do LZMA2 ao com‐
pactar executáveis x86.
Todos os filtros BCJ suportam as mesmas opções:
start=deslocamento
Especifica o deslocamento inicial que é usado na conversão entre endereços relativos e absolutos. O
deslocamento deve ser um múltiplo do alinhamento do filtro (ver tabela acima). O padrão é zero. Na
prática, o padrão é bom; especificar um deslocamento personalizado quase nunca é útil.
--delta[=opções]
Adiciona o filtro Delta à cadeia de filtros. O filtro Delta só pode ser usado como filtro não-último na
cadeia de filtros.
Atualmente, apenas o cálculo simples de delta byte a byte é suportado. Pode ser útil ao compactar, por ex‐
emplo, imagens bitmap não compactadas ou áudio PCM não compactado. No entanto, algoritmos de propósito es‐
pecial podem fornecer resultados significativamente melhores do que Delta + LZMA2. Isso é verdade espe‐
cialmente com áudio, que compacta mais rápido e melhor, por exemplo, com flac(1).
Opções suportadas:
dist=distância
Especifica a distância do cálculo delta em bytes. distância deve ser 1–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 avisos. Especifique isso 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
Ser detalhado. Se o erro padrão estiver conectado a um terminal, xz exibirá um indicador de progresso. Es‐
pecifique --verbose duas vezes dará uma saída ainda mais 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 por‐
centagem não pode ser mostrada em encadeamentos (pipe).
• Quantidade de dados compactados produzidos (compactando) ou consumidos (descompactando).
• Quantidade de dados não compactados consumidos (compactação) ou produzidos (descompactação).
• Taxa de compactação, que é calculada dividindo a quantidade de dados compactados processados até o mo‐
mento pela quantidade de dados não compactados processados até o momento.
• Velocidade de compactação ou descompactação. Isso é medido como a quantidade de dados não compactados
consumidos (compactação) ou produzidos (descompactação) por segundo. É mostrado após alguns segundos
desde que xz começou a processar o arquivo.
• Tempo decorrido no formato M:SS ou H:MM:SS.
• O tempo restante estimado é mostrado apenas quando o tamanho do arquivo de entrada é conhecido e alguns
segundos já se passaram desde que xz começou a processar o arquivo. A hora é mostrada em um formato
menos preciso que nunca tem dois pontos, por exemplo, 2 min 30 s.
Quando o erro padrão não é um terminal, --verbose fará com que xz imprima o nome do arquivo, tamanho com‐
pactado, tamanho não compactado, taxa de compactação e possivelmente também a velocidade e o tempo decor‐
rido em uma única linha para o erro padrão após a compactação ou descompactando o arquivo. A velocidade e
o tempo decorrido são incluídos apenas quando a operação leva pelo menos alguns segundos. Se a operação
não foi concluída, por exemplo, devido à interrupção do usuário, também é impressa a porcentagem de con‐
clusão se o tamanho do arquivo de entrada for conhecido.
-Q, --no-warn
Não define o status de saída como 2, mesmo que uma condição digna de um aviso tenha sido detectada. Esta
opção não afeta o nível de detalhamento, portanto, tanto --quiet quanto --no-warn devem ser usados para
não exibir avisos e não alterar o status de saída.
--robot
Imprime mensagens em um formato analisável por máquina. Isso visa facilitar a criação de frontends que de‐
sejam usar xz em vez de liblzma, o que pode ser o caso de vários scripts. A saída com esta opção habili‐
tada deve ser estável em versões xz. Consulte a seção MODO ROBÔ para obter detalhes.
--info-memory
Exibe, em formato legível por humanos, quanta memória física (RAM) e quantos threads de processador xz
acredita que o sistema possui e os limites de uso de memória para compactação e descompactação e saia com
êxito.
-h, --help
Exibe uma mensagem de ajuda descrevendo as opções mais usadas e sai com sucesso.
-H, --long-help
Exibe uma mensagem de ajuda descrevendo todos os recursos de xz e sai com sucesso
-V, --version
Exibe o número da versão de xz e liblzma em formato legível por humanos. Para obter uma saída analisável
por máquina, especifique --robot antes de --version.
MODO ROBÔ
O modo robô é ativado com a opção --robot. Isso torna a saída de xz mais fácil de ser analisada por outros pro‐
gramas. Atualmente --robot é suportado apenas junto com --version, --info-memory e --list. Ele terá suporte para
compactação e descompactação no futuro.
Versão
xz --robot --version prints the version number of xz and liblzma in the following format:
XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS
X Versão principal.
YYY Versão menor. Números pares são estáveis. Os 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 iguais 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.
Informações de limite de memória
xz --robot --info-memory prints a single line with multiple tab-separated columns:
1. Quantidade total de memória física (RAM) em bytes.
2. Limite de uso de memória para compactação em bytes (--memlimit-compress). Um valor especial de 0 indica a
configuração padrão que para o modo de thread única é o mesmo que sem limite.
3. Limite de uso de memória para descompactação em bytes (--memlimit-decompress). Um valor especial de 0 indica
a configuração padrão que para o modo de thread única é o mesmo que sem limite.
4. Desde xz 5.3.4alpha: Uso de memória para descompactação com várias thread em bytes (--memlimit-mt-decom‐
press). Isso nunca é zero porque um valor padrão específico do sistema mostrado na coluna 5 é usado se nenhum
limite for 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.
5. 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 compactar com um número automático de threads (--threads=0) e nenhum limite de uso de
memória foi especificado (--memlimit-compress). Isso também é usado como o valor padrão para --mem‐
limit-mt-decompress.
6. 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.
Modo lista
xz --robot --list usa saída separada por tabulações. A primeira coluna de cada linha possui uma string que indica
o tipo de informação encontrada naquela linha:
name Esta é sempre a primeira linha ao começar a listar um arquivo. A segunda coluna na linha é o nome do ar‐
quivo.
file Esta linha contém informações gerais sobre o arquivo .xz. Esta linha é sempre impressa após a linha name.
stream Este tipo de linha é usado somente quando --verbose foi especificado. Existem tantas linhas de stream
quanto fluxos no arquivo .xz.
block Este tipo de linha é usado somente quando --verbose foi especificado. Existem tantas linhas block quanto
blocos no arquivo .xz. As linhas block são mostradas após todas as linhas 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 block. Assim como a linha arquivo, a linha summary contém informações gerais sobre o
arquivo .xz.
totals Esta linha é sempre a última linha da saída da lista. Ele mostra as contagens totais e tamanhos.
As colunas das linhas file:
2. Número de fluxos no arquivo
3. Número total de blocos no(s) fluxo(s)
4. Tamanho compactado do arquivo
5. Uncompressed size of the file
6. Taxa de compactação, por exemplo, 0.123. Se a proporção for superior a 9.999, serão exibidos três
traços (---) em vez da proporção.
7. Lista separada por vírgulas de nomes de verificação de integridade. As seguintes strings são usadas
para os tipos de verificação conhecidos: None, CRC32, CRC64 e SHA-256. Para tipos de verificações de‐
sconhecidos, Unknown-N é usado, onde N é o ID do cheque como um número decimal (um ou dois dígitos).
8. Tamanho total do preenchimento de fluxo no arquivo
As colunas das linhas stream:
2. Número do fluxo (o primeiro fluxo é 1)
3. Número de blocos no fluxo
4. Deslocamento inicial compactado
5. Deslocamento inicial descompactado
6. Tamanho compactado (não inclui preenchimento de fluxo)
7. Tamanho descompactado
8. Taxa de compactação
9. Nome da verificação de integridade
10. Tamanho do preenchimento do fluxo
As colunas das linhas block:
2. Número do fluxo que contém este bloco
3. Número do bloco relativo ao início do fluxo (o primeiro bloco é 1)
4. Número do bloco relativo ao início do arquivo
5. Deslocamento inicial compactado em relação ao início do arquivo
6. Deslocamento inicial descompactado em relação ao início do arquivo
7. Tamanho total compactado do bloco (inclui cabeçalhos)
8. Tamanho descompactado
9. Taxa de compactação
10. Nome da verificação de integridade
Se --verbose for especificado duas vezes, colunas adicionais serão incluídas nas linhas block. Eles não são ex‐
ibidos com um único --verbose, porque obter essas informações requer muitas buscas e, portanto, pode ser lento:
11. Valor da verificação de integridade em hexadecimal
12. Tamanho do cabeçalho do bloco
13. Sinalizadores de bloco: c indica que o tamanho compactado está presente e u indica que o tamanho não
compactado está presente. Se o sinalizador não estiver definido, um traço (-) será exibido para manter
o comprimento da string fixo. Novos sinalizadores podem ser adicionados ao final da string no futuro.
14. Tamanho dos dados reais compactados no bloco (isso exclui o cabeçalho do bloco, o preenchimento do
bloco e os campos de verificação)
15. Quantidade de memória (em bytes) necessária para descompactar este bloco com esta versão xz
16. Cadeia de filtro. Observe que a maioria das opções usadas no momento da compactação não pode ser con‐
hecida, pois apenas as opções necessárias para a descompactação são armazenadas nos cabeçalhos .xz.
As colunas das linhas summary:
2. Quantidade de memória (em bytes) necessária para descompactar este arquivo com esta versão do xz
3. yes ou no indicando se todos os cabeçalhos de bloco têm tamanho compactado e tamanho não compactado
armazenados neles
Desde xz 5.1.2alpha:
4. Versão mínima do xz necessária para descompactar o arquivo
As colunas da linha totals:
2. Número de fluxos
3. Número de blocos
4. Tamanho compactado
5. Tamanho descompactado
6. Taxa de compactação média
7. Lista separada por vírgulas de nomes de verificação de integridade que estavam presentes nos arquivos
8. Tamanho do preenchimento do fluxo
9. Número de arquivos. Isso está aqui para manter a ordem das colunas anteriores a mesma das linhas file.
Se --verbose for especificado duas vezes, colunas adicionais serão incluídas na linha totals:
10. Quantidade máxima de memória (em bytes) necessária para descompactar os arquivos com esta versão do xz
11. yes ou no indicando se todos os cabeçalhos de bloco têm tamanho compactado e tamanho não compactado
armazenados neles
Desde xz 5.1.2alpha:
12. 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 ex‐
istentes, mas as colunas existentes não serão alteradas.
STATUS DE SAÍDA
0 Está tudo bem.
1 Ocorreu um erro.
2 Algo digno de um aviso ocorreu, mas ocorreu nenhum erro real.
Observações (não avisos ou erros) impressas no erro padrão não afetam o status de saída.
AMBIENTE
xz analisa listas de opções separadas por espaços 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 as opções são analisadas a partir das
variáveis de ambiente; todas as não opções são silenciosamente ignoradas. A análise é feita com getopt_long(3)
que também é usado para os argumentos da linha de comando.
XZ_DEFAULTS
Opções padrão específicas do usuário ou de todo o 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. Excluindo scripts de
inicialização de shell e casos especiais semelhantes, os scripts nunca devem definir ou remover 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(1):
XZ_OPT=-2v tar caf foo.tar.xz foo
Os scripts podem usar XZ_OPT, por exemplo, para definir opções de compactação padrão específicas do
script. Ainda é 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 assim:
XZ_OPT=${XZ_OPT-"-7e"} export XZ_OPT
COMPATIBILIDADE COM LZMA UTILS
A sintaxe da linha de comando do xz é praticamente um superconjunto de lzma, unlzma e lzcat conforme encontrado
no LZMA Utils 4.32.x. Na maioria dos casos, é possível substituir LZMA Utils por XZ Utils sem interromper os
scripts existentes. Existem algumas incompatibilidades, porém, que às vezes podem causar problemas.
Níveis de predefinição de compactação
A numeração das predefinições de nível de compactação não é idêntica em xz e LZMA Utils. A diferença mais impor‐
tante é como os tamanhos dos dicionários são mapeados para diferentes predefinições. O tamanho do dicionário é
aproximadamente igual ao uso de memória do descompactador.
Nível xz LZMA Utils
-0 256 KiB N/D
-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 de tamanho do dicionário também afetam o uso da memória do compressor, mas existem algumas outras
diferenças entre LZMA Utils e XZ Utils, que tornam a diferença ainda maior:
Nível xz LZMA Utils 4.32.x
-0 3 MiB N/D
-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, então ambos usam um dicionário de 8
MiB por padrão.
Arquivos .lzma em um fluxo versus sem ser em um fluxo
O tamanho descompactado do arquivo pode ser armazenado no cabeçalho de .lzma. O LZMA Utils faz isso ao compactar
arquivos comuns. A alternativa é marcar que o tamanho não compactado é desconhecido e usar o marcador de fim de
carga útil para indicar onde o descompactador deve parar. O LZMA Utils usa este método quando o tamanho não com‐
pactado não é conhecido, como é o caso, por exemplo, de encadeamentos (pipes).
xz oferece suporte à descompactação de arquivos .lzma com ou sem marcador de fim de carga útil, mas todos os ar‐
quivos .lzma criados por xz usarão marcador de fim de carga útil e terão o tamanho descompactado marcado como de‐
sconhecido no cabeçalho de .lzma. Isso pode ser um problema em algumas situações incomuns. Por exemplo, um de‐
scompactador de .lzma em um dispositivo embarcado pode funcionar apenas com arquivos que tenham tamanho descom‐
pactado conhecido. Se você encontrar esse problema, precisará usar o LZMA Utils ou o LZMA SDK para criar arquivos
.lzma com tamanho descompactado conhecido.
Arquivos .lzma não suportados
O formato .lzma permite valores lc até 8 e valores lp até 4. LZMA Utils pode descompactar arquivos com qualquer
lc e lp, mas sempre cria arquivos com lc=3 e lp=0. Criar arquivos com outros lc e lp é possível com xz e com LZMA
SDK.
A implementação do filtro LZMA1 em liblzma requer que a soma de lc e lp não exceda 4. Assim, arquivos .lzma, que
excedam esta limitação, não podem ser descompactados com xz.
LZMA Utils cria apenas arquivos .lzma que possuem um tamanho de dicionário de 2^n (uma potência de 2), mas aceita
arquivos com qualquer tamanho de dicionário. liblzma aceita apenas arquivos .lzma que tenham um tamanho de di‐
cioná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, já que praticamente todos os arquivos .lzma foram com‐
pactados com configurações que o liblzma aceitará.
Lixo à direita
Ao descompactar, o LZMA Utils silenciosamente ignora tudo após o primeiro fluxo .lzma. Na maioria das situações,
isso é um bug. Isso também significa que o LZMA Utils não oferece suporte a descompactação de arquivos .lzma con‐
catenados.
Se houver dados restantes após o primeiro fluxo de .lzma, xz considera o arquivo corrompido, a menos que --sin‐
gle-stream tenha sido usado. Isso pode quebrar scripts obscuros que presumiram que o lixo à direita é ignorado.
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 se as opções de compactação forem idênticas. Isso ocorre porque o codificador pode ser
aprimorado (compactação mais rápida ou melhor) sem afetar o formato do arquivo. A saída pode variar mesmo entre
diferentes compilações da mesma versão do XZ Utils, se diferentes opções de compilação forem usadas.
A informaçã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 antigos e novos tenham sido compactados com a mesma
versão xz. Esse problema pode ser corrigido se uma parte da implementação do codificador for congelada para man‐
ter a saída de rsyncable estável nas versões do xz.
Descompactadores .xz embarcados
As implementações do descompactador .xz embarcados, como o XZ Embedded, não oferecem necessariamente suporte a
arquivos criados com tipos de verificações de integridade diferentes de none 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 oferecem suporte a todos os tipos de veri‐
ficaçã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 oferece suporte a filtros BCJ, mas apenas com o deslocamento inicial padrão.
EXEMPLOS
Básico
Compactar o arquivo foo em foo.xz usando o nível de compactação padrão (-6) e remover foo se a compactação for
bem-sucedida:
xz foo
Descompactar bar.xz em bar e não remover bar.xz mesmo se a descompactação for bem-sucedida:
xz -dk bar.xz
Criar baz.tar.xz com a predefinição -4e (-4 --extreme), que é mais lenta que o padrão -6, mas precisa de menos
memória para compactação e descompactação (48 MiB e 5 MiB, respectivamente):
tar cf - baz | xz -4e > baz.tar.xz
Uma mistura de arquivos compactados e descompactados pode ser descompactada para a saída padrão com um único co‐
mando:
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
Compactação paralela de muitos arquivos
No GNU e *BSD, find(1) e xargs(1) podem ser usados para paralelizar a compactaçã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 paralelos do xz. O melhor valor para a opção -n depende de
quantos arquivos devem ser compactados. Se houver apenas alguns arquivos, o valor provavelmente deve ser 1; com
dezenas de milhares de arquivos, 100 ou até mais podem ser apropriados para reduzir o número de processos de xz
que xargs(1) eventualmente criará.
A opção -T1 para xz existe para forçá-lo ao modo de thread única, porque xargs(1) é usado para controlar a quan‐
tidade de paralelização.
Modo robô
Calcular quantos bytes foram salvos no total depois de compactar vários arquivos:
xz --robot --list *.xz | awk '/^totals/{print $5-$4}'
Um script pode querer saber que está usando xz novo o suficiente. 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 suportavam
a opção --robot:
if ! eval "$(xz --robot --version 2> /dev/null)" || [ "$XZ_VERSION" -lt 50000002 ]; then echo "Your xz is too old." fi unset XZ_VERSION LIBLZMA_VERSION
Definir um limite de uso de memória para descompactação usando XZ_OPT, mas se um limite já tiver sido definido,
não o aumentar:
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 abrangem apenas um subconjunto das combinações potencialmente úteis de con‐
figurações de compactação.
As colunas CompCPU das tabelas das descrições das opções -0 ... -9 e --extreme são úteis ao personalizar as pre‐
definiçõ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 tanto grande (por exemplo, 32 MiB) para compactar bem, mas
deseja comprimi-lo mais rapidamente do que xz -8 faria, uma predefinição com um valor CompCPU baixo (por exemplo,
1) pode ser modificado para usar um dicionário maior:
xz --lzma2=preset=1,dict=32MiB foo.tar
Com certos arquivos, o comando acima pode ser mais rápido que xz -6 enquanto compacta significativamente melhor.
No entanto, deve-se enfatizar que apenas alguns arquivos se beneficiam de um grande dicionário, mantendo o valor
CompCPU baixo. A situação mais óbvia, onde um grande dicionário pode ajudar muito, é um arquivo contendo arquivos
muito semelhantes de pelo menos alguns megabytes cada. O tamanho do dicionário deve 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 muito alto de memória do compactador e do descompactador for bom e o arquivo que está sendo compactado
tiver pelo menos várias centenas de megabytes, pode ser útil usar um dicionário ainda maior do que os 64 MiB que
o 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 compacta‐
dor e do descompactador. Lembre-se que usar um dicionário maior que o tamanho do arquivo descompactado é des‐
perdício de memória, então o comando acima não é útil para arquivos pequenos.
Às vezes, o tempo de compactação não importa, mas o uso de memória do descompactador deve ser mantido baixo, por
exemplo, para possibilitar a descompactação do arquivo em um sistema embarcado. O comando a seguir usa -6e (-6
--extreme) como base e define o dicionário como apenas 64 KiB. O arquivo resultante pode ser descompactado com XZ
Embedded (é por isso que existe --check=crc32) usando cerca de 100 KiB de memória.
xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo
Se você deseja espremer 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 aju‐
dar, 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 (como 0,1 %) menor que xz -6e
(tente também sem lc=4):
xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar
O uso de outro filtro junto com o LZMA2 pode melhorar a compactação com determinados tipos de arquivo. Por exem‐
plo, 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 dará um
erro, porque não pode haver nenhum filtro após LZMA2 e também porque o filtro x86 BCJ não pode ser usado como o
último filtro em a corrente.
O filtro Delta junto com LZMA2 pode dar bons resultados com imagens bitmap. Ele geralmente deve superar o PNG,
que possui alguns filtros mais avançados do que o delta simples, mas usa 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,
bitmap RGB de 24 bits precisa de dist=3, e também é bom passar pb=0 para 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)
XZ Utils: <https://tukaani.org/xz/>
XZ Embedded: <https://tukaani.org/xz/embedded.html>
LZMA SDK: <https://7-zip.org/sdk.html>
Tukaani 2023-07-17 XZ(1)
NOME
xz, unxz, xzcat, lzma, unlzma, lzcat - Compacta ou descompacta arquivos .xz e .lzma
SINOPSE
xz [opção...] [arquivo...]
COMANDOS APELIDOS
unxz é equivalente a xz --decompress.
xzcat é equivalente a xz --decompress --stdout.
lzma é equivalente a xz --format=lzma.
unlzma é equivalente a xz --format=lzma --decompress.
lzcat é equivalente a xz --format=lzma --decompress --stdout.
Ao escrever scripts que precisam descompactar arquivos, é recomendável sempre usar o nome xz com os argumentos
apropriados (xz -d ou xz -dc) em vez dos nomes unxz e xzcat.
DESCRIÇÃO
xz é uma ferramenta de compactação de dados de uso geral com sintaxe de linha de comando semelhante ao gzip(1) e
ao bzip2(1). O formato de arquivo nativo é o formato .xz, mas o formato legado .lzma usado por LZMA Utils e
fluxos compactados brutos sem cabeçalhos de formato de contêiner também são suportados. Além disso, a descom‐
pactação do formato .lz usado por lzip é suportada.
xz compacta ou descompacta cada arquivo de acordo com o modo de operação selecionado. Se nenhum arquivo for
fornecido ou arquivo for -, xz lê da entrada padrão e grava os dados processados na saída padrão. xz recusará
(exibirá um erro e ignorará o arquivo) para 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 --stdout seja especificado, arquivos diferentes de - são gravados em um novo arquivo cujo nome é de‐
rivado do nome arquivo de origem:
• Ao compactar, 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 des‐
tino. 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 arquivo será ignorado.
A menos que grave na saída padrão, xz exibirá um aviso e pulará o arquivo se qualquer um dos seguintes se
aplicar:
• Arquivo não é um arquivo normal. Links simbólicos não são seguidos e, portanto, não são considerados arquivos
comuns.
• Arquivo tem mais de um link físico.
• File tem setuid, setgid ou sticky bit definido.
• O modo de operação está definido para compactar e o arquivo já possui um sufixo do formato de arquivo de des‐
tino (.xz ou .txz ao compactar para o formato .xz e .lzma ou .tlz ao compactar para o formato .lzma).
• O modo de operação está definido para descompactar e o arquivo não possui um sufixo de nenhum dos formatos de
arquivo suportados (.xz, .txz, .lzma, .tlz , ou .lz).
Depois de compactar ou descompactar com êxito o arquivo, o xz copia o dono, grupo, permissões, horário de acesso
e horário de modificação do arquivo de origem para o arquivo de destino. Se a cópia do grupo falhar, as per‐
missões serão modificadas para que o arquivo de destino não se torne acessível a usuários que não têm permissão
para acessar o arquivo de origem. xz ainda não oferece suporte à cópia de outros metadados, como listas de cont‐
role de acesso ou atributos estendidos.
Depois que o arquivo de destino for fechado com êxito, o arquivo de origem será 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 ocor‐
rer um erro.
O envio de SIGINFO ou SIGUSR1 para o processo do xz faz com que ele imprima informações de andamento para erro
padrão. Isso tem uso limitado, pois quando o erro padrão é um terminal, usar --verbose exibirá um indicador de
progresso de atualização automática.
Uso de memória
O uso de memória de xz varia de algumas centenas de kilobytes a vários gigabytes, dependendo das configurações de
compactação. As configurações usadas ao compactar um arquivo determinam os requisitos de memória do descompacta‐
dor. Normalmente, o descompactador precisa de 5 % a 20 % da quantidade de memória que o compactador precisou ao
criar o arquivo. Por exemplo, descompactar um arquivo criado com xz -9 atualmente requer 65 MiB de memória. Ainda
assim, é possível ter arquivos .xz que requerem vários gigabytes de memória para descompactar.
Especialmente os usuários de sistemas mais antigos podem achar irritante a possibilidade de uso de memória muito
grande. Para evitar surpresas desconfortáveis, o xz possui um limitador de uso de memória embutido, que está
desabilitado por padrão. Embora alguns sistemas operacionais forneçam maneiras de limitar o uso de memória dos
processos, confiar nele 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 ativado com a opção de linha de comando --memlimit=limite. Geralmente é
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 compactação e descompactação us‐
ando --memlimit-compress=limite e --memlimit-decompress=limite. Usar essas duas opções fora de XZ_DEFAULTS rara‐
mente é útil porque uma única execução de xz não pode fazer compactação e descompactação e --memlimit=limite (ou
-M limite ) é mais curto para digitar na linha de comando.
Se o limite de uso de memória especificado for excedido durante a descompactação, xz exibirá um erro e a descom‐
pactação do arquivo falhará. Se o limite for excedido durante a compactaçã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 escala das configurações é feita em etapas que não corre‐
spondem às predefinições do nível de compactação, por exemplo, se o limite for apenas um pouco menor que o valor
necessário para xz -9, as configurações serão reduzidas apenas um pouco , não até xz -8.
Concatenação e preenchimento com arquivos .xz
É possível concatenar arquivos .xz como estão. xz irá descompactar tais 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 consi‐
stir 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 tamanhos de arquivo em blocos de 512 bytes.
Concatenação e preenchimento não são permitidos com arquivos .lzma ou fluxos brutos.
OPÇÕES
Sufixos inteiros e valores especiais
Na maioria dos lugares onde um argumento inteiro é esperado, um sufixo opcional é suportado para indicar facil‐
mente números inteiros grandes. Não deve haver espaço entre o número 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 de KiB.
MiB Multiplica o número inteiro por 1.048.576 (2^20). Mi, m, M e MB são aceitos como sinônimos de MiB.
GiB Multiplica o número inteiro por 1.073.741.824 (2^30). Gi, g, G e GB são aceitos como sinônimos de 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 dadas, a última entrará em vigor.
-z, --compress
Compacta. Este é o modo de operação padrão quando nenhuma opção de modo de operação é especificada e nen‐
hum outro modo de operação está implícito no nome do comando (por exemplo, unxz implica em --decompress).
-d, --decompress, --uncompress
Descompacta.
-t, --test
Testa a integridade de 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
Imprime informações sobre arquivos compactados. Nenhuma saída descompactada é produzida e nenhum arquivo é
criado ou removido. No modo de lista, o programa não pode ler os dados compactados da entrada padrão ou de
outras fontes não pesquisáveis.
A listagem padrão mostra informações básicas sobre 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 muitas buscas.
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 tiver largura o suficiente.
A saída exata pode variar entre versões xz e localidades diferentes. Para saída legível por máquina, --ro‐
bot --list deve ser usado.
Modificadores de operação
-k, --keep
Não exclui os arquivos de entrada.
Desde xz 5.2.6, esta opção também faz xz compactar ou descompactar mesmo se a entrada for um link
simbólico para um arquivo comum, tiver mais de um link físico ou tiver o setuid, setgid ou sticky bit
definir. Os bits setuid, setgid e sticky não são copiados para o arquivo de destino. Nas versões anteri‐
ores, isso era feito apenas com --force.
-f, --force
Esta opção tem vários efeitos:
• Se o arquivo de destino já existir, o exclui antes de compactar ou descompactar.
• Compacta ou descompacta, mesmo que a entrada seja um link simbólico para um arquivo normal, tenha mais
de um link físico ou tenha setuid, setgid ou sticky bit definido. Os bits setuid, setgid e sticky não
são copiados para o arquivo de destino.
• Quando usado com --decompress --stdout e xz não consegue reconhecer o tipo do arquivo de origem, copia
o arquivo de origem como está na saída padrão. Isso permite que xzcat --force seja usado como cat(1)
para arquivos que não foram compactados com xz. Observe que, no futuro, o xz pode oferecer suporte a
novos formatos de arquivo compactado, o que pode fazer com que o xz descompacte mais tipos de arquivos
em vez de copiá-los como na saída padrão. --format=formato pode ser usado para restringir xz para de‐
scompactar apenas um único formato de arquivo.
-c, --stdout, --to-stdout
Grava os dados compactados ou descompactados na saída padrão em vez de em um arquivo. Isso implica em
--keep.
--single-stream
Descompacta apenas o primeiro fluxo de .xz e ignora silenciosamente possíveis dados de entrada restantes
após o fluxo. Normalmente, esse restante posterior sem uso faz com que xz exiba um erro.
xz nunca descompacta mais de um fluxo de arquivos .lzma ou fluxos brutos, mas esta opção ainda faz xz ig‐
norar os possíveis dados posteriores 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.
--no-sparse
Desativa a criação de arquivos esparsos. Por padrão, ao descompactar em um arquivo normal, xz tenta tornar
o arquivo esparso se os dados descompactados contiverem longas sequências de zeros binários. Ele também
funciona ao gravar na saída padrão, desde que a saída padrão esteja conectada a um arquivo normal e certas
condições adicionais sejam atendidas para torná-la segura. A criação de arquivos esparsos pode economizar
espaço em disco e acelerar a descompactação, reduzindo a quantidade de E/S do disco.
-S .suf, --suffix=.suf
Ao compactar, usa .suf como sufixo para o arquivo de destino em vez de .xz ou .lzma. Se não estiver gra‐
vando 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, reconhece arquivos com o sufixo .suf além de arquivos com o sufixo .xz, .txz, .lzma, .tlz
ou .lz . Se o arquivo de origem tiver o sufixo .suf, o sufixo será removido para obter o nome do arquivo
de destino.
Ao compactar ou descompactar fluxos brutos (--format=raw), o sufixo sempre deve ser especificado, a menos
que seja gravado na saída padrão, porque não há sufixo padrão para fluxos brutos.
--files[=arquivo]
Lê os nomes dos arquivos a serem processados em arquivo; se arquivo for omitido, os nomes dos arquivos
serão lidos da entrada padrão. Os nomes de arquivo devem terminar com o caractere de nova linha. Um traço
(-) é considerado um nome de arquivo regular; não significa entrada padrão. Se os nomes de arquivo forem
fornecidos também como argumentos de linha de comando, eles serão processados antes da leitura dos nomes
de arquivo de arquivo.
--files0[=arquivo]
Isso é idêntico a --files[=arquivo], exceto que cada nome de arquivo deve ser finalizado com o caractere
nulo.
Opções básicas de formato de arquivo e de compactação
-F formato, --format=formato
Especifica o formato de arquivo para compactar ou descompactar:
auto Este é o padrão. Ao compactar, auto é equivalente a xz. Ao descompactar, o formato do arquivo de
entrada é detectado automaticamente. Observe que os fluxos brutos (criados com --format=raw) não
podem ser detectados automaticamente.
xz Compacta no formato de arquivo .xz ou aceite apenas arquivos .xz ao descompactar.
lzma, alone
Compacta no formato de arquivo legado .lzma ou aceite apenas arquivos .lzma ao descompactar. O nome
alternativo alone é fornecido para compatibilidade com versões anteriores do LZMA Utils.
lzip Aceita apenas arquivos .lz ao descompactar. Sem suporte a compactação.
O formato .lz versão 0 e a versão não estendida 1 são suportados. Os arquivos da versão 0 foram
produzidos por lzip 1.3 e anteriores. Esses arquivos não são comuns, mas podem ser encontrados em
arquivos compactados, pois alguns pacotes de origem foram lançados nesse formato. As pessoas também
podem ter arquivos pessoais antigos neste formato. O suporte de descompactação para o formato
versão 0 foi removido em lzip 1.18.
lzip 1.4 e posteriores criam arquivos no formato versão 1. A extensão do marcador de descarga de
sincronização para o formato versão 1 foi adicionada em lzip 1.6. Esta extensão raramente é usada e
não é suportada por xz (diagnosticada como entrada corrompida).
raw Compacta ou descompacta um fluxo bruto (sem cabeçalhos). Isso é destinado apenas a usuários
avançados. Para decodificar fluxos brutos, você precisa usar --format=raw e especificar explicita‐
mente a cadeia de filtros, que normalmente seria armazenada nos cabeçalhos do contêiner.
-C verificação, --check=verificação
Especifica o tipo de verificação de integridade. A verificação é calculada a partir dos dados descompacta‐
dos e armazenados no arquivo .xz. Esta opção tem efeito somente ao compactar no formato .xz; o formato
.lzma não oferece suporte a verificações de integridade. A verificação de integridade (se for o caso) é
verificada quando o arquivo .xz é descompactado.
Tipos de verificação suportados:
none Não calcula uma verificação de integridade. Isso geralmente é uma má ideia. Pode ser útil quando a
integridade dos dados é verificada por outros meios.
crc32 Calcula CRC32 usando o polinômio do IEEE-802.3 (Ethernet).
crc64 Calcula CRC64 usando o polinômio de ECMA-182. Este é o padrão, pois é um pouco melhor que o CRC32
na detecção de arquivos danificados e a diferença de velocidade é insignificante.
sha256 Calcula SHA-256. Isso é um pouco mais lento do que CRC32 e CRC64.
A integridade dos cabeçalhos de .xz é sempre verificada com CRC32. Não é possível alterá-la ou de‐
sativá-la.
--ignore-check
Não confere a verificação de integridade dos dados compactados ao descompactar. Os valores CRC32 nos
cabeçalhos .xz ainda serão conferidos normalmente.
Não use esta opção a menos que saiba o que está fazendo. Possíveis razões para usar esta opção:
• Tentativa de recuperar dados de um arquivo .xz corrompido.
• Acelerar a descompactação. Isso é importante principalmente com SHA-256 ou com arquivos extremamente
bem compactados. É recomendável não usar essa opção para essa finalidade, 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, especi‐
ficar 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 con‐
figuraçõ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 cegamente -9 para tudo como costuma acontecer com
gzip(1) e bzip2(1).
-0 ... -3
Estas são predefinições um tanto rápidas. -0 às vezes é mais rápida que gzip -9 ao mesmo tempo que
compacta muito melhor. As mais altas 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
Compactação boa a muito boa, mantendo o uso de memória do descompactador razoável mesmo para sis‐
temas antigos. -6 é o padrão, que geralmente é uma boa escolha para distribuir arquivos que pre‐
cisam ser descompactáveis, mesmo em sistemas com apenas 16 MiB de RAM. (-5e ou -6e também vale a
pena considerar. Veja --extreme.)
-7 ... -9
Eles são como -6, mas com requisitos de memória de compressor e descompressor mais altos. Eles 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 descom‐
pactação. Isso também significa que a quantidade de saída não compactada produzida por segundo pode variar
muito.
A tabela a seguir resume os recursos das predefinições:
Predefinição DicTam 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ções das colunas:
• DicTam é o tamanho do dicionário LZMA2. É desperdício de memória usar um dicionário maior que o tamanho
do arquivo descompactado. É por isso que é bom evitar usar as predefinições -7 ... -9 quando não há
real necessidade deles. Em -6 e inferior, a quantidade de memória desperdiçada geralmente é baixa o su‐
ficiente para não importar.
• CompCPU é uma representação simplificada das configurações LZMA2 que afetam a velocidade de com‐
pactação. O tamanho do dicionário também afeta a velocidade, portanto, embora o CompCPU seja o mesmo
para os níveis -6 ... -9, níveis mais altos ainda tendem a ser um pouco mais lentos. Para obter uma
compactação ainda mais lenta e possivelmente melhor, consulte --extreme.
• CompMem contém os requisitos de memória do compactador no modo de thread única.Pode variar ligeiramente
entre as versões xz. Os requisitos de memória de alguns dos futuros modos de várias threads (multi‐
thread) podem ser dramaticamente maiores do que os do modo de thread única.
• DecMem contém os requisitos de memória do descompactador. Ou seja, as configurações de compactação de‐
terminam os requisitos de memória do descompactador. O uso exato da memória do descompactador é um
pouco maior do que o tamanho do dicionário LZMA2, mas os valores na tabela foram arredondados para o
próximo MiB completo.
-e, --extreme
Usa uma variante mais lenta do nível de predefinição de compactação selecionado (-0 ... -9) para obter uma
taxa de compactação um pouco melhor, mas, com azar, isso também pode piorar. O uso da memória do descom‐
pressor não é afetado, mas o uso da memória do compactador aumenta um pouco nos níveis de predefinição -0
... -3.
Como existem duas predefinições com tamanhos de dicionário 4 MiB e 8 MiB, as predefinições -3e e -5e usam
configurações um pouco mais rápidas (CompCPU inferior) do que -4e e -6e, respectivamente. Dessa forma, não
há duas predefinições idênticas.
Predefinição DicTam 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, há um total de quatro predefinições que usam o dicionário 8 MiB, cuja ordem do mais rápido ao
mais lento é -5, -6, -5e e -6e.
--fast
--best Esses são apelidos um tanto enganosos para -0 e -9, respectivamente. Eles são fornecidos apenas para com‐
patibilidade com versões anteriores do LZMA Utils. Evite usar essas opções.
--block-size=tamanho
Ao compactar para o formato .xz, divida os dados de entrada em blocos de tamanho bytes. Os blocos são com‐
pactados independentemente uns dos outros, o que ajuda no multi-threading e torna possível a descom‐
pactação limitada de acesso aleatório. Essa opção normalmente é usada para substituir o tamanho de bloco
padrão no modo multi-thread, mas também pode ser usada em thread única.
No modo multi-thread, cerca de três vezes tamanho bytes serão alocados em cada thread para armazenar em
buffer a entrada e a saída. O tamanho padrão é três vezes o tamanho do dicionário LZMA2 ou 1 MiB, o que
for maior. Normalmente, um bom valor é 2–4 vezes o tamanho do dicionário LZMA2 ou pelo menos 1 MiB. Usar
tamanho menor que o tamanho do dicionário LZMA2 é um desperdício de RAM porque o buffer do dicionário
LZMA2 nunca será totalmente usado. Os tamanhos dos blocos são armazenados nos cabeçalhos dos blocos, que
uma versão futura do xz usará para descompactação em multi-thread.
No modo de thread única, nenhuma divisão de bloco é feita por padrão. Definir essa opção não afeta o uso
da memória. Nenhuma informação de tamanho é armazenada nos cabeçalhos dos blocos, portanto, os arquivos
criados no modo de thread única não serão idênticos aos arquivos criados no modo multi-thread. A falta de
informações de tamanho também significa que uma versão futura do xz não poderá descompactar os arquivos no
modo multi-thread.
--block-list=tamanhos
Ao compactar para o formato .xz, inicia um novo bloco após os intervalos fornecidos de dados não compacta‐
dos.
Os tamanhos não compactados dos blocos são especificados como uma lista separada por vírgulas. Omitir um
tamanho (duas ou mais vírgulas consecutivas) é uma forma abreviada de usar o tamanho do bloco anterior.
Se o arquivo de entrada for maior que a soma de tamanhos, o último valor em tamanhos é repetido até o fi‐
nal do arquivo. Um valor especial de 0 pode ser usado como o último valor para indicar que o restante do
arquivo deve ser codificado como um único bloco.
Se alguém especificar tamanhos que excedam o tamanho do bloco do codificador (seja o valor padrão no modo
em threads ou o valor especificado com --block-size=tamanho), o codificador criará blocos adicionais en‐
quanto mantém o limites especificados em tamanhos. Por exemplo, se alguém especificar --block-size=10MiB
--block-list=5MiB,10MiB,8MiB,12MiB,24MiB e o arquivo de entrada for 80 MiB, obterá 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 de thread única, portanto, a saída codificada não será idêntica à do modo multi-thread.
--flush-timeout=tempo_limite
Ao compactar, se mais de tempo_limite milissegundos (um número inteiro positivo) se passaram desde a lib‐
eração anterior e a leitura de mais entrada seria bloqueada, todos os dados de entrada pendentes serão
liberados do codificador e disponibilizados no fluxo de saída. Isso pode ser útil se xz for usado para
compactar dados transmitidos por uma rede. Valores tempo_limite pequenos tornam os dados disponíveis na
extremidade receptora com um pequeno atraso, mas valores tempo_limite grandes oferecem melhor taxa de com‐
pactação.
Esse recurso está desabilitado por padrão. Se esta opção for especificada mais de uma vez, a última terá
efeito. O valor especial tempo_limite de 0 pode ser usado para desabilitar explicitamente esse recurso.
Este recurso não está disponível em sistemas não-POSIX.
Este recurso ainda é experimental. Atualmente, xz não é adequado para descompactar o fluxo em tempo real
devido à forma como xz faz o buffer.
--memlimit-compress=limite
Define um limite de uso de memória para compactação. Se esta opção for especificada várias vezes, a última
entrará em vigor.
Se as configurações de compactação excederem o limite, 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 encadeamentos, alternando para o modo sigle-thread se até
mesmo uma thread no modo multi-thread exceder o limite e, finalmente, reduzindo o tamanho do dicionário
LZMA2.
Ao compactar com --format=raw ou se --no-adjust tiver sido especificado, apenas o número de threads pode
ser reduzido, pois isso pode ser feito sem afetar a saída compactada.
Se o limite não puder ser alcançado mesmo com os ajustes descritos acima, um erro será exibido e xz sairá
com status 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 equivale a
definir limite como max (sem limite de uso de memória).
Para xz de 32 bits, há um caso especial: se o limite estiver acima de 4020 MiB, o limite é definido como
4020 MiB. No MIPS32 2000 MiB é usado em seu lugar. (Os valores 0 e max não são afetados por isso. Um re‐
curso semelhante não existe para descompactação.) Isso pode ser útil quando um executável de 32 bits tem
acesso a espaço de endereço de 4 GiB (2 GiB no MIPS32) enquanto espero não causar danos em outras
situações.
Consulte também a seção Uso de memória.
--memlimit-decompress=limite
Define um limite de uso de memória para descompactação. Isso também afeta o modo --list. Se a operação não
for possível sem exceder o limite, xz exibirá um erro e a descompactação do arquivo falhará. Consulte
--memlimit-compress=limite para possíveis maneiras de especificar o limite.
--memlimit-mt-decompress=limite
Define um limite de uso de memória para descompactação multi-thread. Isso pode afetar apenas o número de
threads; isso nunca fará com que xz se recuse a descompactar um arquivo. Se limite for muito baixo para
permitir qualquer multi-thread, o limite será ignorado e xz continuará no modo de thread única. Observe
que se --memlimit-decompress também for usado, ele sempre se aplicará aos modos de thread única 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
padrão limite 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 qualquer limite, o descompactador usando 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 para um valor
maior que a quantidade de RAM utilizável, pois com os arquivos de entrada apropriados xz tentará usar essa
quantidade de memória mesmo com um baixo número de threads. Ficar sem memória ou trocar não melhorará o
desempenho da descompactação.
Consulte --memlimit-compress=limite para possíveis maneiras de especificar o limite. Definir limite como 0
redefine limite para o valor padrão específico do sistema.
-M limite, --memlimit=limite, --memory=limite
Isso é equivalente a especificar --memlimit-compress=limite --memlimit-decompress=limite --memlimit-mt-de‐
compress=limite.
--no-adjust
Exibe um erro e saia 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 evita que xz alterne o codificador do modo multi-thread para o
modo encadeado único e 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 com‐
pactada.
O ajuste automático é sempre desativado ao criar fluxos 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 xz use tantos threads quanto o(s) processador(es) no suporte do sistema. O número real de encadea‐
mentos pode ser menor que threads se o arquivo de entrada não for grande o suficiente para subdividir em
threads com as configurações fornecidas ou se o uso de mais threads exceder o limite de uso de memória.
Os compactadores usando thread única e várias threads produzem saídas diferentes. O compactador de thread
única fornecerá o menor tamanho de arquivo, mas apenas a saída do compactador de várias threads pode ser
descompactada usando várias threads. Definir threads como 1 usará o modo de thread única. Definir threads
para qualquer outro valor, incluindo 0, usará o compressor de várias threads, mesmo que o sistema tenha
suporte a apenas uma thread de hardware. (xz 5.2.x usou o modo de thread única nesta situação.)
Para usar o modo de várias threads com apenas uma thread, defina threads como +1. O prefixo + não tem
efeito com valores diferentes de 1. Um limite de uso de memória ainda pode fazer xz alternar para o modo
de thread única, 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, um
limite flexível padrão específico do sistema será usado para possivelmente limitar o número de threads. É
um limite flexível no sentido de que é ignorado se o número de threads se tornar um, portanto, um limite
flexível nunca impedirá xz de compactar ou descompactar. Este limite flexível padrão não fará com que xz
alterne do modo de várias threads para o modo de thread única. Os limites ativos podem ser vistos com xz
--info-memory.
Atualmente, o único método de threading é dividir a entrada em blocos e comprimi-los independentemente um
do outro. O tamanho padrão do bloco depende do nível de compactação e pode ser substituído com a opção
--block-size=tamanho.
A descompactação em threads funciona apenas 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 de várias
thread atendem a essa condição, mas os arquivos compactados no modo de thread única não atendem, mesmo se
--block-size=tamanho tiver sido usado.
Cadeias de filtro de compressor personalizadas
Uma cadeia de filtro personalizada permite especificar as configurações de compactação em detalhes, em vez de
confiar nas configurações associadas às predefinições. Quando uma cadeia de filtro personalizada é especificada,
as opções predefinidas (-0 ... -9 e --extreme) anteriores na linha de comando são esquecidas. Se uma opção pre‐
definida for especificada após uma ou mais opções de cadeia de filtros personalizados, a nova predefinição en‐
trará em vigor e as opções de cadeia de filtros personalizados especificadas anteriormente serão esquecidas.
Uma cadeia de filtro é comparável à tubulação na linha de comando. Ao compactar, a entrada descompactada vai para
o primeiro filtro, cuja saída vai para o próximo filtro (se houver). A saída do último filtro é gravada no ar‐
quivo compactado. 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 podem funcionar apenas
como o último filtro na cadeia, alguns apenas como filtro não-último e alguns funcionam em qualquer posição na
cadeia. Dependendo do filtro, essa limitação é inerente ao projeto do filtro ou existe para evitar problemas de
segurança.
Uma cadeia de filtro personalizada é especificada usando uma ou mais opções de filtro na ordem desejada na cadeia
de filtro. Ou seja, a ordem das opções de filtro é significativa! Ao decodificar fluxos brutos (--format=raw), a
cadeia de filtros é especificada na mesma ordem em que foi especificada durante a compactação.
Os filtros usam opções específicas do filtro como uma lista separada por vírgulas. As vírgulas extras em opções
são ignoradas. Cada opção tem um valor padrão, portanto, você precisa especificar apenas aquelas que deseja al‐
terar.
Para ver toda a cadeia de filtros e opções, use xz -vv (isto é, use --verbose duas vezes). Isso também funciona
para visualizar as opções da cadeia de filtros usadas pelas predefinições.
--lzma1[=opções]
--lzma2[=opções]
Adiciona o filtro LZMA1 ou LZMA2 à cadeia de filtros. Esses filtros podem ser usados apenas como o último
filtro na cadeia.
LZMA1 é um filtro legado, que é suportado quase exclusivamente devido ao formato de arquivo legado .lzma,
que suporta apenas LZMA1. LZMA2 é uma versão atualizada do LZMA1 para corrigir alguns problemas práticos
do LZMA1. O formato .xz usa LZMA2 e não suporta LZMA1. A velocidade de compactação e as proporções 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 predefinição. Predefinição consiste em um número
inteiro, que pode ser seguido por modificadores de predefinição de uma única letra. O inteiro pode
ser 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 nenhum preset for especificado, 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
repetidos (correspondências) nos dados não compactados e substituí-los por referências aos dados
atualmente no dicionário. Quanto maior o dicionário, maior a chance de encontrar uma corre‐
spondência. Portanto, aumentar o dicionário tamanho geralmente melhora a taxa de compactação, mas
um dicionário maior que o arquivo não compactado é um desperdício de memória.
Um tamanho de dicionário típico é de 64 KiB a 64 MiB. O mínimo é 4 KiB. O máximo para compactação é
atualmente 1,5 GiB (1536 MiB). O descompactador já oferece suporte a dicionários de até um byte a
menos de 4 GiB, que é o máximo para os formatos de fluxo LZMA1 e LZMA2.
O tamanho de dicionário e o localizador de correspondência (mf) juntos determinam o uso de memória
do codificador LZMA1 ou LZMA2. O mesmo (ou maior) tamanho de dicionário é necessário para descom‐
pactar que foi usado durante a compactação, portanto, o uso de memória do decodificador é determi‐
nado pelo tamanho do dicionário usado durante a compactação. Os cabeçalhos .xz armazenam o tamanho
de dicionário como 2^n ou 2^n + 2^(n-1), então esses tamanhos são um tanto preferidos para com‐
pactação. Outros tamanhos serão arredondados quando armazenados nos cabeçalhos .xz.
lc=lc Especifica o número de bits de contexto literais. 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, literais são simplesmente bytes de 8 bits que são codificados um de cada vez.
A codificação literal assume que os bits lc mais altos do byte não compactado anterior se correla‐
cionam com o próximo byte. Por exemplo, em um texto típico em inglês, uma letra maiúscula geral‐
mente é 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 altos são 010 para letras maiúscu‐
las 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 compactação máxima, experimente lc=4. Às vezes
ajuda um pouco, às vezes piora a compactação. Se piorar, experimente lc=2 também.
lp=lp Especifica o número de bits de posição literal. O mínimo é 0 e o máximo é 4; o padrão é 0.
Lp afeta que tipo de alinhamento nos dados não compactados é assumido ao codificar literais. Con‐
sulte pb abaixo para obter mais informações sobre alinhamento.
pb=pb Especifica o número de bits de posição. O mínimo é 0 e o máximo é 4; o padrão é 2.
Pb afeta que tipo de alinhamento nos dados não compactados é 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á melhor es‐
timativa.
Quando o alinhamento é conhecido, definir pb adequadamente pode reduzir um pouco o tamanho do ar‐
quivo. Por exemplo, com arquivos de texto com alinhamento de um byte (US-ASCII, ISO-8859-*, UTF-8),
a configuração pb=0 pode melhorar um pouco a compactação. Para texto UTF-16, pb=1 é uma boa es‐
colha. 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 em consideração ao projetar for‐
matos de arquivo que provavelmente serão compactados com LZMA1 ou LZMA2.
mf=mf O localizador de correspondência tem um efeito importante na velocidade do codificador, uso de
memória e taxa de compactação. Normalmente, os localizadores de correspondência de Hash Chain são
mais rápidos do que os localizadores de correspondência de árvore binária. O padrão depende do pre‐
definição: 0 usa hc3, 1–3 usa hc4 e o resto usa bt4.
Os seguintes localizadores de correspondência são suportados. As fórmulas de uso de memória abaixo
são aproximações aproximadas, que estão mais próximas da realidade quando dict é uma potência de
dois.
hc3 Cadeia de hashs com hashing de 2 e 3 bytes
Valor mínimo para nice: 3
Uso de memória:
dict * 7.5 (if dict <= 16 MiB);
dict * 5.5 + 64 MiB (if dict > 16 MiB)
hc4 Cadeia de hashs com hashing de 2, 3 e 4 bytes
Valor mínimo para nice: 4
Uso de memória:
dict * 7.5 (if dict <= 32 MiB);
dict * 6.5 (if 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 (if dict <= 16 MiB);
dict * 9.5 + 64 MiB (if 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 (if dict <= 32 MiB);
dict * 10.5 (if dict > 32 MiB)
mode=modo
O modo de compactação especifica o método para analisar os dados produzidos pelo localizador de
correspondência. Os modos suportados são fast e normal. O padrão é fast para predefinições 0–3 e
normal para predefinições 4–9.
Normalmente, fast é usado com localizadores de correspondência cadeia de hashs e normal com local‐
izadores de correspondência de árvore binária. Isso também é o que os predefinições fazem.
nice=nice
Especifica o que é considerado um bom comprimento para uma correspondência. Uma vez que uma corre‐
spondência de pelo menos nice bytes é encontrada, o algoritmo para de procurar correspondências
possivelmente melhores.
Nice pode ser 2–273 bytes. Valores mais altos tendem a fornecer melhor taxa de compactação em
detrimento da velocidade. O padrão depende do predefinição.
depth=profundidade
Especifica 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 um profundidade razoável de mf e nice.
Uma profundidade razoável para cadeias de hash é 4–100 e 16–1000 para árvores binárias. Usar val‐
ores muito altos para profundidade pode tornar o codificador extremamente lento com alguns ar‐
quivos. Evite definir profundidade acima de 1000 a menos que você esteja preparado para interromper
a compactação caso ela esteja demorando muito.
Ao decodificar fluxos brutos (--format=raw), o LZMA2 precisa apenas do dicionário tamanho. LZMA1 também
precisa de lc, lp e pb.
--x86[=opções]
--arm[=opções]
--armthumb[=opções]
--arm64[=opções]
--powerpc[=opções]
--ia64[=opções]
--sparc[=opções]
Adiciona um filtro de ramificação/chamada/salto (BCJ) à cadeia de filtros. Esses filtros podem ser usados
apenas como um filtro não último na cadeia de filtros.
Um filtro BCJ converte endereços relativos no código de máquina em suas contrapartes absolutas. Isso não
altera o tamanho dos dados, mas aumenta a redundância, o que pode ajudar o LZMA2 a produzir um arquivo .xz
0–15 % menor. Os filtros BCJ são sempre reversíveis, portanto, usar um filtro BCJ para o tipo errado de
dados não causa nenhuma perda de dados, embora possa piorar um pouco a taxa de compactação.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 compactação:
• Alguns tipos de arquivos contendo código executável (por exemplo, arquivos de objeto, bibliotecas
estáticas e módulos do kernel do Linux) têm os endereços nas instruções preenchidos com valores de
preenchimento. Esses filtros BCJ ainda vão fazer a conversão de endereço, o que vai piorar a com‐
pactação desses arquivos.
• Se um filtro BCJ for aplicado em um arquivo, é possível que isso torne a taxa de compactação pior do
que não usar um filtro BCJ. Por exemplo, se houver executáveis semelhantes ou mesmo idênticos, a fil‐
tragem provavelmente tornará os arquivos menos semelhantes e, portanto, a compactação será pior. O
conteúdo de arquivos não executáveis no mesmo arquivo também pode ser importante. Na prática tem que
tentar com e sem filtro BCJ para ver qual é melhor em cada situação.
Conjuntos de instruções diferentes têm alinhamento diferente: o arquivo executável deve ser alinhado a um
múltiplo desse valor nos dados de entrada para fazer o filtro funcionar.
Filtro Alinhamento Observações
x86 1 x86 32 bits ou 64 bits
ARM 4
ARM-Thumb 2
ARM64 4 Alinhamento de 4096 bytes
é melhor
PowerPC 4 Somente big endian
IA-64 16 Itanium
SPARC 4
Como os dados filtrados por BCJ geralmente são compactados com LZMA2, a taxa de compactação pode melhorar
ligeiramente se as opções de LZMA2 forem definidas para corresponder ao alinhamento do filtro BCJ sele‐
cionado. Por exemplo, com o filtro IA-64, é bom definir pb=4 ou mesmo pb=4,lp=4,lc=0 com LZMA2 (2^4=16). O
filtro x86 é uma exceção; geralmente é bom manter o alinhamento padrão de quatro bytes do LZMA2 ao com‐
pactar executáveis x86.
Todos os filtros BCJ suportam as mesmas opções:
start=deslocamento
Especifica o deslocamento inicial que é usado na conversão entre endereços relativos e absolutos. O
deslocamento deve ser um múltiplo do alinhamento do filtro (ver tabela acima). O padrão é zero. Na
prática, o padrão é bom; especificar um deslocamento personalizado quase nunca é útil.
--delta[=opções]
Adiciona o filtro Delta à cadeia de filtros. O filtro Delta só pode ser usado como filtro não-último na
cadeia de filtros.
Atualmente, apenas o cálculo simples de delta byte a byte é suportado. Pode ser útil ao compactar, por ex‐
emplo, imagens bitmap não compactadas ou áudio PCM não compactado. No entanto, algoritmos de propósito es‐
pecial podem fornecer resultados significativamente melhores do que Delta + LZMA2. Isso é verdade espe‐
cialmente com áudio, que compacta mais rápido e melhor, por exemplo, com flac(1).
Opções suportadas:
dist=distância
Especifica a distância do cálculo delta em bytes. distância deve ser 1–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 avisos. Especifique isso 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
Ser detalhado. Se o erro padrão estiver conectado a um terminal, xz exibirá um indicador de progresso. Es‐
pecifique --verbose duas vezes dará uma saída ainda mais 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 por‐
centagem não pode ser mostrada em encadeamentos (pipe).
• Quantidade de dados compactados produzidos (compactando) ou consumidos (descompactando).
• Quantidade de dados não compactados consumidos (compactação) ou produzidos (descompactação).
• Taxa de compactação, que é calculada dividindo a quantidade de dados compactados processados até o mo‐
mento pela quantidade de dados não compactados processados até o momento.
• Velocidade de compactação ou descompactação. Isso é medido como a quantidade de dados não compactados
consumidos (compactação) ou produzidos (descompactação) por segundo. É mostrado após alguns segundos
desde que xz começou a processar o arquivo.
• Tempo decorrido no formato M:SS ou H:MM:SS.
• O tempo restante estimado é mostrado apenas quando o tamanho do arquivo de entrada é conhecido e alguns
segundos já se passaram desde que xz começou a processar o arquivo. A hora é mostrada em um formato
menos preciso que nunca tem dois pontos, por exemplo, 2 min 30 s.
Quando o erro padrão não é um terminal, --verbose fará com que xz imprima o nome do arquivo, tamanho com‐
pactado, tamanho não compactado, taxa de compactação e possivelmente também a velocidade e o tempo decor‐
rido em uma única linha para o erro padrão após a compactação ou descompactando o arquivo. A velocidade e
o tempo decorrido são incluídos apenas quando a operação leva pelo menos alguns segundos. Se a operação
não foi concluída, por exemplo, devido à interrupção do usuário, também é impressa a porcentagem de con‐
clusão se o tamanho do arquivo de entrada for conhecido.
-Q, --no-warn
Não define o status de saída como 2, mesmo que uma condição digna de um aviso tenha sido detectada. Esta
opção não afeta o nível de detalhamento, portanto, tanto --quiet quanto --no-warn devem ser usados para
não exibir avisos e não alterar o status de saída.
--robot
Imprime mensagens em um formato analisável por máquina. Isso visa facilitar a criação de frontends que de‐
sejam usar xz em vez de liblzma, o que pode ser o caso de vários scripts. A saída com esta opção habili‐
tada deve ser estável em versões xz. Consulte a seção MODO ROBÔ para obter detalhes.
--info-memory
Exibe, em formato legível por humanos, quanta memória física (RAM) e quantos threads de processador xz
acredita que o sistema possui e os limites de uso de memória para compactação e descompactação e saia com
êxito.
-h, --help
Exibe uma mensagem de ajuda descrevendo as opções mais usadas e sai com sucesso.
-H, --long-help
Exibe uma mensagem de ajuda descrevendo todos os recursos de xz e sai com sucesso
-V, --version
Exibe o número da versão de xz e liblzma em formato legível por humanos. Para obter uma saída analisável
por máquina, especifique --robot antes de --version.
MODO ROBÔ
O modo robô é ativado com a opção --robot. Isso torna a saída de xz mais fácil de ser analisada por outros pro‐
gramas. Atualmente --robot é suportado apenas junto com --version, --info-memory e --list. Ele terá suporte para
compactação e descompactação no futuro.
Versão
xz --robot --version prints the version number of xz and liblzma in the following format:
XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS
X Versão principal.
YYY Versão menor. Números pares são estáveis. Os 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 iguais 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.
Informações de limite de memória
xz --robot --info-memory prints a single line with multiple tab-separated columns:
1. Quantidade total de memória física (RAM) em bytes.
2. Limite de uso de memória para compactação em bytes (--memlimit-compress). Um valor especial de 0 indica a
configuração padrão que para o modo de thread única é o mesmo que sem limite.
3. Limite de uso de memória para descompactação em bytes (--memlimit-decompress). Um valor especial de 0 indica
a configuração padrão que para o modo de thread única é o mesmo que sem limite.
4. Desde xz 5.3.4alpha: Uso de memória para descompactação com várias thread em bytes (--memlimit-mt-decom‐
press). Isso nunca é zero porque um valor padrão específico do sistema mostrado na coluna 5 é usado se nenhum
limite for 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.
5. 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 compactar com um número automático de threads (--threads=0) e nenhum limite de uso de
memória foi especificado (--memlimit-compress). Isso também é usado como o valor padrão para --mem‐
limit-mt-decompress.
6. 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.
Modo lista
xz --robot --list usa saída separada por tabulações. A primeira coluna de cada linha possui uma string que indica
o tipo de informação encontrada naquela linha:
name Esta é sempre a primeira linha ao começar a listar um arquivo. A segunda coluna na linha é o nome do ar‐
quivo.
file Esta linha contém informações gerais sobre o arquivo .xz. Esta linha é sempre impressa após a linha name.
stream Este tipo de linha é usado somente quando --verbose foi especificado. Existem tantas linhas de stream
quanto fluxos no arquivo .xz.
block Este tipo de linha é usado somente quando --verbose foi especificado. Existem tantas linhas block quanto
blocos no arquivo .xz. As linhas block são mostradas após todas as linhas 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 block. Assim como a linha arquivo, a linha summary contém informações gerais sobre o
arquivo .xz.
totals Esta linha é sempre a última linha da saída da lista. Ele mostra as contagens totais e tamanhos.
As colunas das linhas file:
2. Número de fluxos no arquivo
3. Número total de blocos no(s) fluxo(s)
4. Tamanho compactado do arquivo
5. Uncompressed size of the file
6. Taxa de compactação, por exemplo, 0.123. Se a proporção for superior a 9.999, serão exibidos três
traços (---) em vez da proporção.
7. Lista separada por vírgulas de nomes de verificação de integridade. As seguintes strings são usadas
para os tipos de verificação conhecidos: None, CRC32, CRC64 e SHA-256. Para tipos de verificações de‐
sconhecidos, Unknown-N é usado, onde N é o ID do cheque como um número decimal (um ou dois dígitos).
8. Tamanho total do preenchimento de fluxo no arquivo
As colunas das linhas stream:
2. Número do fluxo (o primeiro fluxo é 1)
3. Número de blocos no fluxo
4. Deslocamento inicial compactado
5. Deslocamento inicial descompactado
6. Tamanho compactado (não inclui preenchimento de fluxo)
7. Tamanho descompactado
8. Taxa de compactação
9. Nome da verificação de integridade
10. Tamanho do preenchimento do fluxo
As colunas das linhas block:
2. Número do fluxo que contém este bloco
3. Número do bloco relativo ao início do fluxo (o primeiro bloco é 1)
4. Número do bloco relativo ao início do arquivo
5. Deslocamento inicial compactado em relação ao início do arquivo
6. Deslocamento inicial descompactado em relação ao início do arquivo
7. Tamanho total compactado do bloco (inclui cabeçalhos)
8. Tamanho descompactado
9. Taxa de compactação
10. Nome da verificação de integridade
Se --verbose for especificado duas vezes, colunas adicionais serão incluídas nas linhas block. Eles não são ex‐
ibidos com um único --verbose, porque obter essas informações requer muitas buscas e, portanto, pode ser lento:
11. Valor da verificação de integridade em hexadecimal
12. Tamanho do cabeçalho do bloco
13. Sinalizadores de bloco: c indica que o tamanho compactado está presente e u indica que o tamanho não
compactado está presente. Se o sinalizador não estiver definido, um traço (-) será exibido para manter
o comprimento da string fixo. Novos sinalizadores podem ser adicionados ao final da string no futuro.
14. Tamanho dos dados reais compactados no bloco (isso exclui o cabeçalho do bloco, o preenchimento do
bloco e os campos de verificação)
15. Quantidade de memória (em bytes) necessária para descompactar este bloco com esta versão xz
16. Cadeia de filtro. Observe que a maioria das opções usadas no momento da compactação não pode ser con‐
hecida, pois apenas as opções necessárias para a descompactação são armazenadas nos cabeçalhos .xz.
As colunas das linhas summary:
2. Quantidade de memória (em bytes) necessária para descompactar este arquivo com esta versão do xz
3. yes ou no indicando se todos os cabeçalhos de bloco têm tamanho compactado e tamanho não compactado
armazenados neles
Desde xz 5.1.2alpha:
4. Versão mínima do xz necessária para descompactar o arquivo
As colunas da linha totals:
2. Número de fluxos
3. Número de blocos
4. Tamanho compactado
5. Tamanho descompactado
6. Taxa de compactação média
7. Lista separada por vírgulas de nomes de verificação de integridade que estavam presentes nos arquivos
8. Tamanho do preenchimento do fluxo
9. Número de arquivos. Isso está aqui para manter a ordem das colunas anteriores a mesma das linhas file.
Se --verbose for especificado duas vezes, colunas adicionais serão incluídas na linha totals:
10. Quantidade máxima de memória (em bytes) necessária para descompactar os arquivos com esta versão do xz
11. yes ou no indicando se todos os cabeçalhos de bloco têm tamanho compactado e tamanho não compactado
armazenados neles
Desde xz 5.1.2alpha:
12. 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 ex‐
istentes, mas as colunas existentes não serão alteradas.
STATUS DE SAÍDA
0 Está tudo bem.
1 Ocorreu um erro.
2 Algo digno de um aviso ocorreu, mas ocorreu nenhum erro real.
Observações (não avisos ou erros) impressas no erro padrão não afetam o status de saída.
AMBIENTE
xz analisa listas de opções separadas por espaços 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 as opções são analisadas a partir das
variáveis de ambiente; todas as não opções são silenciosamente ignoradas. A análise é feita com getopt_long(3)
que também é usado para os argumentos da linha de comando.
XZ_DEFAULTS
Opções padrão específicas do usuário ou de todo o 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. Excluindo scripts de
inicialização de shell e casos especiais semelhantes, os scripts nunca devem definir ou remover 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(1):
XZ_OPT=-2v tar caf foo.tar.xz foo
Os scripts podem usar XZ_OPT, por exemplo, para definir opções de compactação padrão específicas do
script. Ainda é 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 assim:
XZ_OPT=${XZ_OPT-"-7e"} export XZ_OPT
COMPATIBILIDADE COM LZMA UTILS
A sintaxe da linha de comando do xz é praticamente um superconjunto de lzma, unlzma e lzcat conforme encontrado
no LZMA Utils 4.32.x. Na maioria dos casos, é possível substituir LZMA Utils por XZ Utils sem interromper os
scripts existentes. Existem algumas incompatibilidades, porém, que às vezes podem causar problemas.
Níveis de predefinição de compactação
A numeração das predefinições de nível de compactação não é idêntica em xz e LZMA Utils. A diferença mais impor‐
tante é como os tamanhos dos dicionários são mapeados para diferentes predefinições. O tamanho do dicionário é
aproximadamente igual ao uso de memória do descompactador.
Nível xz LZMA Utils
-0 256 KiB N/D
-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 de tamanho do dicionário também afetam o uso da memória do compressor, mas existem algumas outras
diferenças entre LZMA Utils e XZ Utils, que tornam a diferença ainda maior:
Nível xz LZMA Utils 4.32.x
-0 3 MiB N/D
-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, então ambos usam um dicionário de 8
MiB por padrão.
Arquivos .lzma em um fluxo versus sem ser em um fluxo
O tamanho descompactado do arquivo pode ser armazenado no cabeçalho de .lzma. O LZMA Utils faz isso ao compactar
arquivos comuns. A alternativa é marcar que o tamanho não compactado é desconhecido e usar o marcador de fim de
carga útil para indicar onde o descompactador deve parar. O LZMA Utils usa este método quando o tamanho não com‐
pactado não é conhecido, como é o caso, por exemplo, de encadeamentos (pipes).
xz oferece suporte à descompactação de arquivos .lzma com ou sem marcador de fim de carga útil, mas todos os ar‐
quivos .lzma criados por xz usarão marcador de fim de carga útil e terão o tamanho descompactado marcado como de‐
sconhecido no cabeçalho de .lzma. Isso pode ser um problema em algumas situações incomuns. Por exemplo, um de‐
scompactador de .lzma em um dispositivo embarcado pode funcionar apenas com arquivos que tenham tamanho descom‐
pactado conhecido. Se você encontrar esse problema, precisará usar o LZMA Utils ou o LZMA SDK para criar arquivos
.lzma com tamanho descompactado conhecido.
Arquivos .lzma não suportados
O formato .lzma permite valores lc até 8 e valores lp até 4. LZMA Utils pode descompactar arquivos com qualquer
lc e lp, mas sempre cria arquivos com lc=3 e lp=0. Criar arquivos com outros lc e lp é possível com xz e com LZMA
SDK.
A implementação do filtro LZMA1 em liblzma requer que a soma de lc e lp não exceda 4. Assim, arquivos .lzma, que
excedam esta limitação, não podem ser descompactados com xz.
LZMA Utils cria apenas arquivos .lzma que possuem um tamanho de dicionário de 2^n (uma potência de 2), mas aceita
arquivos com qualquer tamanho de dicionário. liblzma aceita apenas arquivos .lzma que tenham um tamanho de di‐
cioná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, já que praticamente todos os arquivos .lzma foram com‐
pactados com configurações que o liblzma aceitará.
Lixo à direita
Ao descompactar, o LZMA Utils silenciosamente ignora tudo após o primeiro fluxo .lzma. Na maioria das situações,
isso é um bug. Isso também significa que o LZMA Utils não oferece suporte a descompactação de arquivos .lzma con‐
catenados.
Se houver dados restantes após o primeiro fluxo de .lzma, xz considera o arquivo corrompido, a menos que --sin‐
gle-stream tenha sido usado. Isso pode quebrar scripts obscuros que presumiram que o lixo à direita é ignorado.
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 se as opções de compactação forem idênticas. Isso ocorre porque o codificador pode ser
aprimorado (compactação mais rápida ou melhor) sem afetar o formato do arquivo. A saída pode variar mesmo entre
diferentes compilações da mesma versão do XZ Utils, se diferentes opções de compilação forem usadas.
A informaçã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 antigos e novos tenham sido compactados com a mesma
versão xz. Esse problema pode ser corrigido se uma parte da implementação do codificador for congelada para man‐
ter a saída de rsyncable estável nas versões do xz.
Descompactadores .xz embarcados
As implementações do descompactador .xz embarcados, como o XZ Embedded, não oferecem necessariamente suporte a
arquivos criados com tipos de verificações de integridade diferentes de none 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 oferecem suporte a todos os tipos de veri‐
ficaçã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 oferece suporte a filtros BCJ, mas apenas com o deslocamento inicial padrão.
EXEMPLOS
Básico
Compactar o arquivo foo em foo.xz usando o nível de compactação padrão (-6) e remover foo se a compactação for
bem-sucedida:
xz foo
Descompactar bar.xz em bar e não remover bar.xz mesmo se a descompactação for bem-sucedida:
xz -dk bar.xz
Criar baz.tar.xz com a predefinição -4e (-4 --extreme), que é mais lenta que o padrão -6, mas precisa de menos
memória para compactação e descompactação (48 MiB e 5 MiB, respectivamente):
tar cf - baz | xz -4e > baz.tar.xz
Uma mistura de arquivos compactados e descompactados pode ser descompactada para a saída padrão com um único co‐
mando:
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
Compactação paralela de muitos arquivos
No GNU e *BSD, find(1) e xargs(1) podem ser usados para paralelizar a compactaçã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 paralelos do xz. O melhor valor para a opção -n depende de
quantos arquivos devem ser compactados. Se houver apenas alguns arquivos, o valor provavelmente deve ser 1; com
dezenas de milhares de arquivos, 100 ou até mais podem ser apropriados para reduzir o número de processos de xz
que xargs(1) eventualmente criará.
A opção -T1 para xz existe para forçá-lo ao modo de thread única, porque xargs(1) é usado para controlar a quan‐
tidade de paralelização.
Modo robô
Calcular quantos bytes foram salvos no total depois de compactar vários arquivos:
xz --robot --list *.xz | awk '/^totals/{print $5-$4}'
Um script pode querer saber que está usando xz novo o suficiente. 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 suportavam
a opção --robot:
if ! eval "$(xz --robot --version 2> /dev/null)" || [ "$XZ_VERSION" -lt 50000002 ]; then echo "Your xz is too old." fi unset XZ_VERSION LIBLZMA_VERSION
Definir um limite de uso de memória para descompactação usando XZ_OPT, mas se um limite já tiver sido definido,
não o aumentar:
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 abrangem apenas um subconjunto das combinações potencialmente úteis de con‐
figurações de compactação.
As colunas CompCPU das tabelas das descrições das opções -0 ... -9 e --extreme são úteis ao personalizar as pre‐
definiçõ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 tanto grande (por exemplo, 32 MiB) para compactar bem, mas
deseja comprimi-lo mais rapidamente do que xz -8 faria, uma predefinição com um valor CompCPU baixo (por exemplo,
1) pode ser modificado para usar um dicionário maior:
xz --lzma2=preset=1,dict=32MiB foo.tar
Com certos arquivos, o comando acima pode ser mais rápido que xz -6 enquanto compacta significativamente melhor.
No entanto, deve-se enfatizar que apenas alguns arquivos se beneficiam de um grande dicionário, mantendo o valor
CompCPU baixo. A situação mais óbvia, onde um grande dicionário pode ajudar muito, é um arquivo contendo arquivos
muito semelhantes de pelo menos alguns megabytes cada. O tamanho do dicionário deve 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 muito alto de memória do compactador e do descompactador for bom e o arquivo que está sendo compactado
tiver pelo menos várias centenas de megabytes, pode ser útil usar um dicionário ainda maior do que os 64 MiB que
o 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 compacta‐
dor e do descompactador. Lembre-se que usar um dicionário maior que o tamanho do arquivo descompactado é des‐
perdício de memória, então o comando acima não é útil para arquivos pequenos.
Às vezes, o tempo de compactação não importa, mas o uso de memória do descompactador deve ser mantido baixo, por
exemplo, para possibilitar a descompactação do arquivo em um sistema embarcado. O comando a seguir usa -6e (-6
--extreme) como base e define o dicionário como apenas 64 KiB. O arquivo resultante pode ser descompactado com XZ
Embedded (é por isso que existe --check=crc32) usando cerca de 100 KiB de memória.
xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo
Se você deseja espremer 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 aju‐
dar, 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 (como 0,1 %) menor que xz -6e
(tente também sem lc=4):
xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar
O uso de outro filtro junto com o LZMA2 pode melhorar a compactação com determinados tipos de arquivo. Por exem‐
plo, 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 dará um
erro, porque não pode haver nenhum filtro após LZMA2 e também porque o filtro x86 BCJ não pode ser usado como o
último filtro em a corrente.
O filtro Delta junto com LZMA2 pode dar bons resultados com imagens bitmap. Ele geralmente deve superar o PNG,
que possui alguns filtros mais avançados do que o delta simples, mas usa 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,
bitmap RGB de 24 bits precisa de dist=3, e também é bom passar pb=0 para 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)
XZ Utils: <https://tukaani.org/xz/>
XZ Embedded: <https://tukaani.org/xz/embedded.html>
LZMA SDK: <https://7-zip.org/sdk.html>
Tukaani 2023-07-17 XZ(1)