ZIP (formato de archivo)

ZIP es un formato de archivo que admite la compresión de datos sin pérdidas. Un archivo ZIP puede contener uno o más archivos o directorios que pueden haber sido comprimidos. El formato de archivo ZIP permite varios algoritmos de compresión, aunque DEFLATE es el más común. Este formato se creó originalmente en 1989 y se implementó por primera vez en la utilidad PKZIP de PKWARE, Inc., como reemplazo del formato de compresión ARC anterior de Thom Henderson. Luego, el formato ZIP fue rápidamente compatible con muchas utilidades de software además de PKZIP. Microsoft ha incluido soporte ZIP incorporado (bajo el nombre de "carpetas comprimidas") en versiones de Microsoft Windows desde 1998 a través de "Plus! 98" complemento para Windows 98. Se agregó soporte nativo a partir del año 2000 en Windows ME. Apple ha incluido soporte ZIP integrado en Mac OS X 10.3 (a través de BOMArchiveHelper, ahora Archive Utility) y versiones posteriores. La mayoría de los sistemas operativos gratuitos tienen soporte integrado para ZIP de manera similar a Windows y Mac OS X.

Los archivos ZIP generalmente usan las extensiones de archivo .zip o .ZIP y el tipo de medio MIME aplicación/zip. Muchos programas utilizan ZIP como formato de archivo base, generalmente con un nombre diferente. Al navegar por un sistema de archivos a través de una interfaz de usuario, los íconos gráficos que representan archivos ZIP a menudo aparecen como un documento u otro objeto que destaca una cremallera.

Historia

El formato de archivo .ZIP fue diseñado por Phil Katz de PKWARE y Gary Conway de Infinity Design Concepts. El formato se creó después de que Systems Enhancement Associates (SEA) presentara una demanda contra PKWARE alegando que los productos de archivo de este último, llamados PKARC, eran derivados del sistema de archivo ARC de SEA. El nombre "zip" (que significa "mover a alta velocidad") fue sugerido por el amigo de Katz, Robert Mahoney. Querían dar a entender que su producto sería más rápido que ARC y otros formatos de compresión de la época. La primera versión conocida de La especificación de formato de archivo.ZIP se publicó por primera vez como parte del paquete PKZIP 0.9 bajo el archivo APPNOTE.TXT en 1989. Al distribuir el formato de archivo zip dentro de APPNOTE.TXT, la compatibilidad con el formato de archivo zip proliferó ampliamente en la Internet pública durante la década de 1990.

PKWARE e Infinity Design Concepts emitieron un comunicado de prensa conjunto el 14 de febrero de 1989, lanzando el formato de archivo .ZIP al dominio público.

Historial de versiones

La especificación de formato de archivo.ZIP tiene su propio número de versión, que no corresponde necesariamente a los números de versión de la herramienta PKZIP, especialmente con PKZIP 6 o posterior. En varias ocasiones, PKWARE ha agregado funciones preliminares que permiten que los productos PKZIP extraigan archivos utilizando funciones avanzadas, pero los productos PKZIP que crean dichos archivos no estarán disponibles hasta la próxima versión principal. Otras empresas u organizaciones respaldan las especificaciones de PKWARE a su propio ritmo.

La especificación de formato de archivo.ZIP se denomina formalmente "APPNOTE - Especificación de formato de archivo.ZIP" y se publica en el sitio web PKWARE.com desde finales de la década de 1990. Varias versiones de la especificación no fueron publicadas. PKWARE publicó las especificaciones de algunas funciones, como la compresión BZIP2, la especificación de cifrado fuerte y otras, unos años después de su creación. La URL de la especificación en línea se cambió varias veces en el sitio web de PKWARE.

Un resumen de los avances clave en varias versiones de la especificación PKWARE:

