.ZIP são arquivos que armazenam múltiplos arquivos. ZIP permite que os arquivos contidos sejam comprimidos usando muitos métodos diferentes, assim como simplesmente armazenar um arquivo sem comprimi-lo. Cada arquivo é armazenado separadamente, permitindo que arquivos diferentes no mesmo arquivo sejam compactados usando métodos diferentes. Como os arquivos em um arquivo ZIP são comprimidos individualmente, é possível extraí-los ou adicionar novos, sem aplicar compressão ou descompressão a todo o arquivo. Isso contrasta com o formato dos arquivos tar comprimidos, para os quais esse processamento de acesso aleatório não é facilmente possível.
Um diretório é colocado no final de um arquivo ZIP. Isto identifica quais arquivos estão no ZIP e identifica onde no ZIP esse arquivo está localizado. Isto permite aos leitores ZIP carregar a lista de arquivos sem ler todo o arquivo ZIP. Os arquivos ZIP também podem incluir dados extras que não estão relacionados com o arquivo ZIP. Isto permite que um arquivo ZIP seja transformado em um arquivo auto-extraível (aplicação que descomprime seus dados contidos), ao pré-ender o código do programa a um arquivo ZIP e marcar o arquivo como executável. O armazenamento do catálogo no final também possibilita esconder um arquivo zipado anexando-o a um arquivo inócuo, como um arquivo de imagem GIF.
O formato .ZIP usa um algoritmo CRC de 32 bits e inclui duas cópias da estrutura de diretórios do arquivo para fornecer maior proteção contra perda de dados.
StructureEdit
Um arquivo ZIP é corretamente identificado pela presença de um fim de registro de diretório central que está localizado no final da estrutura do arquivo, a fim de permitir a fácil anexação de novos arquivos. Se o fim do registro do diretório central indicar um arquivo não vazio, o nome de cada arquivo ou diretório dentro do arquivo deve ser especificado em uma entrada do diretório central, juntamente com outros metadados sobre a entrada, e um offset no arquivo ZIP, apontando para os dados da entrada real. Isso permite que uma listagem do arquivo seja feita relativamente rapidamente, já que o arquivo inteiro não precisa ser lido para ver a lista de arquivos. As entradas dentro do file ZIP também incluem essas informações, para redundância, em um cabeçalho de file local. Como os arquivos ZIP podem ser anexados, somente os arquivos especificados no diretório central no final do arquivo são válidos. A verificação de um arquivo ZIP em busca de cabeçalhos de arquivo local é inválida (exceto no caso de arquivos corrompidos), pois o diretório central pode declarar que alguns arquivos foram excluídos e outros foram atualizados.
Por exemplo, podemos começar com um arquivo ZIP que contém arquivos A, B e C. O arquivo B é então excluído e C é atualizado. Isto pode ser conseguido apenas anexando um novo arquivo C ao final do arquivo ZIP original e adicionando um novo diretório central que lista apenas o arquivo A e o novo arquivo C. Quando ZIP foi projetado pela primeira vez, transferir arquivos por disquete era comum, mas escrever em disquetes consumia muito tempo. Se você tivesse um arquivo zip grande, possivelmente abrangendo vários discos, e precisasse apenas atualizar alguns arquivos, ao invés de ler e reescrever todos os arquivos, seria substancialmente mais rápido apenas ler o diretório central antigo, anexar os novos arquivos e então anexar um diretório central atualizado.
A ordem das entradas do arquivo no diretório central não precisa coincidir com a ordem das entradas do arquivo.
Cada entrada armazenada em um arquivo ZIP é introduzida por um cabeçalho de arquivo local com informações sobre o arquivo, como o comentário, tamanho do arquivo e nome do arquivo, seguido por campos de dados opcionais “extras”, e então os dados do arquivo possivelmente comprimido, possivelmente criptografado. Os campos de dados “extras” são a chave para a extensibilidade do formato ZIP. Os campos “extra” são explorados para suportar o formato ZIP64, criptografia AES compatível com o WinZip, atributos de arquivo e carimbos de tempo de arquivo NTFS ou Unix de alta resolução. Outras extensões são possíveis através do campo “Extra”. As ferramentas ZIP são exigidas pela especificação para ignorar campos Extra que não reconhecem.
O formato ZIP usa “assinaturas” específicas de 4 bytes para denotar as várias estruturas no arquivo. Cada entrada de arquivo é marcada por uma assinatura específica. O fim do registo do directório central é indicado com a sua assinatura específica, e cada entrada no directório central começa com a assinatura do cabeçalho do ficheiro central de 4 bytes.
Não existe um marcador BOF ou EOF na especificação ZIP. Convencionalmente a primeira coisa num ficheiro ZIP é uma entrada ZIP, que pode ser facilmente identificada pela sua assinatura local do cabeçalho do ficheiro. No entanto, este não é necessariamente o caso, já que isto não é exigido pela especificação ZIP – mais notadamente, um arquivo auto-extraível começará com um cabeçalho de arquivo executável.
Ferramentas que lêem corretamente os arquivos ZIP devem procurar pelo fim da assinatura de registro do diretório central, e então, conforme apropriado, o outro, indicado, registros do diretório central. Eles não devem procurar por entradas do topo do arquivo ZIP, porque (como mencionado anteriormente nesta seção) apenas o diretório central especifica onde um trecho de arquivo começa e que ele não foi apagado. A varredura pode levar a falsos positivos, pois o formato não proíbe que outros dados fiquem entre pedaços, nem que fluxos de dados de arquivos contenham tais assinaturas. Entretanto, ferramentas que tentam recuperar dados de arquivos ZIP danificados muito provavelmente escanearão o arquivo em busca de assinaturas locais do cabeçalho do arquivo; isto é dificultado pelo fato de que o tamanho comprimido de um trecho de arquivo pode ser armazenado após o trecho de arquivo, tornando o processamento seqüencial difícil.
A maioria das assinaturas termina com o número inteiro curto 0x4b50, que é armazenado em ordem little-endian. Visto como uma string ASCII, esta lê “PK”, as iniciais do inventor Phil Katz. Assim, quando um arquivo ZIP é visto em um editor de texto os dois primeiros bytes do arquivo são geralmente “PK”. (DOS, OS/2 e Windows auto-extraível ZIPs têm um EXE antes do ZIP então comece com “MZ”; ZIPs auto-extraíveis para outros sistemas operacionais podem similarmente ser precedidos por código executável para extrair o conteúdo do arquivo naquela plataforma.)
A especificação .ZIP também suporta a propagação de arquivos através de múltiplos arquivos de sistema de arquivos. Originalmente destinado ao armazenamento de arquivos ZIP grandes através de múltiplos disquetes, este recurso agora é usado para enviar arquivos ZIP em partes por e-mail, ou por outros transportes ou mídia removível.
O sistema de arquivos FAT do DOS tem uma resolução de timestamp de apenas dois segundos; os registros de arquivos ZIP imitam isto. Como resultado, a resolução de timestamp incorporada dos arquivos em um arquivo ZIP é de apenas dois segundos, embora campos extras possam ser usados para armazenar timestamps mais precisos. O formato ZIP não tem noção de fuso horário, então os timestamps só são significativos se for conhecido qual fuso horário eles foram criados em.
Em setembro de 2007, PKWARE lançou uma revisão da especificação ZIP fornecendo o armazenamento de nomes de arquivos usando UTF-8, finalmente adicionando compatibilidade Unicode a ZIP.
Cabeçalhos de arquivoEditar
Todos os valores de multi-byte no cabeçalho são armazenados em ordem de bytes little-endian. Todos os campos de comprimento contam o comprimento em bytes.
Cabeçalho de ficheiro localEditar
| Offset | Bytes | Descrição | |
|---|---|---|---|
| 0 | 4 | Assinatura de cabeçalho de ficheiro local = 0x04034b50 (lido como um pequeno…número do tutor) | |
| 4 | 2 | >Versão necessária para extrair (mínimo) | |
| 6 | 2 | Bandeira de bit de propósito geral | |
| 8 | 2 | Método de compressão | |
| 10 | 2 | Tempo da última modificação do ficheiro | |
| 12 | 2 | Tempo da última modificação do ficheiro | |
| 14 | 4 | CRC-32 de dados não comprimidos | |
| 18 | 4 | Tamanho comprimido (ou 0xffffffff para ZIP64) | |
| 22 | 4 | Tamanho não comprimido (ou 0xffffff para ZIP64) | |
| 26 | 2 | 2 | Comprimento do nome do ficheiro (n) |
| 28 | 2 | Comprimento do campo extra (m) | |
| 30 | n | Nome do ficheiro | |
| 30+n | m | Campo extra |
O campo extra contém uma variedade de dados opcionais, tais como OS-atributos específicos. Está dividido em pedaços, cada um com um código de identificação de 16 bits e um comprimento de 16 bits. Para ZIP64, pelo menos um trecho (com código de ID 0001 e tamanho de 32 bytes) sempre existe, veja abaixo.
Isso é imediatamente seguido pelos dados comprimidos.
Data descriptorEdit
Se o bit no offset 3 (0x08) do campo general-purpose flags estiver definido, então o CRC-32 e os tamanhos dos arquivos não são conhecidos quando o cabeçalho é escrito. Os campos no cabeçalho local são preenchidos com zero, e o CRC-32 e o tamanho são anexados em uma estrutura de 12 bytes (opcionalmente precedida por uma assinatura de 4 bytes) imediatamente após os dados comprimidos:
| Offset | Bytes | Descrição |
|---|---|---|
| 0 | 0/4 | Assinatura do descritor de dados opcional = 0x08074b50 |
| 0/4 | 4 | CRC-32 de dados não comprimidos |
| 4/8 | 4 | Tamanho comprimido |
| 8/12 | 4 | Não comprimido tamanho |
Cabeçalho do directório centralEditar
A entrada do directório central é uma forma expandida do cabeçalho local:
| Offset | Bytes | Descrição | |
|---|---|---|---|
| 0 | 4 | Central assinatura do cabeçalho do ficheiro de directório = 0x02014b50 | |
| 4 | 2 | Versão feita por | |
| 6 | 2 | Versão necessária para extrair (mínimo) | |
| 8 | 2 | Bandeira de bit de propósito geral | |
| 10 | 2 | Método de compressão | |
| 12 | 2 | Tempo da última modificação do arquivo | |
| 14 | 2 | 2 | Tempo da última modificação do arquivo |
| 16 | 4 | CRC-32 de dados não comprimidos | |
| 20 | 4 | Tamanho comprimido (ou 0xffffffff para ZIP64) | |
| 24 | 4 | Tamanho não comprimido (ou 0xffffff para ZIP64) | |
| 28 | 2 | Comprimento do nome do ficheiro (n) | |
| 30 | 2 | Comprimento do campo extra (m) | |
| 32 | 2 | Comprimento do comentário do arquivo (k) | |
| 34 | 2 | 2 | Número doDisk onde o arquivo começa |
| 36 | 2 | Atributos de ficheiro internos | |
| 38 | 4 | Atributos de ficheiro externos | |
| 42 | 4 | Deslocamento relativo do cabeçalho do ficheiro local. Este é o número de bytes entre o início do primeiro disco em que o arquivo ocorre, e o início do cabeçalho do arquivo local. Isto permite que o software que lê o diretório central localize a posição do arquivo dentro do arquivo ZIP. | |
| 46 | n | Nome do ficheiro | |
| 46+n | m | Campo extra | |
| 46+n+m | k | Comentário do arquivo |
Fim do registro do diretório central (EOCD)Editar
Após todas as entradas do diretório central vem o fim do registro do diretório central (EOCD), que marca o fim do ficheiro ZIP:
| Offset | Bytes | Descrição |
|---|---|---|
| 0 | 4 | End of assinatura do diretório central = 0x06054b50 |
| 4 | 2 | Número deste disco |
| 6 | 2 | Disk onde o diretório central starts |
| 8 | 2 | Número total de registros do diretório central neste disco |
| 10 | 2 | Número total de registros do diretório central registos do directório central |
| 12 | 4 | >Tamanho do directório central (bytes) |
| 16 | 4 | Offset of start of central directory, relativo ao início do arquivo |
| 20 | 2 | Comprimento do comentário (n) |
| 22 | n | Comentário |
Esta ordenação permite que um arquivo ZIP seja criado em uma passagem, mas o diretório central também é colocado no final do arquivo a fim de facilitar a remoção de arquivos de múltiplas partes (e.Como discutido anteriormente.
Métodos de compressãoEditar
O arquivo .ZIP File Format Specification documenta os seguintes métodos de compressão: Store (no compression), Shrink (LZW), Reduce (levels 1-4; LZ77 + probabilistic), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, e uma variante do LZ77 fornecida pela instrução IBM z/OS CMPSC. O método de compressão mais utilizado é o DEFLATE, que é descrito na IETF RFC 1951.
Outros métodos mencionados, mas não documentados em detalhes na especificação incluem: PKWARE DCL Implode (antigo IBM TERSE), novo IBM TERSE, IBM LZ77 z Architecture (PFS), e uma variante JPEG. Um método “Tokenize” foi reservado para terceiros, mas o suporte nunca foi adicionado.
A palavra Implode é sobreutilizada por PKWARE: o DCL/TERSE Implode é distinto do antigo PKZIP Implode, um predecessor do Deflate. O DCL Implode é indocumentado parcialmente devido à sua natureza proprietária mantida pela IBM, mas Mark Adler forneceu um descompressor chamado “blast” juntamente com zlib.
EncryptionEdit
ZIP suporta um sistema simples de criptografia simétrica baseada em senha, geralmente conhecido como ZipCrypto. Ele está documentado na especificação ZIP, e conhecido por ser seriamente defeituoso. Em particular, ele é vulnerável a ataques de texto conhecido, que em alguns casos são agravados por implementações pobres de geradores de números aleatórios.
Novos recursos incluindo novos métodos de compressão e criptografia (por exemplo, AES) foram documentados na Especificação de Formato de Arquivo ZIP desde a versão 5.2. Um padrão aberto baseado em AES (“AE-x” em APPNOTE) desenvolvido pelo WinZip é usado também pelo 7-Zip e Xceed, mas alguns fornecedores usam outros formatos. PKWARE SecureZIP (SES, proprietário) também suporta métodos de criptografia RC2, RC4, DES, Triple DES, criptografia e autenticação baseadas em certificados digitais (X.509), e criptografia de cabeçalho de arquivo. No entanto, ele é patenteado (veja § Forte controvérsia sobre criptografia).
A criptografia de nome de arquivo é introduzida na Especificação de formato de arquivo .ZIP 6.2, que criptografa metadados armazenados na parte do Diretório Central de um arquivo, mas as seções do Cabeçalho Local permanecem não criptografadas. Um arquivador compatível pode falsificar os dados do Cabeçalho Local ao usar a Criptografia do Diretório Central. A partir da versão 6.2 da especificação, os campos Compression Method e Compressed Size dentro do Local Header ainda não estão mascarados.
ZIP64Edit
O formato original .ZIP tinha um limite de 4 GiB (232 bytes) em várias coisas (tamanho não comprimido de um arquivo, tamanho comprimido de um arquivo e tamanho total do arquivo), bem como um limite de 65.535 (216) entradas em um arquivo ZIP. Na versão 4.5 da especificação (que não é igual à v4.5 de nenhuma ferramenta em particular), PKWARE introduziu as extensões de formato “ZIP64” para contornar essas limitações, aumentando os limites para 16 EiB (264 bytes). Em essência, ele usa uma entrada de diretório central “normal” para um arquivo, seguido por uma entrada de diretório opcional “zip64”, que tem os campos maiores.
O formato do cabeçalho do arquivo Local e da entrada de diretório Central são os mesmos em ZIP e ZIP64, mas para tamanhos sempre 0xffffffff armazenados, e um campo extra sempre existe:
| Offset | Bytes | Descrição | |
|---|---|---|---|
| 0 | 2 | Header ID 0x0001 | |
| 2 | 2 | 2 | Tamanho do pedaço de campo extra (16, 24 ou 28) |
| 4 | 8 | Tamanho do ficheiro original não comprimido | |
| 12 | 8 | Tamanho dos dados comprimidos | |
| 20 | 8 | Offset of local header record | |
| 28 | 4 | Número do disco em que este ficheiro começa |
Por outro lado, o formato do EOCD para o ZIP64 é ligeiramente diferente da versão normal do ZIP (consulte a secção 4 do apêndice).3.14).
| Offset | Bytes | Descrição |
|---|---|---|
| 0 | 4 | End of central directory signature = 0x06064b50 |
| 4 | 8 | Tamanho do EOCD64 – 8 |
| 12 | 2 | Versão feita por |
| 14 | 2 | Versão necessária para extrair (no mínimo) |
| 16 | 4 | Número deste disco |
| 20 | 4 | Disk onde começa o diretório central |
| 24 | 8 | Número total de registos de directório central neste disco |
| 32 | 8 | Número total de registos de directório central |
| 40 | 8 | Tamanho do directório central (bytes) |
| 48 | 8 | Offset do início do directório central, relativo ao início do arquivo |
| 56 | n | Comentário (até ao tamanho do EOCD64) |
Também não é necessariamente o último registo no ficheiro, pode seguir-se um Fim de Localizador de Directório Central opcional (um adicional de 20 bytes no final).
O File Explorer no Windows XP não suporta o ZIP64, mas o Explorer no Windows Vista e mais tarde o faz. Da mesma forma, algumas bibliotecas de extensão suportam o ZIP64, como DotNetZip, QuaZIP e IO::Compress::Zip em Perl. O arquivo zip embutido do Python suporta desde a versão 2.5 e o padrão desde a versão 3.4. O java.util.zip embutido do OpenJDK suporta o ZIP64 a partir da versão Java 7. O Android Java API suporta ZIP64 desde o Android 6.0. O Archive Utility do Mac OS Sierra notavelmente não suporta o ZIP64, e pode criar arquivos corrompidos quando o ZIP64 for necessário. No entanto, o comando ditto enviado com o Mac OS irá descompactar os arquivos ZIP64. Versões mais recentes do Mac OS são fornecidas com as ferramentas de linha de comando zip e unzip que suportam Zip64: para verificar execute zip -v e procure por “ZIP64_SUPPORT”.
Combinação com outros formatos de arquivoEditar
O formato de arquivo .ZIP permite que um comentário contendo até 65.535 (216-1) bytes de dados ocorra no final do arquivo após o diretório central. Além disso, como o diretório central especifica o offset de cada arquivo no arquivo em relação ao início, é possível que a primeira entrada de arquivo comece com um offset diferente de zero, embora algumas ferramentas, por exemplo gzip, não processem arquivos que não comecem com uma entrada de arquivo com offset zero.
Isso permite que dados arbitrários ocorram no arquivo tanto antes quanto depois dos dados do arquivo ZIP, e que o arquivo ainda seja lido por uma aplicação ZIP. Um efeito colateral disso é que é possível criar um arquivo que seja tanto um arquivo ZIP funcional quanto um outro formato, desde que o outro formato tolere dados arbitrários em seu final, início ou meio. Os arquivos auto-extraíveis (SFX), do formato suportado pelo WinZip, tiram partido disso, na medida em que são ficheiros executáveis (.exe) que estão em conformidade com a especificação PKZIP AppNote.txt, e podem ser lidos por ferramentas zip ou bibliotecas compatíveis.
Esta propriedade do formato .ZIP, e do formato JAR que é uma variante do ZIP, pode ser explorada para esconder conteúdo nocivo (como classes Java nocivas) dentro de um arquivo aparentemente inofensivo, como uma imagem GIF carregada para a web. Esta chamada exploração GIFAR foi demonstrada como um ataque eficaz contra aplicações web como o Facebook.
LimitsEdit
O tamanho mínimo de um arquivo .ZIP é de 22 bytes. Tal arquivo zip vazio contém apenas um Fim de Registro Central de Diretório (EOCD):
O tamanho máximo para o arquivo e para os arquivos individuais dentro dele é de 4.294.967.295 bytes (232-1 bytes, ou 4 GiB menos 1 byte) para o ZIP padrão. Para ZIP64, o tamanho máximo é de 18.446.744.073.709.551.615 bytes (264-1 bytes, ou 16 EiB menos 1 byte).
Extensões proprietáriasEditar
Campo extraEditar
.O formato de arquivo ZIP inclui um recurso de campo extra dentro dos cabeçalhos do arquivo, que pode ser usado para armazenar dados extras não definidos pelas especificações ZIP existentes, e que permitem que arquivadores compatíveis que não reconhecem os campos os ignorem com segurança. Os IDs de cabeçalho 0-31 são reservados para uso pelo PKWARE. Os IDs restantes podem ser usados por fornecedores terceiros para uso proprietário.
Forte controvérsia de criptografiaEditar
Quando o WinZip 9.0 public beta foi lançado em 2003, o WinZip introduziu sua própria criptografia AES-256, usando um formato de arquivo diferente, juntamente com a documentação para a nova especificação. Os padrões de criptografia em si não eram proprietários, mas o PKWARE não tinha atualizado o APPNOTE.TXT para incluir a Strong Encryption Specification (SES) desde 2001, que tinha sido usada pelas versões PKZIP 5.0 e 6.0. O consultor técnico do WinZip Kevin Kearney e o gerente de produtos StuffIt Mathew Covington acusaram a PKWARE de reter SES, mas o diretor de tecnologia da PKZIP, Jim Peterson, alegou que a criptografia baseada em certificados ainda estava incompleta.
Em outra ação controversa, a PKWare solicitou uma patente em 16 de julho de 2003, descrevendo um método para combinar ZIP e criptografia forte para criar um arquivo seguro.
No final, PKWARE e WinZip concordaram em apoiar os produtos um do outro. Em 21 de janeiro de 2004, o PKWARE anunciou o suporte ao formato de compressão AES baseado no WinZip. Em uma versão posterior do WinZip beta, ele foi capaz de suportar arquivos ZIP baseados em SES. PKWARE finalmente lançou a versão 5.2 da Especificação do formato de arquivo .ZIP para o público, que documentou o SES. O projeto Free Software 7-Zip também suporta AES, mas não SES em arquivos ZIP (como sua porta POSIX p7zip).
Ao usar criptografia AES no WinZip, o método de compressão é sempre definido como 99, com o método de compressão real armazenado em um campo de dados extra AES. Em contraste, a Strong Encryption Specification armazena o método de compressão no segmento básico do cabeçalho do arquivo Local Header e Central Directory, a menos que a Central Directory Encryption seja usada para mascarar/encriptar metadados.