Adding upstream version 5.6.1+really5.4.5.upstream/5.6.1+really5.4.5

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

7 files changed, 2157 insertions, 0 deletions

diff --git a/po4a/man/pt_BR/lzmainfo.1 b/po4a/man/pt_BR/lzmainfo.1
new file mode 100644
index 0000000..160a494
--- /dev/null
+++ b/po4a/man/pt_BR/lzmainfo.1
@@ -0,0 +1,43 @@
+.\"
+.\" Author: Lasse Collin
+.\"
+.\" This file has been put into the public domain.
+.\" You can do whatever you want with this file.
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH LZMAINFO 1 2013\-06\-30 Tukaani "XZ Utils"
+.SH NOME
+lzmainfo \- mostra informações armazenadas no cabeçalho do arquivo .lzma
+.SH SINOPSE
+\fBlzmainfo\fP [\fB\-\-help\fP] [\fB\-\-version\fP] [\fIarquivo...\fP]
+.SH DESCRIÇÃO
+\fBlzmainfo\fP mostra as informações armazenadas no cabeçalho do arquivo
+\&\fB.lzma\fP. Ele lê os primeiros 13 bytes do \fIarquivo\fP especificado,
+decodifica o cabeçalho e o imprime na saída padrão em formato legível por
+humanos. Se nenhum \fIarquivo\fP for fornecido ou \fIarquivo\fP for \fB\-\fP, a
+entrada padrão será lida.
+.PP
+Normalmente, as informações mais interessantes são o tamanho descompactado e
+o tamanho do dicionário. O tamanho não compactado pode ser mostrado apenas
+se o arquivo estiver na variante de formato \fB.lzma\fP não transmitido. A
+quantidade de memória necessária para descompactar o arquivo é de algumas
+dezenas de kilobytes mais o tamanho do dicionário.
+.PP
+\fBlzmainfo\fP está incluído no XZ Utils principalmente para compatibilidade
+com versões anteriores do LZMA Utils.
+.SH "STATUS DE SAÍDA"
+.TP 
+\fB0\fP
+Está tudo bem.
+.TP 
+\fB1\fP
+Ocorreu um erro.
+.SH BUGS
+\fBlzmainfo\fP usa \fBMB\fP enquanto o sufixo correto seria \fBMiB\fP (2^20
+bytes). Isso é para manter a saída compatível com LZMA Utils.
+.SH "VEJA TAMBÉM"
+\fBxz\fP(1)
diff --git a/po4a/man/pt_BR/xz.1 b/po4a/man/pt_BR/xz.1
new file mode 100644
index 0000000..d8ccb2f
--- /dev/null
+++ b/po4a/man/pt_BR/xz.1
@@ -0,0 +1,1837 @@
+'\" t
+.\"
+.\" Authors: Lasse Collin
+.\"          Jia Tan
+.\"
+.\" This file has been put into the public domain.
+.\" You can do whatever you want with this file.
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH XZ 1 2023\-07\-17 Tukaani "XZ Utils"
+.
+.SH NOME
+xz, unxz, xzcat, lzma, unlzma, lzcat \- Compacta ou descompacta arquivos .xz
+e .lzma
+.
+.SH SINOPSE
+\fBxz\fP [\fIopção...\fP] [\fIarquivo...\fP]
+.
+.SH "COMANDOS APELIDOS"
+\fBunxz\fP é equivalente a  \fBxz \-\-decompress\fP.
+.br
+\fBxzcat\fP é equivalente a  \fBxz \-\-decompress \-\-stdout\fP.
+.br
+\fBlzma\fP é equivalente a  \fBxz \-\-format=lzma\fP.
+.br
+\fBunlzma\fP é equivalente a  \fBxz \-\-format=lzma \-\-decompress\fP.
+.br
+\fBlzcat\fP é equivalente a  \fBxz \-\-format=lzma \-\-decompress \-\-stdout\fP.
+.PP
+Ao escrever scripts que precisam descompactar arquivos, é recomendável
+sempre usar o nome \fBxz\fP com os argumentos apropriados (\fBxz \-d\fP ou \fBxz \-dc\fP) em vez dos nomes \fBunxz\fP e \fBxzcat\fP.
+.
+.SH DESCRIÇÃO
+\fBxz\fP é uma ferramenta de compactação de dados de uso geral com sintaxe de
+linha de comando semelhante ao \fBgzip\fP(1) e ao \fBbzip2\fP(1). O formato de
+arquivo nativo é o formato \fB.xz\fP, mas o formato legado \fB.lzma\fP 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 descompactação do formato
+\&\fB.lz\fP usado por \fBlzip\fP é suportada.
+.PP
+\fBxz\fP compacta ou descompacta cada \fIarquivo\fP de acordo com o modo de
+operação selecionado. Se nenhum \fIarquivo\fP for fornecido ou \fIarquivo\fP for
+\fB\-\fP, \fBxz\fP lê da entrada padrão e grava os dados processados na saída
+padrão. \fBxz\fP recusará (exibirá um erro e ignorará o \fIarquivo\fP) para gravar
+dados compactados na saída padrão se for um terminal. Da mesma forma, \fBxz\fP
+se recusará a ler dados compactados da entrada padrão se for um terminal.
+.PP
+A menos que \fB\-\-stdout\fP seja especificado, \fIarquivos\fP diferentes de \fB\-\fP
+são gravados em um novo arquivo cujo nome é derivado do nome \fIarquivo\fP de
+origem:
+.IP \(bu 3
+Ao compactar, o sufixo do formato de arquivo de destino (\fB.xz\fP ou \fB.lzma\fP)
+é anexado ao nome do arquivo de origem para obter o nome do arquivo de
+destino.
+.IP \(bu 3
+Ao descompactar, o sufixo \fB.xz\fP, \fB.lzma\fP ou \fB.lz\fP é removido do nome do
+arquivo para obter o nome do arquivo de destino. \fBxz\fP também reconhece os
+sufixos \fB.txz\fP e \fB.tlz\fP e os substitui pelo sufixo \fB.tar\fP.
+.PP
+Se o arquivo de destino já existir, um erro será exibido e \fIarquivo\fP será
+ignorado.
+.PP
+A menos que grave na saída padrão, \fBxz\fP exibirá um aviso e pulará o
+\fIarquivo\fP se qualquer um dos seguintes se aplicar:
+.IP \(bu 3
+\fIArquivo\fP não é um arquivo normal. Links simbólicos não são seguidos e,
+portanto, não são considerados arquivos comuns.
+.IP \(bu 3
+\fIArquivo\fP tem mais de um link físico.
+.IP \(bu 3
+\fIFile\fP tem setuid, setgid ou sticky bit definido.
+.IP \(bu 3
+O modo de operação está definido para compactar e o \fIarquivo\fP já possui um
+sufixo do formato de arquivo de destino (\fB.xz\fP ou \fB.txz\fP ao compactar para
+o formato \fB.xz\fP e \fB.lzma \fP ou \fB.tlz\fP ao compactar para o formato
+\&\fB.lzma\fP).
+.IP \(bu 3
+O modo de operação está definido para descompactar e o \fIarquivo\fP não possui
+um sufixo de nenhum dos formatos de arquivo suportados (\fB.xz\fP, \fB.txz\fP,
+\&\fB.lzma\fP, \fB.tlz\fP , ou \fB.lz\fP).
+.PP
+Depois de compactar ou descompactar com êxito o \fIarquivo\fP, o \fBxz\fP copia o
+dono, grupo, permissões, horário de acesso e horário de modificação do
+\fIarquivo\fP de origem para o arquivo de destino. Se a cópia do grupo falhar,
+as permissõ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 \fIarquivo\fP de
+origem. \fBxz\fP ainda não oferece suporte à cópia de outros metadados, como
+listas de controle de acesso ou atributos estendidos.
+.PP
+Depois que o arquivo de destino for fechado com êxito, o \fIarquivo\fP de
+origem será removido, a menos que \fB\-\-keep\fP tenha sido especificado. O
+\fIarquivo\fP de origem nunca é removido se a saída for gravada na saída padrão
+ou se ocorrer um erro.
+.PP
+O envio de \fBSIGINFO\fP ou \fBSIGUSR1\fP para o processo do \fBxz\fP 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 \fB\-\-verbose\fP exibirá um
+indicador de progresso de atualização automática.
+.
+.SS "Uso de memória"
+O uso de memória de \fBxz\fP 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
+descompactador. 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 \fBxz \-9\fP atualmente requer 65\ MiB de memória. Ainda assim, é possível ter arquivos \fB.xz\fP que requerem
+vários gigabytes de memória para descompactar.
+.PP
+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 \fBxz\fP 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 \fBulimit\fP(1) para
+limitar a memória virtual tende a prejudicar \fBmmap\fP(2)).
+.PP
+O limitador de uso de memória pode ser ativado com a opção de linha de
+comando \fB\-\-memlimit=\fP\fIlimite\fP. Geralmente é mais conveniente habilitar o
+limitador por padrão definindo a variável de ambiente \fBXZ_DEFAULTS\fP, por
+exemplo, \fBXZ_DEFAULTS=\-\-memlimit=150MiB\fP. É possível definir os limites
+separadamente para compactação e descompactação usando
+\fB\-\-memlimit\-compress=\fP\fIlimite\fP e \fB\-\-memlimit\-decompress=\fP\fIlimite\fP. Usar
+essas duas opções fora de \fBXZ_DEFAULTS\fP raramente é útil porque uma única
+execução de \fBxz\fP não pode fazer compactação e descompactação e
+\fB\-\-memlimit=\fP\fIlimite\fP (ou \fB\-M\fP \fIlimite\fP ) é mais curto para digitar na
+linha de comando.
+.PP
+Se o limite de uso de memória especificado for excedido durante a
+descompactação, \fBxz\fP exibirá um erro e a descompactação do arquivo
+falhará. Se o limite for excedido durante a compactação, \fBxz\fP tentará
+reduzir as configurações para que o limite não seja mais excedido (exceto ao
+usar \fB\-\-format=raw\fP ou \fB\-\-no\-adjust\fP). 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 correspondem à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 \fBxz \-9\fP, as configurações serão reduzidas apenas um pouco ,
+não até \fBxz \-8\fP.
+.
+.SS "Concatenação e preenchimento com arquivos .xz"
+É possível concatenar arquivos \fB.xz\fP como estão. \fBxz\fP irá descompactar
+tais arquivos como se fossem um único arquivo \fB.xz\fP.
+.PP
+É possível inserir preenchimento entre as partes concatenadas ou após a
+última parte. O preenchimento deve consistir em bytes nulos e o tamanho do
+preenchimento deve ser um múltiplo de quatro bytes. Isso pode ser útil, por
+exemplo, se o arquivo \fB.xz\fP for armazenado em uma mídia que mede tamanhos
+de arquivo em blocos de 512 bytes.
+.PP
+Concatenação e preenchimento não são permitidos com arquivos \fB.lzma\fP ou
+fluxos brutos.
+.
+.SH OPÇÕES
+.
+.SS "Sufixos inteiros e valores especiais"
+Na maioria dos lugares onde um argumento inteiro é esperado, um sufixo
+opcional é suportado para indicar facilmente números inteiros grandes. Não
+deve haver espaço entre o número inteiro e o sufixo.
+.TP 
+\fBKiB\fP
+Multiplica o inteiro por 1.024 (2^10). \fBKi\fP, \fBk\fP, \fBkB\fP, \fBK\fP e \fBKB\fP são
+aceitos como sinônimos de \fBKiB\fP.
+.TP 
+\fBMiB\fP
+Multiplica o número inteiro por 1.048.576 (2^20). \fBMi\fP, \fBm\fP, \fBM\fP e \fBMB\fP
+são aceitos como sinônimos de \fBMiB\fP.
+.TP 
+\fBGiB\fP
+Multiplica o número inteiro por 1.073.741.824 (2^30). \fBGi\fP, \fBg\fP, \fBG\fP e
+\fBGB\fP são aceitos como sinônimos de \fBGiB\fP.
+.PP
+O valor especial \fBmax\fP pode ser usado para indicar o valor inteiro máximo
+suportado pela opção.
+.
+.SS "Modo de operação"
+Se várias opções de modo de operação forem dadas, a última entrará em vigor.
+.TP 
+\fB\-z\fP, \fB\-\-compress\fP
+Compacta. Este é o modo de operação padrão quando nenhuma opção de modo de
+operação é especificada e nenhum outro modo de operação está implícito no
+nome do comando (por exemplo, \fBunxz\fP implica em \fB\-\-decompress\fP).
+.TP 
+\fB\-d\fP, \fB\-\-decompress\fP, \fB\-\-uncompress\fP
+Descompacta.
+.TP 
+\fB\-t\fP, \fB\-\-test\fP
+Testa a integridade de \fIarquivos\fP compactados. Esta opção é equivalente a
+\fB\-\-decompress \-\-stdout\fP exceto que os dados descompactados são descartados
+em vez de serem gravados na saída padrão. Nenhum arquivo é criado ou
+removido.
+.TP 
+\fB\-l\fP, \fB\-\-list\fP
+Imprime informações sobre \fIarquivos\fP 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.
+.IP ""
+A listagem padrão mostra informações básicas sobre \fIarquivos\fP, um arquivo
+por linha. Para obter informações mais detalhadas, use também a opção
+\fB\-\-verbose\fP. Para obter ainda mais informações, use \fB\-\-verbose\fP 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, \fBless\ \-S\fP
+pode ser conveniente se o terminal não tiver largura o suficiente.
+.IP ""
+A saída exata pode variar entre versões \fBxz\fP e localidades diferentes. Para
+saída legível por máquina, \fB\-\-robot \-\-list\fP deve ser usado.
+.
+.SS "Modificadores de operação"
+.TP 
+\fB\-k\fP, \fB\-\-keep\fP
+Não exclui os arquivos de entrada.
+.IP ""
+Desde \fBxz\fP 5.2.6, esta opção também faz \fBxz\fP 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 anteriores, isso era feito apenas com \fB\-\-force\fP.
+.TP 
+\fB\-f\fP, \fB\-\-force\fP
+Esta opção tem vários efeitos:
+.RS
+.IP \(bu 3
+Se o arquivo de destino já existir, o exclui antes de compactar ou
+descompactar.
+.IP \(bu 3
+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.
+.IP \(bu 3
+Quando usado com \fB\-\-decompress\fP \fB\-\-stdout\fP e \fBxz\fP 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 \fBxzcat\fP \fB\-\-force\fP seja usado como \fBcat\fP(1) para
+arquivos que não foram compactados com \fBxz\fP. Observe que, no futuro, o
+\fBxz\fP pode oferecer suporte a novos formatos de arquivo compactado, o que
+pode fazer com que o \fBxz\fP descompacte mais tipos de arquivos em vez de
+copiá\-los como na saída padrão. \fB\-\-format=\fP\fIformato\fP pode ser usado para
+restringir \fBxz\fP para descompactar apenas um único formato de arquivo.
+.RE
+.TP 
+\fB\-c\fP, \fB\-\-stdout\fP, \fB\-\-to\-stdout\fP
+Grava os dados compactados ou descompactados na saída padrão em vez de em um
+arquivo. Isso implica em \fB\-\-keep\fP.
+.TP 
+\fB\-\-single\-stream\fP
+Descompacta apenas o primeiro fluxo de \fB.xz\fP e ignora silenciosamente
+possíveis dados de entrada restantes após o fluxo. Normalmente, esse
+restante posterior sem uso faz com que \fBxz\fP exiba um erro.
+.IP ""
+\fBxz\fP nunca descompacta mais de um fluxo de arquivos \fB.lzma\fP ou fluxos
+brutos, mas esta opção ainda faz \fBxz\fP ignorar os possíveis dados
+posteriores após o arquivo \fB.lzma\fP ou fluxo bruto.
+.IP ""
+Esta opção não tem efeito se o modo de operação não for \fB\-\-decompress\fP ou
+\fB\-\-test\fP.
+.TP 
+\fB\-\-no\-sparse\fP
+Desativa a criação de arquivos esparsos. Por padrão, ao descompactar em um
+arquivo normal, \fBxz\fP 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.
+.TP 
+\fB\-S\fP \fI.suf\fP, \fB\-\-suffix=\fP\fI.suf\fP
+Ao compactar, usa \fI.suf\fP como sufixo para o arquivo de destino em vez de
+\&\fB.xz\fP ou \fB.lzma\fP. Se não estiver gravando na saída padrão e o arquivo de
+origem já tiver o sufixo \fI.suf\fP, um aviso será exibido e o arquivo será
+ignorado.
+.IP ""
+Ao descompactar, reconhece arquivos com o sufixo \fI.suf\fP além de arquivos
+com o sufixo \fB.xz\fP, \fB.txz\fP, \fB.lzma\fP, \fB.tlz\fP ou \fB.lz\fP . Se o arquivo de
+origem tiver o sufixo \fI.suf\fP, o sufixo será removido para obter o nome do
+arquivo de destino.
+.IP ""
+Ao compactar ou descompactar fluxos brutos (\fB\-\-format=raw\fP), 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.
+.TP 
+\fB\-\-files\fP[\fB=\fP\fIarquivo\fP]
+Lê os nomes dos arquivos a serem processados em \fIarquivo\fP; se \fIarquivo\fP
+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 (\fB\-\fP) é
+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
+\fIarquivo\fP.
+.TP 
+\fB\-\-files0\fP[\fB=\fP\fIarquivo\fP]
+Isso é idêntico a \fB\-\-files\fP[\fB=\fP\fIarquivo\fP], exceto que cada nome de
+arquivo deve ser finalizado com o caractere nulo.
+.
+.SS "Opções básicas de formato de arquivo e de compactação"
+.TP 
+\fB\-F\fP \fIformato\fP, \fB\-\-format=\fP\fIformato\fP
+Especifica o \fIformato\fP de arquivo para compactar ou descompactar:
+.RS
+.TP 
+\fBauto\fP
+Este é o padrão. Ao compactar, \fBauto\fP é equivalente a \fBxz\fP. Ao
+descompactar, o formato do arquivo de entrada é detectado
+automaticamente. Observe que os fluxos brutos (criados com \fB\-\-format=raw\fP)
+não podem ser detectados automaticamente.
+.TP 
+\fBxz\fP
+Compacta no formato de arquivo \fB.xz\fP ou aceite apenas arquivos \fB.xz\fP ao
+descompactar.
+.TP 
+\fBlzma\fP, \fBalone\fP
+Compacta no formato de arquivo legado \fB.lzma\fP ou aceite apenas arquivos
+\&\fB.lzma\fP ao descompactar. O nome alternativo \fBalone\fP é fornecido para
+compatibilidade com versões anteriores do LZMA Utils.
+.TP 
+\fBlzip\fP
+Aceita apenas arquivos \fB.lz\fP ao descompactar. Sem suporte a compactação.
+.IP ""
+O formato \fB.lz\fP versão 0 e a versão não estendida 1 são suportados. Os
+arquivos da versão 0 foram produzidos por \fBlzip\fP 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 \fBlzip\fP 1.18.
+.IP ""
+\fBlzip\fP 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 \fBlzip\fP 1.6. Esta extensão raramente é usada e não é suportada por \fBxz\fP
+(diagnosticada como entrada corrompida).
+.TP 
+\fBraw\fP
+Compacta ou descompacta um fluxo bruto (sem cabeçalhos). Isso é destinado
+apenas a usuários avançados. Para decodificar fluxos brutos, você precisa
+usar \fB\-\-format=raw\fP e especificar explicitamente a cadeia de filtros, que
+normalmente seria armazenada nos cabeçalhos do contêiner.
+.RE
+.TP 
+\fB\-C\fP \fIverificação\fP, \fB\-\-check=\fP\fIverificação\fP
+Especifica o tipo de verificação de integridade. A verificação é calculada a
+partir dos dados descompactados e armazenados no arquivo \fB.xz\fP. Esta opção
+tem efeito somente ao compactar no formato \fB.xz\fP; o formato \fB.lzma\fP não
+oferece suporte a verificações de integridade. A verificação de integridade
+(se for o caso) é verificada quando o arquivo \fB.xz\fP é descompactado.
+.IP ""
+Tipos de \fIverificação\fP suportados:
+.RS
+.TP 
+\fBnone\fP
+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.
+.TP 
+\fBcrc32\fP
+Calcula CRC32 usando o polinômio do IEEE\-802.3 (Ethernet).
+.TP 
+\fBcrc64\fP
+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.
+.TP 
+\fBsha256\fP
+Calcula SHA\-256. Isso é um pouco mais lento do que CRC32 e CRC64.
+.RE
+.IP ""
+A integridade dos cabeçalhos de \fB.xz\fP é sempre verificada com CRC32. Não é
+possível alterá\-la ou desativá\-la.
+.TP 
+\fB\-\-ignore\-check\fP
+Não confere a verificação de integridade dos dados compactados ao
+descompactar. Os valores CRC32 nos cabeçalhos \fB.xz\fP ainda serão conferidos
+normalmente.
+.IP ""
+\fBNão use esta opção a menos que saiba o que está fazendo.\fP Possíveis razões
+para usar esta opção:
+.RS
+.IP \(bu 3
+Tentativa de recuperar dados de um arquivo .xz corrompido.
+.IP \(bu 3
+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.
+.RE
+.TP 
+\fB\-0\fP ... \fB\-9\fP
+Seleciona um nível de predefinição de compactação. O padrão é \fB\-6\fP. Se
+vários níveis de predefinição forem especificados, o último terá efeito. Se
+uma cadeia de filtro personalizada já foi especificada, especificar um nível
+de predefinição de compactação limpa a cadeia de filtro personalizada.
+.IP ""
+As diferenças entre as predefinições são mais significativas do que com
+\fBgzip\fP(1) e \fBbzip2\fP(1). As configurações de compactação selecionadas
+determinam os requisitos de memória do descompactador, portanto, usar um
+nível de predefinição muito alto pode dificultar a descompactação do arquivo
+em um sistema antigo com pouca RAM. Especificamente, \fBnão é uma boa ideia usar cegamente \-9 para tudo\fP como costuma acontecer com \fBgzip\fP(1) e
+\fBbzip2\fP(1).
+.RS
+.TP 
+\fB\-0\fP ... \fB\-3\fP
+Estas são predefinições um tanto rápidas. \fB\-0\fP às vezes é mais rápida que
+\fBgzip \-9\fP ao mesmo tempo que compacta muito melhor. As mais altas
+geralmente têm velocidade comparável ao \fBbzip2\fP(1) com taxa de compactação
+comparável ou melhor, embora os resultados dependam muito do tipo de dados
+que estão sendo compactados.
+.TP 
+\fB\-4\fP ... \fB\-6\fP
+Compactação boa a muito boa, mantendo o uso de memória do descompactador
+razoável mesmo para sistemas antigos. \fB\-6\fP é o padrão, que geralmente é uma
+boa escolha para distribuir arquivos que precisam ser descompactáveis, mesmo
+em sistemas com apenas 16\ MiB de RAM. (\fB\-5e\fP ou \fB\-6e\fP também vale a pena
+considerar. Veja \fB\-\-extreme\fP.)
+.TP 
+\fB\-7 ... \-9\fP
+Eles são como \fB\-6\fP, 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.
+.RE
+.IP ""
+No mesmo hardware, a velocidade de descompactação é aproximadamente um
+número constante de bytes de dados compactados por segundo. Em outras
+palavras, quanto melhor a compactação, mais rápida será a
+descompactação. Isso também significa que a quantidade de saída não
+compactada produzida por segundo pode variar muito.
+.IP ""
+A tabela a seguir resume os recursos das predefinições:
+.RS
+.RS
+.PP
+.TS
+tab(;);
+c c c c c
+n n n n n.
+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
+.TE
+.RE
+.RE
+.IP ""
+Descrições das colunas:
+.RS
+.IP \(bu 3
+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 \fB\-7\fP ... \fB\-9\fP quando não há real
+necessidade deles. Em \fB\-6\fP e inferior, a quantidade de memória desperdiçada
+geralmente é baixa o suficiente para não importar.
+.IP \(bu 3
+CompCPU é uma representação simplificada das configurações LZMA2 que afetam
+a velocidade de compactação. O tamanho do dicionário também afeta a
+velocidade, portanto, embora o CompCPU seja o mesmo para os níveis \fB\-6\fP
+\&... \fB\-9\fP, níveis mais altos ainda tendem a ser um pouco mais lentos. Para
+obter uma compactação ainda mais lenta e possivelmente melhor, consulte
+\fB\-\-extreme\fP.
+.IP \(bu 3
+CompMem contém os requisitos de memória do compactador no modo de thread
+única.Pode variar ligeiramente entre as versões \fBxz\fP. Os requisitos de
+memória de alguns dos futuros modos de várias threads (multithread) podem
+ser dramaticamente maiores do que os do modo de thread única.
+.IP \(bu 3
+DecMem contém os requisitos de memória do descompactador. Ou seja, as
+configurações de compactação determinam 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.
+.RE
+.TP 
+\fB\-e\fP, \fB\-\-extreme\fP
+Usa uma variante mais lenta do nível de predefinição de compactação
+selecionado (\fB\-0\fP ... \fB\-9\fP) para obter uma taxa de compactação um pouco
+melhor, mas, com azar, isso também pode piorar. O uso da memória do
+descompressor não é afetado, mas o uso da memória do compactador aumenta um
+pouco nos níveis de predefinição \fB\-0\fP ... \fB\-3\fP.
+.IP ""
+Como existem duas predefinições com tamanhos de dicionário 4\ MiB e 8\ MiB,
+as predefinições \fB\-3e\fP e \fB\-5e\fP usam configurações um pouco mais rápidas
+(CompCPU inferior) do que \fB\-4e\fP e \fB\-6e\fP, respectivamente. Dessa forma, não
+há duas predefinições idênticas.
+.RS
+.RS
+.PP
+.TS
+tab(;);
+c c c c c
+n n n n n.
+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
+.TE
+.RE
+.RE
+.IP ""
+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 é \fB\-5\fP, \fB\-6\fP, \fB\-5e\fP e
+\fB\-6e\fP.
+.TP 
+\fB\-\-fast\fP
+.PD 0
+.TP 
+\fB\-\-best\fP
+.PD
+Esses são apelidos um tanto enganosos para \fB\-0\fP e \fB\-9\fP,
+respectivamente. Eles são fornecidos apenas para compatibilidade com versões
+anteriores do LZMA Utils. Evite usar essas opções.
+.TP 
+\fB\-\-block\-size=\fP\fItamanho\fP
+Ao compactar para o formato \fB.xz\fP, divida os dados de entrada em blocos de
+\fItamanho\fP bytes. Os blocos são compactados independentemente uns dos
+outros, o que ajuda no multi\-threading e torna possível a descompactaçã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.
+.IP ""
+No modo multi\-thread, cerca de três vezes \fItamanho\fP bytes serão alocados em
+cada thread para armazenar em buffer a entrada e a saída. O \fItamanho\fP
+padrão é três vezes o tamanho do dicionário LZMA2 ou 1 MiB, o que for
+maior. Normalmente, um bom valor é 2\(en4 vezes o tamanho do dicionário
+LZMA2 ou pelo menos 1 MiB. Usar \fItamanho\fP 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 \fBxz\fP usará para descompactação em
+multi\-thread.
+.IP ""
+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 \fBxz\fP não poderá descompactar os arquivos no modo
+multi\-thread.
+.TP 
+\fB\-\-block\-list=\fP\fItamanhos\fP
+Ao compactar para o formato \fB.xz\fP, inicia um novo bloco após os intervalos
+fornecidos de dados não compactados.
+.IP ""
+Os \fItamanhos\fP 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.
+.IP ""
+Se o arquivo de entrada for maior que a soma de \fItamanhos\fP, o último valor
+em \fItamanhos\fP é repetido até o final do arquivo. Um valor especial de \fB0\fP
+pode ser usado como o último valor para indicar que o restante do arquivo
+deve ser codificado como um único bloco.
+.IP ""
+Se alguém especificar \fItamanhos\fP que excedam o tamanho do bloco do
+codificador (seja o valor padrão no modo em threads ou o valor especificado
+com \fB\-\-block\-size=\fP\fItamanho\fP), o codificador criará blocos adicionais
+enquanto mantém o limites especificados em \fItamanhos\fP. Por exemplo, se
+alguém especificar \fB\-\-block\-size=10MiB\fP
+\fB\-\-block\-list=5MiB,10MiB,8MiB,12MiB,24MiB\fP e o arquivo de entrada for 80
+MiB, obterá 11 blocos: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 e 1 MiB.
+.IP ""
+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.
+.TP 
+\fB\-\-flush\-timeout=\fP\fItempo_limite\fP
+Ao compactar, se mais de \fItempo_limite\fP milissegundos (um número inteiro
+positivo) se passaram desde a liberaçã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
+\fBxz\fP for usado para compactar dados transmitidos por uma rede. Valores
+\fItempo_limite\fP pequenos tornam os dados disponíveis na extremidade
+receptora com um pequeno atraso, mas valores \fItempo_limite\fP grandes
+oferecem melhor taxa de compactação.
+.IP ""
+Esse recurso está desabilitado por padrão. Se esta opção for especificada
+mais de uma vez, a última terá efeito. O valor especial \fItempo_limite\fP de
+\fB0\fP pode ser usado para desabilitar explicitamente esse recurso.
+.IP ""
+Este recurso não está disponível em sistemas não\-POSIX.
+.IP ""
+.\" FIXME
+\fBEste recurso ainda é experimental.\fP Atualmente, \fBxz\fP não é adequado para
+descompactar o fluxo em tempo real devido à forma como \fBxz\fP faz o buffer.
+.TP 
+\fB\-\-memlimit\-compress=\fP\fIlimite\fP
+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.
+.IP ""
+Se as configurações de compactação excederem o \fIlimite\fP, \fBxz\fP 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
+\fIlimite\fP e, finalmente, reduzindo o tamanho do dicionário LZMA2.
+.IP ""
+Ao compactar com \fB\-\-format=raw\fP ou se \fB\-\-no\-adjust\fP tiver sido
+especificado, apenas o número de threads pode ser reduzido, pois isso pode
+ser feito sem afetar a saída compactada.
+.IP ""
+Se o \fIlimite\fP não puder ser alcançado mesmo com os ajustes descritos acima,
+um erro será exibido e \fBxz\fP sairá com status de saída 1.
+.IP ""
+O \fIlimite\fP pode ser especificado de várias maneiras:
+.RS
+.IP \(bu 3
+O \fIlimite\fP pode ser um valor absoluto em bytes. Usar um sufixo inteiro como
+\fBMiB\fP pode ser útil. Exemplo: \fB\-\-memlimit\-compress=80MiB\fP
+.IP \(bu 3
+O \fIlimite\fP 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 \fBXZ_DEFAULTS\fP 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:
+\fB\-\-memlimit\-compress=70%\fP
+.IP \(bu 3
+O \fIlimite\fP pode ser redefinido para seu valor padrão, definindo\-o como
+\fB0\fP. Atualmente, isso equivale a definir \fIlimite\fP como \fBmax\fP (sem limite
+de uso de memória).
+.RE
+.IP ""
+Para \fBxz\fP de 32 bits, há um caso especial: se o \fIlimite\fP estiver acima de
+\fB4020\ MiB\fP, o \fIlimite\fP é definido como \fB4020\ MiB\fP. No MIPS32 \fB2000\ MiB\fP é usado em seu lugar. (Os valores \fB0\fP e \fBmax\fP não são afetados por
+isso. Um recurso 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.
+.IP ""
+Consulte também a seção \fBUso de memória\fP.
+.TP 
+\fB\-\-memlimit\-decompress=\fP\fIlimite\fP
+Define um limite de uso de memória para descompactação. Isso também afeta o
+modo \fB\-\-list\fP. Se a operação não for possível sem exceder o \fIlimite\fP,
+\fBxz\fP exibirá um erro e a descompactação do arquivo falhará. Consulte
+\fB\-\-memlimit\-compress=\fP\fIlimite\fP para possíveis maneiras de especificar o
+\fIlimite\fP.
+.TP 
+\fB\-\-memlimit\-mt\-decompress=\fP\fIlimite\fP
+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 \fBxz\fP se
+recuse a descompactar um arquivo. Se \fIlimite\fP for muito baixo para permitir
+qualquer multi\-thread, o \fIlimite\fP será ignorado e \fBxz\fP continuará no modo
+de thread única. Observe que se \fB\-\-memlimit\-decompress\fP também for usado,
+ele sempre se aplicará aos modos de thread única e multi\-thread e, portanto,
+o \fIlimite\fP efetivo para multi\-threading nunca será maior que o limite
+definido com \fB\-\-memlimit\-decompress\fP.
+.IP ""
+Em contraste com as outras opções de limite de uso de memória,
+\fB\-\-memlimit\-mt\-decompress=\fP\fIlimite\fP tem um padrão \fIlimite\fP específico do
+sistema. \fBxz \-\-info\-memory\fP pode ser usado para ver o valor atual.
+.IP ""
+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 \fIlimite\fP padrão for muito
+baixo em seu sistema, sinta\-se à vontade para aumentar o \fIlimite\fP, mas
+nunca defina\-o para um valor maior que a quantidade de RAM utilizável, pois
+com os arquivos de entrada apropriados \fBxz\fP 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.
+.IP ""
+Consulte \fB\-\-memlimit\-compress=\fP\fIlimite\fP para possíveis maneiras de
+especificar o \fIlimite\fP. Definir \fIlimite\fP como \fB0\fP redefine \fIlimite\fP para
+o valor padrão específico do sistema.
+.TP 
+\fB\-M\fP \fIlimite\fP, \fB\-\-memlimit=\fP\fIlimite\fP, \fB\-\-memory=\fP\fIlimite\fP
+Isso é equivalente a especificar \fB\-\-memlimit\-compress=\fP\fIlimite\fP
+\fB\-\-memlimit\-decompress=\fP\fIlimite\fP \fB\-\-memlimit\-mt\-decompress=\fP\fIlimite\fP.
+.TP 
+\fB\-\-no\-adjust\fP
+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 \fBxz\fP 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 compactada.
+.IP ""
+O ajuste automático é sempre desativado ao criar fluxos brutos
+(\fB\-\-format=raw\fP).
+.TP 
+\fB\-T\fP \fIthreads\fP, \fB\-\-threads=\fP\fIthreads\fP
+Especifica o número de threads de trabalho a serem usados. Definir
+\fIthreads\fP para um valor especial \fB0\fP faz com que \fBxz\fP use tantos threads
+quanto o(s) processador(es) no suporte do sistema. O número real de
+encadeamentos pode ser menor que \fIthreads\fP 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.
+.IP ""
+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 \fIthreads\fP como \fB1\fP usará o
+modo de thread única. Definir \fIthreads\fP para qualquer outro valor,
+incluindo \fB0\fP, usará o compressor de várias threads, mesmo que o sistema
+tenha suporte a apenas uma thread de hardware. (\fBxz\fP 5.2.x usou o modo de
+thread única nesta situação.)
+.IP ""
+Para usar o modo de várias threads com apenas uma thread, defina \fIthreads\fP
+como \fB+1\fP. O prefixo \fB+\fP não tem efeito com valores diferentes de \fB1\fP. Um
+limite de uso de memória ainda pode fazer \fBxz\fP alternar para o modo de
+thread única, a menos que \fB\-\-no\-adjust\fP seja usado. O suporte para o
+prefixo \fB+\fP foi adicionado no \fBxz\fP 5.4.0.
+.IP ""
+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á \fBxz\fP de compactar ou
+descompactar. Este limite flexível padrão não fará com que \fBxz\fP alterne do
+modo de várias threads para o modo de thread única. Os limites ativos podem
+ser vistos com \fBxz \-\-info\-memory\fP.
+.IP ""
+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
+\fB\-\-block\-size=\fP\fItamanho\fP.
+.IP ""
+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 \fB\-\-block\-size=\fP\fItamanho\fP tiver sido usado.
+.
+.SS "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 (\fB\-0\fP \&...\& \fB\-9\fP e \fB\-\-extreme\fP) anteriores na linha
+de comando são esquecidas. Se uma opção predefinida for especificada após
+uma ou mais opções de cadeia de filtros personalizados, a nova predefinição
+entrará em vigor e as opções de cadeia de filtros personalizados
+especificadas anteriormente serão esquecidas.
+.PP
+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
+arquivo compactado. O número máximo de filtros na cadeia é quatro, mas
+normalmente uma cadeia de filtros tem apenas um ou dois filtros.
+.PP
+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.
+.PP
+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 (\fB\-\-format=raw\fP), a
+cadeia de filtros é especificada na mesma ordem em que foi especificada
+durante a compactação.
+.PP
+Os filtros usam \fIopções\fP específicas do filtro como uma lista separada por
+vírgulas. As vírgulas extras em \fIopções\fP são ignoradas. Cada opção tem um
+valor padrão, portanto, você precisa especificar apenas aquelas que deseja
+alterar.
+.PP
+Para ver toda a cadeia de filtros e \fIopções\fP, use \fBxz \-vv\fP (isto é, use
+\fB\-\-verbose\fP duas vezes). Isso também funciona para visualizar as opções da
+cadeia de filtros usadas pelas predefinições.
+.TP 
+\fB\-\-lzma1\fP[\fB=\fP\fIopções\fP]
+.PD 0
+.TP 
+\fB\-\-lzma2\fP[\fB=\fP\fIopções\fP]
+.PD
+Adiciona o filtro LZMA1 ou LZMA2 à cadeia de filtros. Esses filtros podem
+ser usados apenas como o último filtro na cadeia.
+.IP ""
+LZMA1 é um filtro legado, que é suportado quase exclusivamente devido ao
+formato de arquivo legado \fB.lzma\fP, que suporta apenas LZMA1. LZMA2 é uma
+versão atualizada do LZMA1 para corrigir alguns problemas práticos do
+LZMA1. O formato \fB.xz\fP 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.
+.IP ""
+LZMA1 e LZMA2 compartilham o mesmo conjunto de \fIopções\fP:
+.RS
+.TP 
+\fBpreset=\fP\fIpredefinição\fP
+Redefine todas as \fIopções\fP de LZMA1 ou LZMA2 para
+\fIpredefinição\fP. \fIPredefinição\fP consiste em um número inteiro, que pode ser
+seguido por modificadores de predefinição de uma única letra. O inteiro pode
+ser de \fB0\fP a \fB9\fP, correspondendo às opções de linha de comando \fB\-0\fP
+\&...\& \fB\-9\fP. O único modificador suportado atualmente é \fBe\fP, que
+corresponde a \fB\-\-extreme\fP. Se nenhum \fBpreset\fP for especificado, os valores
+padrão das \fIopções\fP LZMA1 ou LZMA2 serão obtidos da predefinição \fB6\fP.
+.TP 
+\fBdict=\fP\fItamanho\fP
+O \fItamanho\fP 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 correspondência. Portanto, aumentar o dicionário \fItamanho\fP
+geralmente melhora a taxa de compactação, mas um dicionário maior que o
+arquivo não compactado é um desperdício de memória.
+.IP ""
+Um \fItamanho\fP 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.
+.IP ""
+O \fItamanho\fP de dicionário e o localizador de correspondência (\fImf\fP) juntos
+determinam o uso de memória do codificador LZMA1 ou LZMA2. O mesmo (ou
+maior) \fItamanho\fP de dicionário é necessário para descompactar que foi usado
+durante a compactação, portanto, o uso de memória do decodificador é
+determinado pelo tamanho do dicionário usado durante a compactação. Os
+cabeçalhos \fB.xz\fP armazenam o \fItamanho\fP de dicionário como 2^\fIn\fP ou 2^\fIn\fP
++ 2^(\fIn\fP\-1), então esses \fItamanhos\fP são um tanto preferidos para
+compactação. Outros \fItamanhos\fP serão arredondados quando armazenados nos
+cabeçalhos \fB.xz\fP.
+.TP 
+\fBlc=\fP\fIlc\fP
+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 \fIlc\fP e \fIlp\fP não deve exceder 4.
+.IP ""
+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.
+.IP ""
+A codificação literal assume que os bits \fIlc\fP mais altos do byte não
+compactado anterior se correlacionam com o próximo byte. Por exemplo, em um
+texto típico em inglês, uma letra maiúscula geralmente é 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úsculas e 011 para letras minúsculas. Quando \fIlc\fP é pelo
+menos 3, a codificação literal pode aproveitar essa propriedade nos dados
+não compactados.
+.IP ""
+O valor padrão (3) geralmente é bom. Se você deseja compactação máxima,
+experimente \fBlc=4\fP. Às vezes ajuda um pouco, às vezes piora a
+compactação. Se piorar, experimente \fBlc=2\fP também.
+.TP 
+\fBlp=\fP\fIlp\fP
+Especifica o número de bits de posição literal. O mínimo é 0 e o máximo é 4;
+o padrão é 0.
+.IP ""
+\fILp\fP afeta que tipo de alinhamento nos dados não compactados é assumido ao
+codificar literais. Consulte \fIpb\fP abaixo para obter mais informações sobre
+alinhamento.
+.TP 
+\fBpb=\fP\fIpb\fP
+Especifica o número de bits de posição. O mínimo é 0 e o máximo é 4; o
+padrão é 2.
+.IP ""
+\fIPb\fP afeta que tipo de alinhamento nos dados não compactados é assumido em
+geral. O padrão significa alinhamento de quatro bytes (2^\fIpb\fP=2^2=4), que
+geralmente é uma boa escolha quando não há melhor estimativa.
+.IP ""
+Quando o alinhamento é conhecido, definir \fIpb\fP adequadamente pode reduzir
+um pouco o tamanho do arquivo. Por exemplo, com arquivos de texto com
+alinhamento de um byte (US\-ASCII, ISO\-8859\-*, UTF\-8), a configuração \fBpb=0\fP
+pode melhorar um pouco a compactação. Para texto UTF\-16, \fBpb=1\fP é uma boa
+escolha. Se o alinhamento for um número ímpar como 3 bytes, \fBpb=0\fP pode ser
+a melhor escolha.
+.IP ""
+Embora o alinhamento assumido possa ser ajustado com \fIpb\fP e \fIlp\fP, LZMA1 e
+LZMA2 ainda favorecem ligeiramente o alinhamento de 16 bytes. Pode valer a
+pena levar em consideração ao projetar formatos de arquivo que provavelmente
+serão compactados com LZMA1 ou LZMA2.
+.TP 
+\fBmf=\fP\fImf\fP
+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
+\fIpredefinição\fP: 0 usa \fBhc3\fP, 1\(en3 usa \fBhc4\fP e o resto usa \fBbt4\fP.
+.IP ""
+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 \fIdict\fP é uma potência de dois.
+.RS
+.TP 
+\fBhc3\fP
+Cadeia de hashs com hashing de 2 e 3 bytes
+.br
+Valor mínimo para \fInice\fP: 3
+.br
+Uso de memória:
+.br
+\fIdict\fP * 7.5 (if \fIdict\fP <= 16 MiB);
+.br
+\fIdict\fP * 5.5 + 64 MiB (if \fIdict\fP > 16 MiB)
+.TP 
+\fBhc4\fP
+Cadeia de hashs com hashing de 2, 3 e 4 bytes
+.br
+Valor mínimo para \fInice\fP: 4
+.br
+Uso de memória:
+.br
+\fIdict\fP * 7.5 (if \fIdict\fP <= 32 MiB);
+.br
+\fIdict\fP * 6.5 (if \fIdict\fP > 32 MiB)
+.TP 
+\fBbt2\fP
+Árvore binária com hashing de 2 bytes
+.br
+Valor mínimo para \fInice\fP: 2
+.br
+Uso de memória: \fIdict\fP * 9.5
+.TP 
+\fBbt3\fP
+Árvore binária com hashing de 2 e 3 bytes
+.br
+Valor mínimo para \fInice\fP: 3
+.br
+Uso de memória:
+.br
+\fIdict\fP * 11.5 (if \fIdict\fP <= 16 MiB);
+.br
+\fIdict\fP * 9.5 + 64 MiB (if \fIdict\fP > 16 MiB)
+.TP 
+\fBbt4\fP
+Árvore binária com hashing de 2, 3 e 4 bytes
+.br
+Valor mínimo para \fInice\fP: 4
+.br
+Uso de memória:
+.br
+\fIdict\fP * 11.5 (if \fIdict\fP <= 32 MiB);
+.br
+\fIdict\fP * 10.5 (if \fIdict\fP > 32 MiB)
+.RE
+.TP 
+\fBmode=\fP\fImodo\fP
+O \fImodo\fP de compactação especifica o método para analisar os dados
+produzidos pelo localizador de correspondência. Os \fImodos\fP suportados são
+\fBfast\fP e \fBnormal\fP. O padrão é \fBfast\fP para \fIpredefinições\fP 0\(en3 e
+\fBnormal\fP para \fIpredefinições\fP 4\(en9.
+.IP ""
+Normalmente, \fBfast\fP é usado com localizadores de correspondência cadeia de
+hashs e \fBnormal\fP com localizadores de correspondência de árvore
+binária. Isso também é o que os \fIpredefinições\fP fazem.
+.TP 
+\fBnice=\fP\fInice\fP
+Especifica o que é considerado um bom comprimento para uma
+correspondência. Uma vez que uma correspondência de pelo menos \fInice\fP bytes
+é encontrada, o algoritmo para de procurar correspondências possivelmente
+melhores.
+.IP ""
+\fINice\fP pode ser 2\(en273 bytes. Valores mais altos tendem a fornecer melhor
+taxa de compactação em detrimento da velocidade. O padrão depende do
+\fIpredefinição\fP.
+.TP 
+\fBdepth=\fP\fIprofundidade\fP
+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 \fIprofundidade\fP razoável de \fImf\fP e \fInice\fP.
+.IP ""
+Uma \fIprofundidade\fP razoável para cadeias de hash é 4\(en100 e 16\(en1000
+para árvores binárias. Usar valores muito altos para \fIprofundidade\fP pode
+tornar o codificador extremamente lento com alguns arquivos. Evite definir
+\fIprofundidade\fP acima de 1000 a menos que você esteja preparado para
+interromper a compactação caso ela esteja demorando muito.
+.RE
+.IP ""
+Ao decodificar fluxos brutos (\fB\-\-format=raw\fP), o LZMA2 precisa apenas do
+dicionário \fItamanho\fP. LZMA1 também precisa de \fIlc\fP, \fIlp\fP e \fIpb\fP.
+.TP 
+\fB\-\-x86\fP[\fB=\fP\fIopções\fP]
+.PD 0
+.TP 
+\fB\-\-arm\fP[\fB=\fP\fIopções\fP]
+.TP 
+\fB\-\-armthumb\fP[\fB=\fP\fIopções\fP]
+.TP 
+\fB\-\-arm64\fP[\fB=\fP\fIopções\fP]
+.TP 
+\fB\-\-powerpc\fP[\fB=\fP\fIopções\fP]
+.TP 
+\fB\-\-ia64\fP[\fB=\fP\fIopções\fP]
+.TP 
+\fB\-\-sparc\fP[\fB=\fP\fIopções\fP]
+.PD
+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.
+.IP ""
+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 \fB.xz\fP 0\(en15\ % 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.
+.IP ""
+Esses filtros BCJ têm problemas conhecidos relacionados à taxa de
+compactação:
+.RS
+.IP \(bu 3
+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
+compactação desses arquivos.
+.IP \(bu 3
+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 filtragem 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.
+.RE
+.IP ""
+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.
+.RS
+.RS
+.PP
+.TS
+tab(;);
+l n l
+l n l.
+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;
+.TE
+.RE
+.RE
+.IP ""
+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 selecionado. Por
+exemplo, com o filtro IA\-64, é bom definir \fBpb=4\fP ou mesmo
+\fBpb=4,lp=4,lc=0\fP com LZMA2 (2^4=16). O filtro x86 é uma exceção; geralmente
+é bom manter o alinhamento padrão de quatro bytes do LZMA2 ao compactar
+executáveis x86.
+.IP ""
+Todos os filtros BCJ suportam as mesmas \fIopções\fP:
+.RS
+.TP 
+\fBstart=\fP\fIdeslocamento\fP
+Especifica o \fIdeslocamento\fP inicial que é usado na conversão entre
+endereços relativos e absolutos. O \fIdeslocamento\fP 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 \fIdeslocamento\fP personalizado quase nunca é
+útil.
+.RE
+.TP 
+\fB\-\-delta\fP[\fB=\fP\fIopções\fP]
+Adiciona o filtro Delta à cadeia de filtros. O filtro Delta só pode ser
+usado como filtro não\-último na cadeia de filtros.
+.IP ""
+Atualmente, apenas o cálculo simples de delta byte a byte é suportado. Pode
+ser útil ao compactar, por exemplo, imagens bitmap não compactadas ou áudio
+PCM não compactado. No entanto, algoritmos de propósito especial podem
+fornecer resultados significativamente melhores do que Delta + LZMA2. Isso é
+verdade especialmente com áudio, que compacta mais rápido e melhor, por
+exemplo, com \fBflac\fP(1).
+.IP ""
+\fIOpções\fP suportadas:
+.RS
+.TP 
+\fBdist=\fP\fIdistância\fP
+Especifica a \fIdistância\fP do cálculo delta em bytes. \fIdistância\fP deve ser
+1\(en256. O padrão é 1.
+.IP ""
+Por exemplo, com \fBdist=2\fP 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.
+.RE
+.
+.SS "Outras opções"
+.TP 
+\fB\-q\fP, \fB\-\-quiet\fP
+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.
+.TP 
+\fB\-v\fP, \fB\-\-verbose\fP
+Ser detalhado. Se o erro padrão estiver conectado a um terminal, \fBxz\fP
+exibirá um indicador de progresso. Especifique \fB\-\-verbose\fP duas vezes dará
+uma saída ainda mais detalhada.
+.IP ""
+O indicador de progresso mostra as seguintes informações:
+.RS
+.IP \(bu 3
+A porcentagem de conclusão é mostrada se o tamanho do arquivo de entrada for
+conhecido. Ou seja, a porcentagem não pode ser mostrada em encadeamentos
+(pipe).
+.IP \(bu 3
+Quantidade de dados compactados produzidos (compactando) ou consumidos
+(descompactando).
+.IP \(bu 3
+Quantidade de dados não compactados consumidos (compactação) ou produzidos
+(descompactação).
+.IP \(bu 3
+Taxa de compactação, que é calculada dividindo a quantidade de dados
+compactados processados até o momento pela quantidade de dados não
+compactados processados até o momento.
+.IP \(bu 3
+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
+\fBxz\fP começou a processar o arquivo.
+.IP \(bu 3
+Tempo decorrido no formato M:SS ou H:MM:SS.
+.IP \(bu 3
+O tempo restante estimado é mostrado apenas quando o tamanho do arquivo de
+entrada é conhecido e alguns segundos já se passaram desde que \fBxz\fP 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.
+.RE
+.IP ""
+Quando o erro padrão não é um terminal, \fB\-\-verbose\fP fará com que \fBxz\fP
+imprima o nome do arquivo, tamanho compactado, tamanho não compactado, taxa
+de compactação e possivelmente também a velocidade e o tempo decorrido 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 conclusão se o tamanho do arquivo de entrada for conhecido.
+.TP 
+\fB\-Q\fP, \fB\-\-no\-warn\fP
+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 \fB\-\-quiet\fP quanto \fB\-\-no\-warn\fP devem ser usados para não
+exibir avisos e não alterar o status de saída.
+.TP 
+\fB\-\-robot\fP
+Imprime mensagens em um formato analisável por máquina. Isso visa facilitar
+a criação de frontends que desejam usar \fBxz\fP em vez de liblzma, o que pode
+ser o caso de vários scripts. A saída com esta opção habilitada deve ser
+estável em versões \fBxz\fP. Consulte a seção \fBMODO ROBÔ\fP para obter detalhes.
+.TP 
+\fB\-\-info\-memory\fP
+Exibe, em formato legível por humanos, quanta memória física (RAM) e quantos
+threads de processador \fBxz\fP acredita que o sistema possui e os limites de
+uso de memória para compactação e descompactação e saia com êxito.
+.TP 
+\fB\-h\fP, \fB\-\-help\fP
+Exibe uma mensagem de ajuda descrevendo as opções mais usadas e sai com
+sucesso.
+.TP 
+\fB\-H\fP, \fB\-\-long\-help\fP
+Exibe uma mensagem de ajuda descrevendo todos os recursos de \fBxz\fP e sai com
+sucesso
+.TP 
+\fB\-V\fP, \fB\-\-version\fP
+Exibe o número da versão de \fBxz\fP e liblzma em formato legível por
+humanos. Para obter uma saída analisável por máquina, especifique \fB\-\-robot\fP
+antes de \fB\-\-version\fP.
+.
+.SH "MODO ROBÔ"
+O modo robô é ativado com a opção \fB\-\-robot\fP. Isso torna a saída de \fBxz\fP
+mais fácil de ser analisada por outros programas. Atualmente \fB\-\-robot\fP é
+suportado apenas junto com \fB\-\-version\fP, \fB\-\-info\-memory\fP e \fB\-\-list\fP. Ele
+terá suporte para compactação e descompactação no futuro.
+.
+.SS Versão
+\fBxz \-\-robot \-\-version\fP prints the version number of \fBxz\fP and liblzma in
+the following format:
+.PP
+\fBXZ_VERSION=\fP\fIXYYYZZZS\fP
+.br
+\fBLIBLZMA_VERSION=\fP\fIXYYYZZZS\fP
+.TP 
+\fIX\fP
+Versão principal.
+.TP 
+\fIYYY\fP
+Versão menor. Números pares são estáveis. Os números ímpares são versões
+alfa ou beta.
+.TP 
+\fIZZZ\fP
+Nível de patch para versões estáveis ou apenas um contador para versões de
+desenvolvimento.
+.TP 
+\fIS\fP
+Estabilidade. 0 é alfa, 1 é beta e 2 é estável. \fIS\fP deve ser sempre 2
+quando \fIYYY\fP for par.
+.PP
+\fIXYYYZZZS\fP são iguais em ambas as linhas se \fBxz\fP e liblzma forem da mesma
+versão do XZ Utils.
+.PP
+Exemplos: 4.999.9beta é \fB49990091\fP e 5.0.0 é \fB50000002\fP.
+.
+.SS "Informações de limite de memória"
+\fBxz \-\-robot \-\-info\-memory\fP prints a single line with multiple tab\-separated
+columns:
+.IP 1. 4
+Quantidade total de memória física (RAM) em bytes.
+.IP 2. 4
+Limite de uso de memória para compactação em bytes
+(\fB\-\-memlimit\-compress\fP). Um valor especial de \fB0\fP indica a configuração
+padrão que para o modo de thread única é o mesmo que sem limite.
+.IP 3. 4
+Limite de uso de memória para descompactação em bytes
+(\fB\-\-memlimit\-decompress\fP). Um valor especial de \fB0\fP indica a configuração
+padrão que para o modo de thread única é o mesmo que sem limite.
+.IP 4. 4
+Desde \fBxz\fP 5.3.4alpha: Uso de memória para descompactação com várias thread
+em bytes (\fB\-\-memlimit\-mt\-decompress\fP). 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
+\fB\-\-memlimit\-mt\-decompress\fP.
+.IP 5. 4
+Desde \fBxz\fP 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 (\fB\-\-threads=0\fP) e nenhum limite de uso de
+memória foi especificado (\fB\-\-memlimit\-compress\fP). Isso também é usado como
+o valor padrão para \fB\-\-memlimit\-mt\-decompress\fP.
+.IP 6. 4
+Desde \fBxz\fP 5.3.4alpha: Número de threads de processador disponíveis.
+.PP
+No futuro, a saída de \fBxz \-\-robot \-\-info\-memory\fP pode ter mais colunas, mas
+nunca mais do que uma única linha.
+.
+.SS "Modo lista"
+\fBxz \-\-robot \-\-list\fP 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:
+.TP 
+\fBname\fP
+Esta é sempre a primeira linha ao começar a listar um arquivo. A segunda
+coluna na linha é o nome do arquivo.
+.TP 
+\fBfile\fP
+Esta linha contém informações gerais sobre o arquivo \fB.xz\fP. Esta linha é
+sempre impressa após a linha \fBname\fP.
+.TP 
+\fBstream\fP
+Este tipo de linha é usado somente quando \fB\-\-verbose\fP foi
+especificado. Existem tantas linhas de \fBstream\fP quanto fluxos no arquivo
+\&\fB.xz\fP.
+.TP 
+\fBblock\fP
+Este tipo de linha é usado somente quando \fB\-\-verbose\fP foi
+especificado. Existem tantas linhas \fBblock\fP quanto blocos no arquivo
+\&\fB.xz\fP. As linhas \fBblock\fP são mostradas após todas as linhas \fBstream\fP;
+diferentes tipos de linha não são intercalados.
+.TP 
+\fBsummary\fP
+Este tipo de linha é usado apenas quando \fB\-\-verbose\fP foi especificado duas
+vezes. Esta linha é impressa após todas as linhas de \fBblock\fP. Assim como a
+linha \fBarquivo\fP, a linha \fBsummary\fP contém informações gerais sobre o
+arquivo \fB.xz\fP.
+.TP 
+\fBtotals\fP
+Esta linha é sempre a última linha da saída da lista. Ele mostra as
+contagens totais e tamanhos.
+.PP
+As colunas das linhas \fBfile\fP:
+.PD 0
+.RS
+.IP 2. 4
+Número de fluxos no arquivo
+.IP 3. 4
+Número total de blocos no(s) fluxo(s)
+.IP 4. 4
+Tamanho compactado do arquivo
+.IP 5. 4
+Uncompressed size of the file
+.IP 6. 4
+Taxa de compactação, por exemplo, \fB0.123\fP. Se a proporção for superior a
+9.999, serão exibidos três traços (\fB\-\-\-\fP) em vez da proporção.
+.IP 7. 4
+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:
+\fBNone\fP, \fBCRC32\fP, \fBCRC64\fP e \fBSHA\-256\fP. Para tipos de verificações
+desconhecidos, \fBUnknown\-\fP\fIN\fP é usado, onde \fIN\fP é o ID do cheque como um
+número decimal (um ou dois dígitos).
+.IP 8. 4
+Tamanho total do preenchimento de fluxo no arquivo
+.RE
+.PD
+.PP
+As colunas das linhas \fBstream\fP:
+.PD 0
+.RS
+.IP 2. 4
+Número do fluxo (o primeiro fluxo é 1)
+.IP 3. 4
+Número de blocos no fluxo
+.IP 4. 4
+Deslocamento inicial compactado
+.IP 5. 4
+Deslocamento inicial descompactado
+.IP 6. 4
+Tamanho compactado (não inclui preenchimento de fluxo)
+.IP 7. 4
+Tamanho descompactado
+.IP 8. 4
+Taxa de compactação
+.IP 9. 4
+Nome da verificação de integridade
+.IP 10. 4
+Tamanho do preenchimento do fluxo
+.RE
+.PD
+.PP
+As colunas das linhas \fBblock\fP:
+.PD 0
+.RS
+.IP 2. 4
+Número do fluxo que contém este bloco
+.IP 3. 4
+Número do bloco relativo ao início do fluxo (o primeiro bloco é 1)
+.IP 4. 4
+Número do bloco relativo ao início do arquivo
+.IP 5. 4
+Deslocamento inicial compactado em relação ao início do arquivo
+.IP 6. 4
+Deslocamento inicial descompactado em relação ao início do arquivo
+.IP 7. 4
+Tamanho total compactado do bloco (inclui cabeçalhos)
+.IP 8. 4
+Tamanho descompactado
+.IP 9. 4
+Taxa de compactação
+.IP 10. 4
+Nome da verificação de integridade
+.RE
+.PD
+.PP
+Se \fB\-\-verbose\fP for especificado duas vezes, colunas adicionais serão
+incluídas nas linhas \fBblock\fP. Eles não são exibidos com um único
+\fB\-\-verbose\fP, porque obter essas informações requer muitas buscas e,
+portanto, pode ser lento:
+.PD 0
+.RS
+.IP 11. 4
+Valor da verificação de integridade em hexadecimal
+.IP 12. 4
+Tamanho do cabeçalho do bloco
+.IP 13. 4
+Sinalizadores de bloco: \fBc\fP indica que o tamanho compactado está presente e
+\fBu\fP indica que o tamanho não compactado está presente. Se o sinalizador não
+estiver definido, um traço (\fB\-\fP) será exibido para manter o comprimento da
+string fixo. Novos sinalizadores podem ser adicionados ao final da string no
+futuro.
+.IP 14. 4
+Tamanho dos dados reais compactados no bloco (isso exclui o cabeçalho do
+bloco, o preenchimento do bloco e os campos de verificação)
+.IP 15. 4
+Quantidade de memória (em bytes) necessária para descompactar este bloco com
+esta versão \fBxz\fP
+.IP 16. 4
+Cadeia de filtro. Observe que a maioria das opções usadas no momento da
+compactação não pode ser conhecida, pois apenas as opções necessárias para a
+descompactação são armazenadas nos cabeçalhos \fB.xz\fP.
+.RE
+.PD
+.PP
+As colunas das linhas \fBsummary\fP:
+.PD 0
+.RS
+.IP 2. 4
+Quantidade de memória (em bytes) necessária para descompactar este arquivo
+com esta versão do \fBxz\fP
+.IP 3. 4
+\fByes\fP ou \fBno\fP indicando se todos os cabeçalhos de bloco têm tamanho
+compactado e tamanho não compactado armazenados neles
+.PP
+\fIDesde\fP \fBxz\fP \fI5.1.2alpha:\fP
+.IP 4. 4
+Versão mínima do \fBxz\fP necessária para descompactar o arquivo
+.RE
+.PD
+.PP
+As colunas da linha \fBtotals\fP:
+.PD 0
+.RS
+.IP 2. 4
+Número de fluxos
+.IP 3. 4
+Número de blocos
+.IP 4. 4
+Tamanho compactado
+.IP 5. 4
+Tamanho descompactado
+.IP 6. 4
+Taxa de compactação média
+.IP 7. 4
+Lista separada por vírgulas de nomes de verificação de integridade que
+estavam presentes nos arquivos
+.IP 8. 4
+Tamanho do preenchimento do fluxo
+.IP 9. 4
+Número de arquivos. Isso está aqui para manter a ordem das colunas
+anteriores a mesma das linhas \fBfile\fP.
+.PD
+.RE
+.PP
+Se \fB\-\-verbose\fP for especificado duas vezes, colunas adicionais serão
+incluídas na linha \fBtotals\fP:
+.PD 0
+.RS
+.IP 10. 4
+Quantidade máxima de memória (em bytes) necessária para descompactar os
+arquivos com esta versão do \fBxz\fP
+.IP 11. 4
+\fByes\fP ou \fBno\fP indicando se todos os cabeçalhos de bloco têm tamanho
+compactado e tamanho não compactado armazenados neles
+.PP
+\fIDesde\fP \fBxz\fP \fI5.1.2alpha:\fP
+.IP 12. 4
+Versão mínima do \fBxz\fP necessária para descompactar o arquivo
+.RE
+.PD
+.PP
+Versões futuras podem adicionar novos tipos de linha e novas colunas podem
+ser adicionadas aos tipos de linha existentes, mas as colunas existentes não
+serão alteradas.
+.
+.SH "STATUS DE SAÍDA"
+.TP 
+\fB0\fP
+Está tudo bem.
+.TP 
+\fB1\fP
+Ocorreu um erro.
+.TP 
+\fB2\fP
+Algo digno de um aviso ocorreu, mas ocorreu nenhum erro real.
+.PP
+Observações (não avisos ou erros) impressas no erro padrão não afetam o
+status de saída.
+.
+.SH AMBIENTE
+\fBxz\fP analisa listas de opções separadas por espaços das variáveis de
+ambiente \fBXZ_DEFAULTS\fP e \fBXZ_OPT\fP, 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 \fBgetopt_long\fP(3) que também é usado para
+os argumentos da linha de comando.
+.TP 
+\fBXZ_DEFAULTS\fP
+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 \fBxz\fP 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 \fBXZ_DEFAULTS\fP.
+.TP 
+\fBXZ_OPT\fP
+Isso é para passar opções para \fBxz\fP quando não é possível definir as opções
+diretamente na linha de comando \fBxz\fP. Este é o caso quando \fBxz\fP é
+executado por um script ou ferramenta, por exemplo, GNU \fBtar\fP(1):
+.RS
+.RS
+.PP
+.nf
+\f(CWXZ_OPT=\-2v tar caf foo.tar.xz foo\fP
+.fi
+.RE
+.RE
+.IP ""
+Os scripts podem usar \fBXZ_OPT\fP, por exemplo, para definir opções de
+compactação padrão específicas do script. Ainda é recomendável permitir que
+os usuários substituam \fBXZ_OPT\fP se isso for razoável. Por exemplo, em
+scripts \fBsh\fP(1) pode\-se usar algo assim:
+.RS
+.RS
+.PP
+.nf
+\f(CWXZ_OPT=${XZ_OPT\-"\-7e"} export XZ_OPT\fP
+.fi
+.RE
+.RE
+.
+.SH "COMPATIBILIDADE COM LZMA UTILS"
+A sintaxe da linha de comando do \fBxz\fP é praticamente um superconjunto de
+\fBlzma\fP, \fBunlzma\fP e \fBlzcat\fP 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.
+.
+.SS "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
+\fBxz\fP e LZMA Utils. A diferença mais importante é 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.
+.RS
+.PP
+.TS
+tab(;);
+c c c
+c n n.
+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
+.TE
+.RE
+.PP
+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:
+.RS
+.PP
+.TS
+tab(;);
+c c c
+c n n.
+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
+.TE
+.RE
+.PP
+O nível de predefinição padrão no LZMA Utils é \fB\-7\fP enquanto no XZ Utils é
+\fB\-6\fP, então ambos usam um dicionário de 8 MiB por padrão.
+.
+.SS "Arquivos .lzma em um fluxo versus sem ser em um fluxo"
+O tamanho descompactado do arquivo pode ser armazenado no cabeçalho de
+\&\fB.lzma\fP. 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 compactado não é conhecido, como
+é o caso, por exemplo, de encadeamentos (pipes).
+.PP
+\fBxz\fP oferece suporte à descompactação de arquivos \fB.lzma\fP com ou sem
+marcador de fim de carga útil, mas todos os arquivos \fB.lzma\fP criados por
+\fBxz\fP usarão marcador de fim de carga útil e terão o tamanho descompactado
+marcado como desconhecido no cabeçalho de \fB.lzma\fP. Isso pode ser um
+problema em algumas situações incomuns. Por exemplo, um descompactador de
+\&\fB.lzma\fP em um dispositivo embarcado pode funcionar apenas com arquivos que
+tenham tamanho descompactado conhecido. Se você encontrar esse problema,
+precisará usar o LZMA Utils ou o LZMA SDK para criar arquivos \fB.lzma\fP com
+tamanho descompactado conhecido.
+.
+.SS "Arquivos .lzma não suportados"
+O formato \fB.lzma\fP permite valores \fIlc\fP até 8 e valores \fIlp\fP até 4. LZMA
+Utils pode descompactar arquivos com qualquer \fIlc\fP e \fIlp\fP, mas sempre cria
+arquivos com \fBlc=3\fP e \fBlp=0\fP. Criar arquivos com outros \fIlc\fP e \fIlp\fP é
+possível com \fBxz\fP e com LZMA SDK.
+.PP
+A implementação do filtro LZMA1 em liblzma requer que a soma de \fIlc\fP e
+\fIlp\fP não exceda 4. Assim, arquivos \fB.lzma\fP, que excedam esta limitação,
+não podem ser descompactados com \fBxz\fP.
+.PP
+LZMA Utils cria apenas arquivos \fB.lzma\fP que possuem um tamanho de
+dicionário de 2^\fIn\fP (uma potência de 2), mas aceita arquivos com qualquer
+tamanho de dicionário. liblzma aceita apenas arquivos \fB.lzma\fP que tenham um
+tamanho de dicionário de 2^\fIn\fP ou 2^\fIn\fP + 2^(\fIn\fP\-1). Isso é para diminuir
+os falsos positivos ao detectar arquivos \fB.lzma\fP.
+.PP
+Essas limitações não devem ser um problema na prática, já que praticamente
+todos os arquivos \fB.lzma\fP foram compactados com configurações que o liblzma
+aceitará.
+.
+.SS "Lixo à direita"
+Ao descompactar, o LZMA Utils silenciosamente ignora tudo após o primeiro
+fluxo \fB.lzma\fP. 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
+\&\fB.lzma\fP concatenados.
+.PP
+Se houver dados restantes após o primeiro fluxo de \fB.lzma\fP, \fBxz\fP considera
+o arquivo corrompido, a menos que \fB\-\-single\-stream\fP tenha sido usado. Isso
+pode quebrar scripts obscuros que presumiram que o lixo à direita é
+ignorado.
+.
+.SH NOTAS
+.
+.SS "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.
+.PP
+A informação acima significa que, uma vez que \fB\-\-rsyncable\fP 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 manter a saída de
+rsyncable estável nas versões do xz.
+.
+.SS "Descompactadores .xz embarcados"
+As implementações do descompactador \fB.xz\fP embarcados, como o XZ Embedded,
+não oferecem necessariamente suporte a arquivos criados com tipos de
+\fIverificações\fP de integridade diferentes de \fBnone\fP e \fBcrc32\fP. Como o
+padrão é \fB\-\-check=crc64\fP, você deve usar \fB\-\-check=none\fP ou
+\fB\-\-check=crc32\fP ao criar arquivos para sistemas embarcados.
+.PP
+Fora dos sistemas embarcados, todos os descompactadores de formato \fB.xz\fP
+oferecem suporte a todos os tipos de \fIverificação\fP ou, pelo menos, são
+capazes de descompactar o arquivo sem verificar a verificação de integridade
+se a \fIverificação\fP específica não for suportada.
+.PP
+XZ Embedded oferece suporte a filtros BCJ, mas apenas com o deslocamento
+inicial padrão.
+.
+.SH EXEMPLOS
+.
+.SS Básico
+Compactar o arquivo \fIfoo\fP em \fIfoo.xz\fP usando o nível de compactação padrão
+(\fB\-6\fP) e remover \fIfoo\fP se a compactação for bem\-sucedida:
+.RS
+.PP
+.nf
+\f(CWxz foo\fP
+.fi
+.RE
+.PP
+Descompactar \fIbar.xz\fP em \fIbar\fP e não remover \fIbar.xz\fP mesmo se a
+descompactação for bem\-sucedida:
+.RS
+.PP
+.nf
+\f(CWxz \-dk bar.xz\fP
+.fi
+.RE
+.PP
+Criar \fIbaz.tar.xz\fP com a predefinição \fB\-4e\fP (\fB\-4 \-\-extreme\fP), que é mais
+lenta que o padrão \fB\-6\fP, mas precisa de menos memória para compactação e
+descompactação (48 \ MiB e 5\ MiB, respectivamente):
+.RS
+.PP
+.nf
+\f(CWtar cf \- baz | xz \-4e > baz.tar.xz\fP
+.fi
+.RE
+.PP
+Uma mistura de arquivos compactados e descompactados pode ser descompactada
+para a saída padrão com um único comando:
+.RS
+.PP
+.nf
+\f(CWxz \-dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt\fP
+.fi
+.RE
+.
+.SS "Compactação paralela de muitos arquivos"
+No GNU e *BSD, \fBfind\fP(1) e \fBxargs\fP(1) podem ser usados para paralelizar a
+compactação de muitos arquivos:
+.RS
+.PP
+.nf
+\f(CWfind . \-type f \e! \-name '*.xz' \-print0 \e     | xargs \-0r \-P4 \-n16 xz \-T1\fP
+.fi
+.RE
+.PP
+A opção \fB\-P\fP para \fBxargs\fP(1) define o número de processos paralelos do
+\fBxz\fP. O melhor valor para a opção \fB\-n\fP 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 \fBxz\fP que \fBxargs\fP(1)
+eventualmente criará.
+.PP
+A opção \fB\-T1\fP para \fBxz\fP existe para forçá\-lo ao modo de thread única,
+porque \fBxargs\fP(1) é usado para controlar a quantidade de paralelização.
+.
+.SS "Modo robô"
+Calcular quantos bytes foram salvos no total depois de compactar vários
+arquivos:
+.RS
+.PP
+.nf
+\f(CWxz \-\-robot \-\-list *.xz | awk '/^totals/{print $5\-$4}'\fP
+.fi
+.RE
+.PP
+Um script pode querer saber que está usando \fBxz\fP novo o suficiente. O
+seguinte script \fBsh\fP(1) verifica se o número da versão da ferramenta \fBxz\fP
+é pelo menos 5.0.0. Este método é compatível com versões beta antigas, que
+não suportavam a opção \fB\-\-robot\fP:
+.RS
+.PP
+.nf
+\f(CWif ! eval "$(xz \-\-robot \-\-version 2> /dev/null)" ||         [ "$XZ_VERSION" \-lt 50000002 ]; then     echo "Your xz is too old." fi unset XZ_VERSION LIBLZMA_VERSION\fP
+.fi
+.RE
+.PP
+Definir um limite de uso de memória para descompactação usando \fBXZ_OPT\fP,
+mas se um limite já tiver sido definido, não o aumentar:
+.RS
+.PP
+.nf
+\f(CWNEWLIM=$((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\fP
+.fi
+.RE
+.
+.SS "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 configurações
+de compactação.
+.PP
+As colunas CompCPU das tabelas das descrições das opções \fB\-0\fP ... \fB\-9\fP e
+\fB\-\-extreme\fP são úteis ao personalizar as predefinições LZMA2. Aqui estão as
+partes relevantes coletadas dessas duas tabelas:
+.RS
+.PP
+.TS
+tab(;);
+c c
+n n.
+Predefinição;CompCPU
+\-0;0
+\-1;1
+\-2;2
+\-3;3
+\-4;4
+\-5;5
+\-6;6
+\-5e;7
+\-6e;8
+.TE
+.RE
+.PP
+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 \fBxz \-8\fP faria, uma predefinição com um valor CompCPU
+baixo (por exemplo, 1) pode ser modificado para usar um dicionário maior:
+.RS
+.PP
+.nf
+\f(CWxz \-\-lzma2=preset=1,dict=32MiB foo.tar\fP
+.fi
+.RE
+.PP
+Com certos arquivos, o comando acima pode ser mais rápido que \fBxz \-6\fP
+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.
+.PP
+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 \fBxz \-9\fP usaria:
+.RS
+.PP
+.nf
+\f(CWxz \-vv \-\-lzma2=dict=192MiB big_foo.tar\fP
+.fi
+.RE
+.PP
+Usar \fB\-vv\fP (\fB\-\-verbose \-\-verbose\fP) como no exemplo acima pode ser útil
+para ver os requisitos de memória do compactador e do
+descompactador. Lembre\-se que usar um dicionário maior que o tamanho do
+arquivo descompactado é desperdício de memória, então o comando acima não é
+útil para arquivos pequenos.
+.PP
+À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
+\fB\-6e\fP (\fB\-6 \-\-extreme\fP) como base e define o dicionário como apenas 64\ KiB. O arquivo resultante pode ser descompactado com XZ Embedded (é por isso
+que existe \fB\-\-check=crc32\fP) usando cerca de 100\ KiB de memória.
+.RS
+.PP
+.nf
+\f(CWxz \-\-check=crc32 \-\-lzma2=preset=6e,dict=64KiB foo\fP
+.fi
+.RE
+.PP
+Se você deseja espremer o máximo de bytes possível, ajustar o número de bits
+de contexto literal (\fIlc\fP) e o número de bits de posição (\fIpb\fP) às vezes
+pode ajudar. Ajustar o número de bits de posição literal (\fIlp\fP) também pode
+ajudar, mas geralmente \fIlc\fP e \fIpb\fP 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 \fBxz \-6e\fP (tente também sem \fBlc=4\fP):
+.RS
+.PP
+.nf
+\f(CWxz \-\-lzma2=preset=6e,pb=0,lc=4 source_code.tar\fP
+.fi
+.RE
+.PP
+O uso de outro filtro junto com o LZMA2 pode melhorar a compactação com
+determinados tipos de arquivo. Por exemplo, para compactar uma biblioteca
+compartilhada x86\-32 ou x86\-64 usando o filtro x86 BCJ:
+.RS
+.PP
+.nf
+\f(CWxz \-\-x86 \-\-lzma2 libfoo.so\fP
+.fi
+.RE
+.PP
+Observe que a ordem das opções de filtro é significativa. Se \fB\-\-x86\fP for
+especificado após \fB\-\-lzma2\fP, \fBxz\fP 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.
+.PP
+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.
+.PP
+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 \fBdist=3\fP, e também é bom passar \fBpb=0\fP para LZMA2
+para acomodar o alinhamento de três bytes:
+.RS
+.PP
+.nf
+\f(CWxz \-\-delta=dist=3 \-\-lzma2=pb=0 foo.tiff\fP
+.fi
+.RE
+.PP
+Se várias imagens foram colocadas em um único arquivo (por exemplo,
+\&\fB.tar\fP), o filtro Delta também funcionará, desde que todas as imagens
+tenham o mesmo número de bytes por pixel.
+.
+.SH "VEJA TAMBÉM"
+\fBxzdec\fP(1), \fBxzdiff\fP(1), \fBxzgrep\fP(1), \fBxzless\fP(1), \fBxzmore\fP(1),
+\fBgzip\fP(1), \fBbzip2\fP(1), \fB7z\fP(1)
+.PP
+XZ Utils: <https://tukaani.org/xz/>
+.br
+XZ Embedded: <https://tukaani.org/xz/embedded.html>
+.br
+LZMA SDK: <https://7\-zip.org/sdk.html>
diff --git a/po4a/man/pt_BR/xzdec.1 b/po4a/man/pt_BR/xzdec.1
new file mode 100644
index 0000000..09f9255
--- /dev/null
+++ b/po4a/man/pt_BR/xzdec.1
@@ -0,0 +1,85 @@
+.\"
+.\" Author: Lasse Collin
+.\"
+.\" This file has been put into the public domain.
+.\" You can do whatever you want with this file.
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH XZDEC 1 2017\-04\-19 Tukaani "XZ Utils"
+.SH NOME
+xzdec, lzmadec \- Pequenos descompactadores .xz e .lzma
+.SH SINOPSE
+\fBxzdec\fP [\fIopção...\fP] [\fIarquivo...\fP]
+.br
+\fBlzmadec\fP [\fIopção...\fP] [\fIarquivo...\fP]
+.SH DESCRIÇÃO
+\fBxzdec\fP é uma ferramenta de descompactação baseada em liblzma somente para
+arquivos \fB.xz\fP (e somente \fB.xz\fP). \fBxzdec\fP destina\-se a funcionar como um
+substituto para \fBxz\fP(1) nas situações mais comuns em que um script foi
+escrito para usar \fBxz \-\-decompress \-\-stdout\fP (e possivelmente alguns outras
+opções comumente usadas) para descompactar arquivos \fB.xz\fP. \fBlzmadec\fP é
+idêntico a \fBxzdec\fP exceto que \fBlzmadec\fP tem suporte a arquivos \fB.lzma\fP em
+vez de arquivos \fB.xz\fP.
+.PP
+Para reduzir o tamanho do executável, \fBxzdec\fP não tem suporte ao uso de
+várias threads ou a localização, e não lê opções de variáveis de ambiente
+\fBXZ_DEFAULTS\fP e \fBXZ_OPT\fP. \fBxzdec\fP não tem suporte à exibição de
+informações de progresso intermediárias: enviar \fBSIGINFO\fP para \fBxzdec\fP não
+faz nada, mas enviar \fBSIGUSR1\fP encerra o processo em vez de exibir
+informações de progresso.
+.SH OPÇÕES
+.TP 
+\fB\-d\fP, \fB\-\-decompress\fP, \fB\-\-uncompress\fP
+Ignorada para compatibilidade \fBxz\fP(1). \fBxzdec\fP tem suporte a apenas
+descompactação.
+.TP 
+\fB\-k\fP, \fB\-\-keep\fP
+Ignorada para compatibilidade \fBxz\fP(1). \fBxzdec\fP nunca cria ou remove
+quaisquer arquivos.
+.TP 
+\fB\-c\fP, \fB\-\-stdout\fP, \fB\-\-to\-stdout\fP
+Ignorada para compatibilidade \fBxz\fP(1). \fBxzdec\fP sempre grava os dados
+descompactados para a saída padrão.
+.TP 
+\fB\-q\fP, \fB\-\-quiet\fP
+Especificar isso uma vez não faz nada, pois \fBxzdec\fP nunca exibe nenhum
+aviso ou notificação. Especifique isso duas vezes para suprimir erros.
+.TP 
+\fB\-Q\fP, \fB\-\-no\-warn\fP
+Ignorada para compatibilidade \fBxz\fP(1). \fBxzdec\fP nunca usa o status de saída
+2.
+.TP 
+\fB\-h\fP, \fB\-\-help\fP
+Exibe uma mensagem de ajuda e sai com sucesso.
+.TP 
+\fB\-V\fP, \fB\-\-version\fP
+Mostra o número da versão do \fBxzdec\fP e liblzma.
+.SH "STATUS DE SAÍDA"
+.TP 
+\fB0\fP
+Correu tudo bem.
+.TP 
+\fB1\fP
+Ocorreu um erro.
+.PP
+\fBxzdec\fP não possui nenhuma mensagem de aviso como o \fBxz\fP(1), portanto, o
+status de saída 2 não é usado por \fBxzdec\fP.
+.SH NOTAS
+Use \fBxz\fP(1) em vez de \fBxzdec\fP ou \fBlzmadec\fP para uso diário
+normal. \fBxzdec\fP ou \fBlzmadec\fP destinam\-se apenas a situações em que é
+importante ter um descompactador menor do que o \fBxz\fP(1) completo.
+.PP
+\fBxzdec\fP e \fBlzmadec\fP não são realmente tão pequenos. O tamanho pode ser
+reduzido ainda mais eliminando recursos do liblzma no tempo de compilação,
+mas isso geralmente não deve ser feito para executáveis distribuídos em
+distribuições típicas de sistemas operacionais não embarcados. Se você
+precisa de um descompactador \fB.xz\fP realmente pequeno, considere usar o XZ
+Embedded.
+.SH "VEJA TAMBÉM"
+\fBxz\fP(1)
+.PP
+XZ Embedded: <https://tukaani.org/xz/embedded.html>
diff --git a/po4a/man/pt_BR/xzdiff.1 b/po4a/man/pt_BR/xzdiff.1
new file mode 100644
index 0000000..9203c41
--- /dev/null
+++ b/po4a/man/pt_BR/xzdiff.1
@@ -0,0 +1,44 @@
+.\"
+.\" Original zdiff.1 for gzip: Jean-loup Gailly
+.\"
+.\" Modifications for XZ Utils: Lasse Collin
+.\"                             Andrew Dudman
+.\"
+.\" License: GNU GPLv2+
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH XZDIFF 1 2021\-06\-04 Tukaani "XZ Utils"
+.SH NOME
+xzcmp, xzdiff, lzcmp, lzdiff \- compara arquivos compactados
+.SH SINOPSE
+\fBxzcmp\fP [\fIopções_cmd\fP] \fIarquivo1\fP [\fIarquivo2\fP]
+.br
+\fBxzdiff\fP [\fIopções_diff\fP] \fIarquivo1\fP [\fIarquivo2\fP]
+.br
+\fBlzcmp\fP [\fIopções_cmp\fP] \fIarquivo1\fP [\fIarquivo2\fP]
+.br
+\fBlzdiff\fP [\fIopções_diff\fP] \fIarquivo1\fP [\fIarquivo2\fP]
+.SH DESCRIÇÃO
+\fBxzcmp\fP e \fBxzdiff\fP invocam \fBcmp\fP(1) ou \fBdiff\fP(1) em arquivos compactados
+com \fBxz\fP(1), \fBlzma\fP(1), \fBgzip\fP( 1), \fBbzip2\fP(1), \fBlzop\fP(1) ou
+\fBzstd\fP(1). Todas as opções especificadas são passadas diretamente para
+\fBcmp\fP(1) ou \fBdiff\fP(1). Se apenas um arquivo for especificado, os arquivos
+comparados serão \fIarquivo1\fP (que deve ter um sufixo de um formato de
+compactação compatível) e \fIarquivo1\fP do qual o sufixo do formato de
+compactação foi removido. Se dois arquivos forem especificados, eles serão
+descompactados, se necessário, e enviados para \fBcmp\fP(1) ou \fBdiff\fP(1). O
+status de saída de \fBcmp\fP(1) ou \fBdiff\fP(1) é preservado, a menos que ocorra
+um erro de descompactação; então o status de saída é 2.
+.PP
+Os nomes \fBlzcmp\fP e \fBlzdiff\fP são fornecidos para compatibilidade com
+versões anteriores do LZMA Utils.
+.SH "VEJA TAMBÉM"
+\fBcmp\fP(1), \fBdiff\fP(1), \fBxz\fP(1), \fBgzip\fP(1), \fBbzip2\fP(1), \fBlzop\fP(1),
+\fBzstd\fP(1), \fBzdiff\fP(1)
+.SH BUGS
+As mensagens dos programas \fBcmp\fP(1) ou \fBdiff\fP(1) referem\-se a nomes de
+arquivos temporários em vez daqueles especificados.
diff --git a/po4a/man/pt_BR/xzgrep.1 b/po4a/man/pt_BR/xzgrep.1
new file mode 100644
index 0000000..1a347fb
--- /dev/null
+++ b/po4a/man/pt_BR/xzgrep.1
@@ -0,0 +1,63 @@
+.\"
+.\" Original zgrep.1 for gzip: Jean-loup Gailly
+.\"                            Charles Levert <charles@comm.polymtl.ca>
+.\"
+.\" Modifications for XZ Utils: Lasse Collin
+.\"
+.\" License: GNU GPLv2+
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH XZGREP 1 2022\-07\-19 Tukaani "XZ Utils"
+.SH NOME
+xzgrep \- pesquisa arquivos compactados para uma expressão regular
+.SH SINOPSE
+\fBxzgrep\fP [\fIopções_grep\fP] [\fB\-e\fP] \fIpadrão\fP [\fIarquivo...\fP]
+.br
+\fBxzegrep\fP \&...
+.br
+\fBxzfgrep\fP \&...
+.br
+\fBlzgrep\fP \&...
+.br
+\fBlzegrep\fP \&...
+.br
+\fBlzfgrep\fP \&...
+.SH DESCRIÇÃO
+\fBxzgrep\fP invoca \fBgrep\fP(1) em \fIarquivos\fP que podem ser descompactados ou
+compactados com \fBxz\fP(1), \fBlzma\fP(1), \fBgzip\fP(1), \fBbzip2\fP(1), \fBlzop\fP(1),
+ou \fBzstd\fP(1). Todas as opções especificadas são passadas diretamente para
+\fBgrep\fP(1).
+.PP
+Se nenhum \fIarquivo\fP for especificado, a entrada padrão será descompactada,
+se necessário, e enviada para \fBgrep\fP(1). Ao ler da entrada padrão, os
+arquivos compactados \fBgzip\fP(1), \fBbzip2\fP(1), \fBlzop\fP(1) e \fBzstd\fP(1) não
+são suportados.
+.PP
+Se \fBxzgrep\fP for chamado como \fBxzegrep\fP ou \fBxzfgrep\fP, então \fBgrep \-E\fP ou
+\fBgrep \-F\fP será usado em vez de \fBgrep\fP(1). O mesmo se aplica aos nomes
+\fBlzgrep\fP, \fBlzegrep\fP e \fBlzfgrep\fP, que são fornecidos para compatibilidade
+com versões anteriores do LZMA Utils.
+.SH "STATUS DE SAÍDA"
+.TP 
+0
+Pelo menos uma correspondência foi encontrada em pelo menos um dos arquivos
+de entrada. Nenhum erro ocorreu.
+.TP 
+1
+Nenhuma correspondência foi encontrada em nenhum dos arquivos de
+entrada. Nenhum erro ocorreu.
+.TP 
+>1
+Ocorreu um ou mais erros. Não se sabe se foram encontradas correspondências.
+.SH AMBIENTE
+.TP 
+\fBGREP\fP
+Se a variável de ambiente \fBGREP\fP for definida, \fBxzgrep\fP a usará em vez de
+\fBgrep\fP(1), \fBgrep \-E\fP ou \fBgrep \-F\fP.
+.SH "VEJA TAMBÉM"
+\fBgrep\fP(1), \fBxz\fP(1), \fBgzip\fP(1), \fBbzip2\fP(1), \fBlzop\fP(1), \fBzstd\fP(1),
+\fBzgrep\fP(1)
diff --git a/po4a/man/pt_BR/xzless.1 b/po4a/man/pt_BR/xzless.1
new file mode 100644
index 0000000..c2da329
--- /dev/null
+++ b/po4a/man/pt_BR/xzless.1
@@ -0,0 +1,46 @@
+.\"
+.\" Authors: Andrew Dudman
+.\"          Lasse Collin
+.\"
+.\" This file has been put into the public domain.
+.\" You can do whatever you want with this file.
+.\"
+.\" (Note that this file is not based on gzip's zless.1.)
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH XZLESS 1 2010\-09\-27 Tukaani "XZ Utils"
+.SH NOME
+xzless, lzless \- visualiza arquivos (texto) compactados em xz ou lzma
+.SH SINOPSE
+\fBxzless\fP [\fIarquivo\fP...]
+.br
+\fBlzless\fP [\fIarquivo\fP...]
+.SH DESCRIÇÃO
+\fBxzless\fP é um filtro que exibe texto de arquivos compactados em um
+terminal. Ele funciona em arquivos compactados com \fBxz\fP(1) ou
+\fBlzma\fP(1). Se nenhum \fIfiles\fP for fornecido, \fBxzless\fP lê da entrada
+padrão.
+.PP
+\fBxzless\fP usa \fBless\fP(1) para apresentar sua saída. Ao contrário de
+\fBxzmore\fP, sua escolha de pager não pode ser alterada pela configuração de
+uma variável de ambiente. Os comandos são baseados em \fBmore\fP(1) e \fBvi\fP(1)
+e permitem movimento e busca para frente e para trás. Consulte o manual
+\fBless\fP(1) para obter mais informações.
+.PP
+O comando denominado \fBlzless\fP é fornecido para compatibilidade com versões
+anteriores do LZMA Utils.
+.SH AMBIENTE
+.TP 
+\fBLESSMETACHARS\fP
+Uma lista de caracteres especiais para o shell. Definido por \fBxzless\fP a
+menos que já esteja definido no ambiente.
+.TP 
+\fBLESSOPEN\fP
+Defina como uma linha de comando para invocar o descompactador \fBxz\fP(1) para
+pré\-processar os arquivos de entrada para \fBless\fP(1).
+.SH "VEJA TAMBÉM"
+\fBless\fP(1), \fBxz\fP(1), \fBxzmore\fP(1), \fBzless\fP(1)
diff --git a/po4a/man/pt_BR/xzmore.1 b/po4a/man/pt_BR/xzmore.1
new file mode 100644
index 0000000..281ea63
--- /dev/null
+++ b/po4a/man/pt_BR/xzmore.1
@@ -0,0 +1,39 @@
+.\"
+.\" Original zdiff.1 for gzip: Jean-loup Gailly
+.\" Modifications for XZ Utils: Lasse Collin
+.\"
+.\" License: GNU GPLv2+
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH XZMORE 1 2013\-06\-30 Tukaani "XZ Utils"
+.SH NOME
+xzmore, lzmore \- visualiza arquivos (texto) compactados em xz ou lzma
+.SH SINOPSE
+\fBxzmore\fP [\fIarquivo...\fP]
+.br
+\fBlzmore\fP [\fIarquivo...\fP]
+.SH DESCRIÇÃO
+\fBxzmore\fP é um filtro que permite o exame de arquivos de texto compactados
+\fBxz\fP(1) ou \fBlzma\fP(1) uma tela por vez em um terminal de cópia eletrônica.
+.PP
+Para usar um pager diferente do padrão \fBmore,\fP defina a variável de
+ambiente \fBPAGER\fP para o nome do programa desejado. O nome \fBlzmore\fP é
+fornecido para compatibilidade com versões anteriores do LZMA Utils.
+.TP 
+\fBe\fP ou \fBq\fP
+Quando o prompt \-\-More\-\-(Next file: \fIarquivo\fP) é impresso, esse comando faz
+com que \fBxzmore\fP saia.
+.TP 
+\fBs\fP
+Quando o prompt \-\-More\-\-(Next file: \fIarquivo\fP) é impresso, esse comando faz
+com que \fBxzmore\fP pule o próximo arquivo e continue.
+.PP
+Para obter uma lista de comandos de teclado suportados durante a exibição
+real do conteúdo de um arquivo, consulte o manual do paginador que você usa,
+geralmente \fBmore\fP(1).
+.SH "VEJA TAMBÉM"
+\fBmore\fP(1), \fBxz\fP(1), \fBxzless\fP(1), \fBzmore\fP(1)