• 2.0: (1993) Las entradas de archivos se pueden comprimir con DEFLATE y utilizar el encripto PKWARE tradicional (ZipCrypto).
• 2.1: (1996) Compresión deflate64
• 4.5: (2001) Formato postal de 64 bits.
• 4.6: (2001) Compresión BZIP2 (no publicada en línea hasta la publicación APPNOTE 5.2)
• 5.0: (2002) SES: DES, Triple DES, RC2, RC4 compatible con el cifrado (no publicado en línea hasta la publicación de APPNOTE 5.2)
• 5.2: (2003) Soporte de cifrado AES para SES (definido en APPNOTE 5.1 que no fue publicado en línea) y AES de WinZip ("AE-x"); versión corregida de RC2-64 compatible con el cifrado SES.
• 6.1: (2004) Almacenamiento de certificados documentados.
• 6.2.0: (2004) Cifrado del Directorio Central documentado.
• 6.3.0: (2006) Almacenamiento de nombre de archivo Unicode (UTF-8). Lista ampliada de algoritmos de compresión soportados (LZMA, PPMd+), algoritmos de cifrado (Blowfish, Twofish), y hashes.
• 6.3.1: (2007) Valores de hash estándar corregidos para SHA-256/384/512.
• 6.3.2: (2007) Método de compresión documentado 97 (WavPack).
• 6.3.3: (2012) Modificar los cambios para facilitar la remisión de la Nota de Aplicación de PKWARE de otras normas utilizando métodos tales como el Informe explicativo de referencia de JTC 1 (RER) dirigido por JTC 1/SC 34 N 1621.
• 6.3.4: (2014) Actualiza la dirección de oficina de PKWARE, Inc..
• 6.3.5: (2018) Métodos de compresión documentados 16, 96 y 99, epoca y precisión de temporizador de DOS, añadidos campos adicionales para claves y descifrado, así como typos y aclaraciones.
• 6.3.6: (2019) Error tipográfico corregido.
• 6.3.7: (2020) Se agregó el método de compresión Zstandard ID 20.
• 6.3.8: (2020) ID del método de compresión Zstandard de 20 a 93, deprecayendo el primero. ID de método documentado 94 y 95 (MP3 y XZ respectivamente).
• 6.3.9: (2020) Corregido un tipopo en la descripción de la alineación de la corriente de datos.
• 6.3.10: (2022) Se agregaron varios valores de atributo z/OS para APPENDIX B. Se agregaron varias cartografías adicionales de campo extra de terceros.

WinZip, a partir de la versión 12.1, usa la extensión .zipx para archivos ZIP que usan métodos de compresión más nuevos que DEFLATE; en concreto, los métodos BZip, LZMA, PPMd, Jpeg y Wavpack. Los últimos 2 se aplican a los tipos de archivos apropiados cuando "Mejor método" se selecciona la compresión.

Estandarización

En abril de 2010, ISO/IEC JTC 1 inició una votación para determinar si se debe iniciar un proyecto para crear un formato estándar internacional ISO/IEC compatible con ZIP. El proyecto propuesto, titulado Paquete de documentos, preveía un 'formato de archivo comprimido mínimo' compatible con ZIP. adecuado para su uso con una serie de estándares existentes, incluidos OpenDocument, Office Open XML y EPUB.

En 2015, ISO/IEC 21320-1 "Archivo contenedor de documentos — Parte 1: Núcleo" fue publicado que establece que "Los archivos contenedores de documentos son archivos Zip conformes". Requiere las siguientes restricciones principales del formato de archivo ZIP:

• Los archivos en archivos ZIP sólo pueden almacenarse sin comprimir o usar la compresión "deflate" (es decir, el método de compresión puede contener el valor "0" - almacenado o "8" - deflado).
• Las características de cifrado están prohibidas.
• Se prohíben las características de firma digital (de SES).
• Se prohíben las características de "datos pareados" (de PKPatchMaker).
• Los archivos pueden no abarcar múltiples volúmenes o ser segmentados.

Diseño

Los archivos

.ZIP son archivos que almacenan varios archivos. ZIP permite comprimir los archivos contenidos usando muchos métodos diferentes, así como simplemente almacenar un archivo sin comprimirlo. Cada archivo se almacena por separado, lo que permite comprimir diferentes archivos en el mismo archivo usando diferentes métodos. Debido a que los archivos en un archivo ZIP se comprimen individualmente, es posible extraerlos o agregar otros nuevos sin aplicar compresión o descompresión a todo el archivo. Esto contrasta con el formato de los archivos tar comprimidos, para los cuales dicho procesamiento de acceso aleatorio no es posible fácilmente.

Un directorio se coloca al final de un archivo ZIP. Esto identifica qué archivos están en el ZIP e identifica en qué parte del ZIP se encuentra ese archivo. Esto permite que los lectores ZIP carguen la lista de archivos sin leer todo el archivo ZIP. Los archivos ZIP también pueden incluir datos adicionales que no están relacionados con el archivo ZIP. Esto permite convertir un archivo ZIP en un archivo autoextraíble (aplicación que descomprime los datos que contiene), anteponiendo el código del programa a un archivo ZIP y marcando el archivo como ejecutable. Almacenar el catálogo al final también hace posible ocultar un archivo comprimido al agregarlo a un archivo inocuo, como un archivo de imagen GIF.

