diff options
Diffstat (limited to 'po4a/man/pt_BR/xz.1')
| -rw-r--r-- | po4a/man/pt_BR/xz.1 | 1837 |
1 files changed, 1837 insertions, 0 deletions
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> |