Introdução ao "UnZip"
O pacote UnZip contém utilitários
de extração ZIP. Eles são úteis para
extrair arquivos a partir de arquivamentos ZIP. Os arquivamentos ZIP são criados com os utilitários PKZIP ou Info-ZIP, principalmente em um ambiente "DOS".
Esse pacote é conhecido por construir e funcionar corretamente
usando uma plataforma LFS 12.1.
![[Cuidado]](../images/caution.png)
Cuidado
A versão anterior do pacote UnZip tinha alguns problemas relacionados à
localidade. Atualmente não existem editores(as) do BLFS capazes
de testar esses problemas de localidade. Portanto, as informações
relacionadas à localidade são deixadas nesta página, mas não
foram testadas. Uma discussão mais geral desses problemas pode
ser encontrada na seção
O Aplicativo Assume a Codificação da página Problemas Relacionados à
Localidade.
Informação do Pacote
-
Transferência (HTTP): https://downloads.sourceforge.net/infozip/unzip60.tar.gz
-
Transferência (FTP):
-
Soma de verificação MD5 da transferência:
62b490407489521db863b523a7f86375
-
Tamanho da transferência: 1,3 MB
-
Espaço em disco estimado exigido: 9 MB
-
Tempo de construção estimado: menos que 0,1 UPC
Transferências Adicionais
Problemas de Localidade do "UnZip"
![[Nota]](../images/note.png)
Nota
O uso de UnZip no JDK, Mozilla, DocBook ou qualquer outra instalação de
pacote do BLFS não é um problema, pois as instruções do BLFS
nunca usam UnZip para extrair um
arquivo com caracteres não "ASCII" no nome do arquivo.
Esses problemas são presumidos terem sido corrigidos no remendo.
Mas, como nenhum(a) dos(a) editores(a) tem dados para testar isso,
as seguintes soluções alternativas são mantidas caso ainda sejam
necessárias.
O pacote UnZip assume que os nomes
de arquivos armazenados nos arquivamentos "ZIP" criados em sistemas
não Unix estejam codificados em "CP850" e que deveriam ser
convertidos para "ISO-8859-1" ao escrever arquivos no sistema de
arquivos. Tais suposições nem sempre são válidas. Na verdade,
dentro do arquivamento "ZIP", os nomes dos arquivos são codificados
na página de códigos do "DOS" que estiver em uso no país relevante,
e os nomes dos arquivos no disco deveriam estar na codificação da
localidade. No "MS Windows", a função C "OemToChar()" (originária
de User32.DLL) faz a conversão
correta (que é, de fato, a conversão de "CP850" para um
superconjunto de "ISO-8859-1", se o "MS Windows" estiver
configurado para usar o idioma inglês dos Estados Unidos da América
do Norte), mas não existe equivalente no Linux.
Ao usar unzip para
desempacotar um arquivamento "ZIP" contendo nomes de arquivos não
"ASCII", os nomes dos arquivos são danificados porque unzip usa conversão inadequada
quando qualquer uma das suposições dele de codificação estiver
incorreta. Por exemplo, na localidade "ru_RU.KOI8-R", a conversão
de nomes de arquivos de "CP866" para "KOI8-R" é necessária, mas a
conversão de "CP850" para "ISO-8859-1" é feita, o que produz nomes
de arquivos que consistem em caracteres indecifráveis em vez de
palavras (o mais próximo exemplo compreensível equivalente para
usuários(as) somente em inglês é "rot13"). Existem várias maneiras
de contornar essa limitação:
1) Para desempacotar arquivamentos ZIP com nomes de arquivos
contendo caracteres não ASCII, use WinZip enquanto executa o emulador de
Windows Wine.
2) Use bsdtar -xf
oriundo de libarchive-3.7.2 para descompactar o
arquivamento "ZIP". Em seguida, corrija os danos causados aos nomes
dos arquivos usando a ferramenta convmv (https://j3e.de/linux/convmv/). A
seguir está um exemplo para a localidade "zh_CN.UTF-8":
convmv -f cp936 -t utf-8 -r --nosmart --notest \
</caminho/para/arquivos/descomprimidos>
Instalação do "UnZip"
Primeiro aplique o remendo:
patch -Np1 -i ../unzip-6.0-consolidated_fixes-1.patch
Agora compile o pacote:
make -f unix/Makefile generic
A suíte de teste não funciona para o alvo “generic”.
Agora, como o(a) usuário(a) root:
make prefix=/usr MANDIR=/usr/share/man/man1 \
-f unix/Makefile install
Explicações do Comando
make -f unix/Makefile
generic: Esse alvo começa executando um conjunto de
comandos sequenciais de configuração (ao contrário dos alvos mais
antigos, como linux e linux_noasm), o qual cria um arquivo de
sinalizadores que é então usado na construção. Isso garante que a
construção x86 de 32 bits receba os sinalizadores corretos para
descompactar arquivos que sejam maiores que 2 GB quando extraídos.