El formato .ZIP utiliza un algoritmo CRC de 32 bits e incluye dos copias de la estructura de directorios del archivo para brindar una mayor protección contra la pérdida de datos.

Estructura

Un archivo ZIP se identifica correctamente por la presencia de un registro de fin de directorio central que se encuentra al final de la estructura del archivo para permitir la fácil adición de nuevos archivos. Si el final del registro del directorio central indica un archivo no vacío, el nombre de cada archivo o directorio dentro del archivo debe especificarse en una entrada del directorio central, junto con otros metadatos sobre la entrada, y un offset en el archivo ZIP, apuntando a los datos de entrada reales. Esto permite realizar una lista de archivos del archivo con relativa rapidez, ya que no es necesario leer todo el archivo para ver la lista de archivos. Las entradas dentro del archivo ZIP también incluyen esta información, por redundancia, en un encabezado de archivo local. Debido a que se pueden agregar archivos ZIP, solo son válidos los archivos especificados en el directorio central al final del archivo. Escanear un archivo ZIP en busca de encabezados de archivos locales no es válido (excepto en el caso de archivos dañados), ya que el directorio central puede declarar que algunos archivos se han eliminado y otros archivos se han actualizado.

Por ejemplo, podemos comenzar con un archivo ZIP que contiene los archivos A, B y C. Luego, el archivo B se elimina y el C se actualiza. Esto se puede lograr simplemente agregando un nuevo archivo C al final del archivo ZIP original y agregando un nuevo directorio central que solo enumere el archivo A y el nuevo archivo C. Cuando se diseñó ZIP por primera vez, la transferencia de archivos por disquete era común, sin embargo, escribir en discos requería mucho tiempo. Si tuviera un archivo zip grande, que posiblemente abarcara varios discos, y solo necesitara actualizar algunos archivos, en lugar de leer y volver a escribir todos los archivos, sería mucho más rápido leer el directorio central anterior y agregar los archivos nuevos. luego agregue un directorio central actualizado.

El orden de las entradas del archivo en el directorio central no tiene por qué coincidir con el orden de las entradas del archivo en el archivo.

Cada entrada almacenada en un archivo ZIP se presenta con un encabezado de archivo local con información sobre el archivo, como el comentario, el tamaño y el nombre del archivo, seguido de "extra&#34 opcional.; campos de datos y, a continuación, los datos del archivo posiblemente comprimidos y posiblemente cifrados. El "Extra" Los campos de datos son la clave para la extensibilidad del formato ZIP. "Extra" Los campos se explotan para admitir el formato ZIP64, el cifrado AES compatible con WinZip, los atributos de archivo y las marcas de tiempo de archivo NTFS o Unix de mayor resolución. Otras extensiones son posibles a través de la opción "Extra" campo. La especificación requiere que las herramientas ZIP ignoren los campos adicionales que no reconocen.

El formato ZIP utiliza "firmas" específicas de 4 bytes; para denotar las diversas estructuras en el archivo. Cada entrada de archivo está marcada con una firma específica. El final del registro del directorio central se indica con su firma específica, y cada entrada en el directorio central comienza con la firma del encabezado del archivo central de 4 bytes.

No hay marcador BOF o EOF en la especificación ZIP. Convencionalmente, lo primero en un archivo ZIP es una entrada ZIP, que se puede identificar fácilmente por su firma de encabezado de archivo local. Sin embargo, este no es necesariamente el caso, ya que la especificación ZIP no lo requiere; en particular, un archivo autoextraíble comenzará con un encabezado de archivo ejecutable.

Las herramientas que leen correctamente los archivos ZIP deben buscar el final de la firma del registro del directorio central y luego, según corresponda, los demás registros del directorio central indicados. No deben buscar entradas desde la parte superior del archivo ZIP porque (como se mencionó anteriormente en esta sección) solo el directorio central especifica dónde comienza un fragmento de archivo y que no se ha eliminado. El escaneo podría dar lugar a falsos positivos, ya que el formato no prohíbe que haya otros datos entre fragmentos, ni que los flujos de datos de archivos contengan dichas firmas. Sin embargo, las herramientas que intentan recuperar datos de archivos ZIP dañados probablemente escanearán el archivo en busca de firmas de encabezados de archivos locales; esto se hace más difícil por el hecho de que el tamaño comprimido de un fragmento de archivo puede almacenarse después del fragmento de archivo, lo que dificulta el procesamiento secuencial.

La mayoría de las firmas terminan con el número entero corto 0x4b50, que se almacena en orden little-endian. Visto como una cadena ASCII, se lee 'PK', las iniciales del inventor Phil Katz. Por lo tanto, cuando se visualiza un archivo ZIP en un editor de texto, los dos primeros bytes del archivo suelen ser "PK". (Los ZIP autoextraíbles de DOS, OS/2 y Windows tienen un EXE antes del ZIP, así que comience con "MZ"; los ZIP autoextraíbles para otros sistemas operativos pueden ir precedidos de manera similar por un código ejecutable para extraer el archivo comprimido&# 39;s contenido en esa plataforma.)

La especificación .ZIP también admite la distribución de archivos en varios archivos del sistema de archivos. Originalmente pensada para el almacenamiento de archivos ZIP de gran tamaño en varios disquetes, esta característica ahora se usa para enviar archivos ZIP en partes por correo electrónico o por otros medios de transporte o extraíbles.

El sistema de archivos FAT de DOS tiene una resolución de marca de tiempo de solo dos segundos; Los registros de archivos ZIP imitan esto. Como resultado, la resolución de marca de tiempo incorporada de los archivos en un archivo ZIP es de solo dos segundos, aunque se pueden usar campos adicionales para almacenar marcas de tiempo más precisas. El formato ZIP no tiene noción de zona horaria, por lo que las marcas de tiempo solo son significativas si se sabe en qué zona horaria se crearon.

En septiembre de 2006, PKWARE publicó una revisión de la especificación ZIP que proporcionaba el almacenamiento de nombres de archivo mediante UTF-8, y finalmente agregó compatibilidad Unicode a ZIP.

Encabezados de archivos

Todos los valores de varios bytes en el encabezado se almacenan en orden de bytes little-endian. Todos los campos de longitud cuentan la longitud en bytes.

Encabezado de archivo local

Local file header

Offset	Bytes	Descripción
0	4	Firma de encabezado de archivo local = 0x04034b50 (PK♥♦ o "PK34")
4	2	Versión necesaria para extraer (mínimo)
6	2	Banda de bits de propósito general
8	2	Método de compresión; por ejemplo, ninguno = 0, DEFLATE = 8 (o "x08x00")
10	2	Tiempo de modificación del archivo
12	2	Fecha de última modificación
14	4	CRC-32 of uncompressed data
18	4	Tamaño comprimido (o 0xffffffff para ZIP64)
22	4	Tamaño no comprimido (o 0xffffffff para ZIP64)
26	2	Longitud del nombre del archivo (n)
28	2	Longitud extra de campo (m)
30	n	Nombre del archivo
30+n	m	Campo extra

El campo adicional contiene una variedad de datos opcionales, como atributos específicos del sistema operativo. Se divide en registros, cada uno con una firma de 16 bits como mínimo y una longitud de 16 bits. Un registro de campo adicional de un archivo local ZIP64, por ejemplo, tiene la firma 0x0001 y una longitud de 16 bytes (o más) para que puedan seguir dos valores de 64 bits (los tamaños comprimidos y sin comprimir). Otra extensión de archivo local común es 0x5455 (o "UT") que contiene marcas de tiempo UTC UNIX de 32 bits.

Esto es seguido inmediatamente por los datos comprimidos.

Descriptor de datos

Si se establece el bit en el desplazamiento 3 (0x08) del campo de banderas de propósito general, entonces el CRC-32 y los tamaños de archivo no se conocen cuando se escribe el encabezado. Si el archivo está en formato Zip64, los campos de tamaño comprimido y sin comprimir tienen una longitud de 8 bytes en lugar de 4 bytes (consulte la sección 4.3.9.2). Los campos equivalentes en el encabezado local (o en el campo adicional de información extendida Zip64 en el caso de archivos en formato Zip64) se completan con cero, y el CRC-32 y el tamaño se agregan en una estructura de 12 bytes (opcionalmente precedido por un Firma de 4 bytes) inmediatamente después de los datos comprimidos:

Descriptor de datos

Offset	Bytes	Descripción
0	0 o 4	Facultativo firma descriptor de datos = 0x08074b50
0 o 4	4	CRC-32 of uncompressed data
4 o 8	4 o 8	Tamaño comprimido
8 o 12 o 20	4 o 8	Tamaño no comprimido

Encabezado del archivo del directorio central

La entrada del directorio central es una forma expandida del encabezado local:

Encabezado del directorio central

Offset	Bytes	Descripción
0	4	Central directorio fichero header signature = 0x02014b50
4	2	Versión hecha
6	2	Versión necesaria para extraer (mínimo)
8	2	Banda de bits de propósito general
10	2	Método de compresión
12	2	Tiempo de modificación del archivo
14	2	Fecha de última modificación
16	4	CRC-32 of uncompressed data
20	4	Tamaño comprimido (o 0xffffffff para ZIP64)
24	4	Tamaño no comprimido (o 0xffffffff para ZIP64)
28	2	Longitud del nombre del archivo (n)
30	2	Longitud extra de campo (m)
32	2	Longitud del comentario del archivo (k)
34	2	Número de disco donde se inicia el archivo (o 0xffff para ZIP64)
36	2	Atributos de archivo interno
38	4	Atributos de archivo externo
42	4	offset relativo de cabecera local de archivos (o 0xffffffffff para ZIP64). Este es el número de bytes entre el inicio del primer disco en el que se produce el archivo, y el inicio del encabezado del archivo local. Esto permite que el software lea el directorio central para localizar la posición del archivo dentro del archivo ZIP.
46	n	Nombre del archivo
46+n	m	Campo extra
46+n+m	k	Archivo

Fin del registro del directorio central (EOCD)

Después de todas las entradas del directorio central, llega el registro del final del directorio central (EOCD), que marca el final del archivo ZIP:

Fin del registro del directorio central (EOCD)

Offset	Bytes	Descripción
0	4	Fin de la firma del directorio central = 0x06054b50
4	2	Número de este disco (o 0xffff para ZIP64)
6	2	Disk donde comienza el directorio central (o 0xffff para ZIP64)
8	2	Número de registros del directorio central en este disco (o 0xffff para ZIP64)
10	2	Número total de registros de directorios centrales (o 0xffff para ZIP64)
12	4	Tamaño del directorio central (bytes) (o 0xffffffffff para ZIP64)
16	4	Offset of start of central directory, relative to start of archive (or 0xffffffff para ZIP64)
20	2	Longitud del comentarion)
22	n	Comentario

Este orden permite crear un archivo ZIP en una sola pasada, pero el directorio central también se coloca al final del archivo para facilitar la eliminación de archivos de varias partes (por ejemplo, " múltiples archivos de disquete"), como se discutió anteriormente.

Métodos de compresión

La especificación de formato de archivo.ZIP documenta los siguientes métodos de compresión: almacenar (sin compresión), reducir (LZW), reducir (niveles 1 a 4; LZ77 + probabilístico), implosionar, desinflar, desinflar64, bzip2, LZMA, WavPack, PPMd y una variante LZ77 proporcionada por la instrucción IBM z/OS CMPSC. El método de compresión más utilizado es DEFLATE, que se describe en IETF RFC 1951.

Otros métodos mencionados, pero no documentados en detalle en la especificación incluyen: PKWARE DCL Implode (antigua IBM TERSE), nueva IBM TERSE, IBM LZ77 z Architecture (PFS) y una variante JPEG. Un "tokenización" El método estaba reservado para un tercero, pero nunca se agregó soporte.

La palabra Implode es usada en exceso por PKWARE: DCL/TERSE Implode es distinta de la antigua PKZIP Implode, una predecesora de Deflate. El DCL Implode no está documentado en parte debido a su naturaleza patentada en poder de IBM, pero Mark Adler, sin embargo, ha proporcionado un descompresor llamado "explosión" junto a zlib.

Cifrado

ZIP es compatible con un sistema de encriptación simétrica simple basado en contraseña generalmente conocido como ZipCrypto. Está documentado en la especificación ZIP y se sabe que tiene fallas graves. En particular, es vulnerable a ataques de texto sin formato conocido, que en algunos casos empeoran debido a implementaciones deficientes de generadores de números aleatorios. Las computadoras que ejecutan Microsoft Windows nativo sin archivadores de terceros pueden abrir, pero no crear, archivos ZIP encriptados con ZipCrypto, pero no pueden extraer el contenido de los archivos usando un cifrado diferente.

Las nuevas características, incluidos los nuevos métodos de compresión y cifrado (por ejemplo, AES), se han documentado en la especificación de formato de archivo ZIP desde la versión 5.2. 7-Zip y Xceed también usan un estándar abierto basado en AES desarrollado por WinZip ("AE-x" en APPNOTE), pero algunos proveedores usan otros formatos. PKWARE SecureZIP (SES, patentado) también es compatible con los métodos de cifrado RC2, RC4, DES, Triple DES, cifrado y autenticación basados en certificados digitales (X.509) y cifrado de encabezado de archivo. Sin embargo, está patentado (ver § Controversia de cifrado fuerte).

El cifrado de nombre de archivo se introduce en la especificación de formato de archivo.ZIP 6.2, que cifra los metadatos almacenados en la parte del directorio central de un archivo, pero las secciones de encabezado local permanecen sin cifrar. Un archivador compatible puede falsificar los datos del encabezado local al usar el cifrado de directorio central. A partir de la versión 6.2 de la especificación, los campos Método de compresión y Tamaño comprimido dentro del Encabezado local aún no están enmascarados.

ZIP64

El formato original .ZIP tenía un límite de 4 GB (2³² bytes) en varias cosas (tamaño sin comprimir de un archivo, tamaño comprimido de un archivo y el tamaño total del archivo), así como un límite de 65 535 (2¹⁶-1) entradas en un archivo ZIP. En la versión 4.5 de la especificación (que no es lo mismo que la v4.5 de ninguna herramienta en particular), PKWARE introdujo el "ZIP64" extensiones de formato para sortear estas limitaciones, aumentando los límites a 16 EB (2⁶⁴ bytes). En esencia, utiliza un "normal" entrada de directorio central para un archivo, seguida de un "zip64" entrada de directorio, que tiene los campos más grandes.

El formato del encabezado del archivo local (LOC) y la entrada del directorio central (CEN) son los mismos en ZIP y ZIP64. Sin embargo, ZIP64 especifica un campo extra que se puede agregar a esos registros a discreción del compresor, cuyo propósito es almacenar valores que no encajan en los registros LOC o CEN clásicos. Para indicar que los valores reales se almacenan en campos adicionales ZIP64, se establecen en 0xFFFF o 0xFFFFFFFF en el registro LOC o CEN correspondiente. Si una entrada no encaja en el registro LOC o CEN clásico, solo se requiere que esa entrada se mueva a un campo adicional ZIP64. Las demás entradas pueden permanecer en el registro clásico. Por lo tanto, es posible que no todas las entradas que se muestran en la siguiente tabla se almacenen en un campo adicional ZIP64. Sin embargo, si aparecen, su orden debe ser como se muestra en la tabla.

Zip64 información extendida campo extra

Offset	Bytes	Descripción
0	2	ID de encabezado 0x0001
2	2	Tamaño del pedazo de campo extra (8, 16, 24 o 28)
4	8	Tamaño original de archivo sin compresión
12	8	Tamaño de los datos comprimidos
20	8	Offset of local header record
28	4	Número del disco en el que comienza este archivo

Por otro lado, el formato de EOCD para ZIP64 es ligeramente diferente de la versión ZIP normal.

Zip64 Fin del registro del directorio central (EOCD64)

Offset	Bytes	Descripción
0	4	Fin de la firma central del directorio = 0x06064b50
4	8	Tamaño del EOCD64 menos 12
12	2	Versión hecha
14	2	Versión necesaria para extraer (mínimo)
16	4	Número de este disco
20	4	Disk donde comienza el directorio central
24	8	Número de registros del directorio central en este disco
32	8	Número total de registros de directorios centrales
40	8	Tamaño del directorio central (bytes)
48	8	Inauguración del directorio central, relativo al inicio del archivo
56	n	Comentario (hasta el tamaño de EOCD64)

Tampoco es necesariamente el último registro del archivo. Sigue un localizador de fin de directorio central (20 bytes adicionales al final).

El Explorador de archivos de Windows XP no es compatible con ZIP64, pero el Explorador de Windows Vista y versiones posteriores sí. Asimismo, algunas bibliotecas de extensión admiten ZIP64, como DotNetZip, QuaZIP e IO::Compress::Zip en Perl. El archivo zip integrado de Python lo admite desde la versión 2.5 y lo usa de forma predeterminada desde la versión 3.4. El java.util.zip incorporado de OpenJDK es compatible con ZIP64 desde la versión Java 7. La API Java de Android es compatible con ZIP64 desde Android 6.0. Notablemente, la utilidad de archivo de Mac OS Sierra no es compatible con ZIP64 y puede crear archivos dañados cuando se requiere ZIP64. Sin embargo, el comando ditto incluido con Mac OS descomprimirá los archivos ZIP64. Las versiones más recientes de Mac OS se envían con las herramientas de línea de comandos para comprimir y descomprimir de info-zip que sí son compatibles con Zip64: para verificar, ejecute zip -v y busque "ZIP64_SUPPORT".

Combinación con otros formatos de archivo

El formato de archivo .ZIP permite que un comentario contenga hasta 65 535 (2¹⁶−1) bytes de datos al final de el archivo después del directorio central. Además, debido a que el directorio central especifica el desplazamiento de cada archivo en el archivo con respecto al inicio, es posible que la primera entrada del archivo comience con un desplazamiento distinto de cero, aunque algunas herramientas, por ejemplo, gzip, no procesarán el archivo. archivos que no comienzan con una entrada de archivo en el desplazamiento cero.

Esto permite que se produzcan datos arbitrarios en el archivo tanto antes como después de los datos del archivo ZIP, y que una aplicación ZIP siga leyendo el archivo. Un efecto secundario de esto es que es posible crear un archivo que sea un archivo ZIP funcional y otro formato, siempre que el otro formato tolere datos arbitrarios al final, al principio o en el medio. Los archivos autoextraíbles (SFX), del formato compatible con WinZip, aprovechan esto, ya que son archivos ejecutables (.exe) que se ajustan a PKZIP AppNote.txt especificación, y puede ser leído por herramientas zip o bibliotecas compatibles.

Esta propiedad del formato .ZIP y del formato JAR, que es una variante de ZIP, puede explotarse para ocultar contenido no autorizado (como clases Java dañinas) dentro un archivo aparentemente inofensivo, como una imagen GIF cargada en la web. Este denominado exploit GIFAR ha demostrado ser un ataque eficaz contra aplicaciones web como Facebook.

Límites

El tamaño mínimo de un archivo .ZIP es de 22 bytes. Tal archivo zip vacío contiene solo un registro de fin de directorio central (EOCD):
[0x50,0x4B,0x05,0x06,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]

El tamaño máximo tanto para el archivo comprimido como para los archivos individuales que contiene es de 4 294 967 295 bytes (2³²−1 bytes, o 4 GB menos 1 byte) para ZIP estándar. Para ZIP64, el tamaño máximo es 18 446 744 073 709 551 615 bytes (2⁶⁴−1 bytes o 16 EB menos 1 byte).

Extensiones abiertas

Perfil optimizado para búsqueda (SOZip)

Se ha propuesto un perfil de archivo ZIP optimizado para búsqueda (SOZip) para el formato ZIP. Dicho archivo contiene uno o varios archivos comprimidos de Deflate que están organizados y anotados de tal manera que un lector compatible con SOZip puede realizar un acceso aleatorio (búsqueda) muy rápido dentro de un archivo comprimido. SOZip permite acceder a grandes archivos comprimidos directamente desde un archivo.zip sin descompresión previa. Combina el uso de descargas de bloque ZLib emitidas a intervalos regulares con un archivo de índice oculto que asigna compensaciones del archivo sin comprimir a compensaciones en la transmisión comprimida. Los lectores de ZIP que no conocen esa extensión pueden leer un archivo habilitado para SOZip normalmente e ignorar las características extendidas que admiten la capacidad de búsqueda eficiente.

Extensiones propietarias

Campo adicional

El formato de archivo

.ZIP incluye una función de campo adicional dentro de los encabezados de archivo, que se puede usar para almacenar datos adicionales no definidos por las especificaciones ZIP existentes, y que permiten a los archivadores compatibles que no no reconozca los campos para omitirlos con seguridad. Los ID de encabezado 0–31 están reservados para que los use PKWARE. Los ID restantes pueden ser utilizados por proveedores externos para uso exclusivo.

Fuerte controversia sobre el cifrado

Cuando se lanzó la versión beta pública de WinZip 9.0 en 2003, WinZip introdujo su propio cifrado AES-256, utilizando un formato de archivo diferente, junto con la documentación para la nueva especificación. Los estándares de cifrado en sí mismos no eran propietarios, pero PKWARE no había actualizado APPNOTE.TXT para incluir Strong Encryption Specification (SES) desde 2001, que había sido utilizado por las versiones 5.0 y 6.0 de PKZIP. El consultor técnico de WinZip, Kevin Kearney, y el gerente de producto de StuffIt, Mathew Covington, acusaron a PKWARE de retener SES, pero el director de tecnología de PKZIP, Jim Peterson, afirmó que el cifrado basado en certificados aún estaba incompleto.

En otro movimiento controvertido, PKWare solicitó una patente el 16 de julio de 2003 que describía un método para combinar ZIP y cifrado fuerte para crear un archivo seguro.

Al final, PKWARE y WinZip acordaron respaldar los productos del otro. El 21 de enero de 2004, PKWARE anunció la compatibilidad con el formato de compresión AES basado en WinZip. En una versión posterior de WinZip beta, podía admitir archivos ZIP basados en SES. PKWARE finalmente lanzó al público la versión 5.2 de la especificación de formato de archivo.ZIP, que documentaba SES. El proyecto de software libre 7-Zip también admite AES, pero no SES en archivos ZIP (al igual que su puerto POSIX p7zip).

Cuando se utiliza el cifrado AES en WinZip, el método de compresión siempre se establece en 99, y el método de compresión real se almacena en un campo de datos adicionales AES. Por el contrario, la especificación de cifrado fuerte almacena el método de compresión en el segmento de encabezado de archivo básico del encabezado local y el directorio central, a menos que se use el cifrado de directorio central para enmascarar/cifrar los metadatos.

Implementación

Existen numerosas herramientas .ZIP disponibles y numerosas bibliotecas .ZIP para varios entornos de programación; las licencias utilizadas incluyen software propietario y libre. WinZip, WinRAR, Info-ZIP, ZipGenius, 7-Zip, PeaZip y B1 Free Archiver son herramientas conocidas .ZIP, disponibles en varias plataformas. Algunas de esas herramientas tienen bibliotecas o interfaces programáticas.

Algunas bibliotecas de desarrollo con licencia bajo acuerdo de fuente abierta son libzip, libarchive e Info-ZIP. Para Java: Java Platform, Standard Edition contiene el paquete "java.util.zip" para manejar archivos estándar .ZIP; la biblioteca Zip64File admite específicamente archivos de gran tamaño (más de 4 GB) y trata los archivos .ZIP con acceso aleatorio; y la herramienta Apache Ant contiene una implementación más completa publicada bajo la licencia de software Apache.

Las implementaciones de Info-ZIP del formato .ZIP agregan compatibilidad con funciones del sistema de archivos Unix, como ID de usuarios y grupos, permisos de archivos y compatibilidad con enlaces simbólicos. La implementación de Apache Ant es consciente de esto en la medida en que puede crear archivos con permisos de Unix predefinidos. Las implementaciones de Info-ZIP también saben cómo usar las capacidades de corrección de errores integradas en el formato de compresión .ZIP. Algunos programas no lo hacen y fallarán en un archivo que tenga errores.

Las herramientas Info-ZIP de Windows también son compatibles con los permisos del sistema de archivos NTFS e intentarán convertir los permisos NTFS a los permisos Unix o viceversa al extraer archivos. Esto puede dar lugar a combinaciones potencialmente no deseadas, por ejemplo, la creación de archivos.exe en volúmenes NTFS con permiso de ejecución denegado.

Las versiones de Microsoft Windows han incluido compatibilidad con la compresión .ZIP en Explorer desde Microsoft Plus. se lanzó para Windows 98. Microsoft llama a esta función "Carpetas comprimidas". No todas las características de .ZIP son compatibles con la función de carpetas comprimidas de Windows. Por ejemplo, el cifrado no es compatible con la edición de Windows 10 Home, aunque puede descifrarse. La codificación de entrada Unicode no es compatible hasta Windows 7, mientras que los archivos divididos y divididos no se pueden leer ni escribir con la función de carpetas comprimidas, ni se admite el cifrado AES.

Microsoft Office comenzó a usar el formato de archivo zip en 2006 para sus archivos Office Open XML.docx,.xlsx,.pptx, etc., que se convirtió en el formato de archivo predeterminado con Microsoft Office 2007.

Legado

Existen muchos otros estándares y formatos que utilizan "zip" como parte de su nombre. Por ejemplo, zip es distinto de gzip, y este último se define en IETF RFC 1952. Tanto zip como gzip utilizan principalmente el algoritmo DEFLATE para la compresión. Del mismo modo, el formato ZLIB (IETF RFC 1950) también utiliza el algoritmo de compresión DEFLATE, pero especifica diferentes encabezados para la comprobación de errores y coherencia. Otros formatos y programas comunes con nombres similares y diferentes formatos nativos incluyen 7-Zip, bzip2 y rzip.

Preocupaciones

El factor de compresión máximo teórico para un flujo DEFLATE sin procesar es de aproximadamente 1032 a uno, pero al explotar el formato ZIP de manera no intencionada, se pueden construir archivos ZIP con proporciones de compresión de miles de millones a uno. Estas bombas zip se descomprimen en tamaños extremadamente grandes, abrumando la capacidad de la computadora en la que se descomprimen.

Los archivos.zip se pueden confundir fácilmente con las URL que terminan en el dominio de nivel superior.zip, que pueden ser explotados por usuarios malintencionados.