ZIP (formato de archivo)

La especificación del formato de archivo .ZIP tiene su propia numeración de versión, que no necesariamente coincide con la de la herramienta PKZIP, especialmente con PKZIP 6 o posterior. En varias ocasiones, PKWARE ha añadido funciones preliminares que permiten a los productos PKZIP extraer archivos comprimidos utilizando funciones avanzadas, pero los productos PKZIP que crean dichos archivos no están disponibles hasta la siguiente versión principal. Otras empresas u organizaciones dan soporte a las especificaciones de PKWARE a su propio ritmo.

La especificación del formato de archivo .ZIP se denomina formalmente "APPNOTE - Especificación del formato de archivo .ZIP" y se publica en el sitio web PKWARE.com desde finales de la década de 1990. ^{[ 11 ]} Varias versiones de la especificación no se publicaron. Las especificaciones de algunas características, como la compresión BZIP2 , la especificación de cifrado robusto y otras, fueron publicadas por PKWARE unos años después de su creación. La URL de la especificación en línea cambió varias veces en el sitio web de PKWARE.

Resumen de los principales avances en las distintas versiones del software y/o especificación PKWARE:

• 2.0: (1993) ^{[ 1 ]} Las entradas de archivo se pueden comprimir con DEFLATE y utilizar el cifrado PKWARE tradicional (ZipCrypto).
• 2.1: (1996) Soporte para compresión Deflate64 (mencionado en la APPNOTE 6.1.0 publicada mucho después). ^{[ 12 ]} Es posible que la APPNOTE no se haya publicado para la versión 2.1.
• 2.5: Compresión de implosión de PKWARE DCL. ^{[ 12 ]} Es posible que la nota de aplicación no se haya publicado para la versión 2.5.
• 2.5: Soporte para compresión Deflate64 (mencionado en manuales de usuario posteriores, por ejemplo, en 2004). ^{[ 13 ]}
• 4.0: (2000) Soporte de compresión Deflate64 (según información proporcionada por Jim Peterson, Científico Jefe de PKWARE, a la Biblioteca del Congreso; y APPNOTE 4.0). ^{[ 14 ] [ 15 ]}
• 4.5: (2001) ^{[ 16 ]} Formato zip de 64 bits documentado.
• 4.6: (2001) Compresión BZIP2 (no publicada en línea hasta la publicación de la NOTA DE APLICACIÓN 5.2)
• 5.0: (2002) SES: DES , Triple DES , RC2 , RC4 compatibles para cifrado (no publicado en línea hasta la publicación de la NOTA DE APLICACIÓN 5.2)
• 5.2: (2003) ^{[ 17 ] [ 18 ]} Compatibilidad con cifrado AES para SES (definido en la NOTA DE APLICACIÓN 5.1 que no se publicó en línea) y AES de WinZip ("AE-x"); versión corregida de RC2-64 compatible con el cifrado SES.
• 6.1: (2004) ^{[ 12 ]} Almacenamiento documentado de certificados.
• 6.2.0: (2004) ^{[ 19 ]} Cifrado de directorio central documentado.
• 6.3.0: (2006) ^{[ 20 ]} Almacenamiento documentado de nombres de archivo Unicode ( UTF-8 ). Lista ampliada de algoritmos de compresión compatibles ( LZMA , PPMd+ ), algoritmos de cifrado ( Blowfish , Twofish ) y hashes.
• 6.3.1: (2007) ^{[ 21 ]} Valores hash estándar corregidos para SHA-256/384/512.
• 6.3.2: (2007) ^{[ 22 ]} Método de compresión documentado 97 ( WavPack ).
• 6.3.3: (2012) ^{[ 23 ]} Cambios en el formato del documento para facilitar la referencia a la Nota de aplicación PKWARE desde otras normas utilizando métodos como el Informe explicativo de referencia (RER) de JTC 1 según lo indicado por JTC 1/SC 34 N 1621.
• 6.3.4: (2014) ^{[ 24 ]} Actualiza la dirección de la oficina de PKWARE, Inc.
• 6.3.5: (2018) ^{[ 25 ]} Métodos de compresión documentados 16, 96 y 99, época y precisión de marca de tiempo DOS, campos adicionales añadidos para claves y descifrado, así como errores tipográficos y aclaraciones.
• 6.3.6: (2019) ^{[ 26 ]} Error tipográfico corregido.
• 6.3.7: (2020) ^{[ 27 ]} Se agregó el ID 20 del método de compresión Zstandard .
• 6.3.8: (2020) ^{[ 28 ]} Se movió el ID del método de compresión Zstandard de 20 a 93, dejando obsoleto el anterior. Se documentaron los ID de método 94 y 95 ( MP3 y XZ respectivamente).
• 6.3.9: (2020) ^{[ 29 ]} Se corrigió un error tipográfico en la descripción de Alineación de flujo de datos.
• 6.3.10: (2022) ^{[ 30 ]} Se agregaron varios valores de atributos de z/OS para el APÉNDICE B. Se agregaron varias asignaciones de campos adicionales de terceros.

WinZip , a partir de la versión 12.1, utiliza la extensión .zipx para los archivos ZIP que emplean métodos de compresión más recientes que DEFLATE; concretamente, los métodos BZip, LZMA, PPMd, Jpeg y Wavpack. Los dos últimos se aplican a los tipos de archivo correspondientes cuando se selecciona la compresión "Mejor método". ^{[ 31 ] [ 32 ]}

En abril de 2010, el JTC 1 de ISO/IEC inició una votación para determinar si se debía iniciar un proyecto para crear un formato estándar internacional ISO/IEC compatible con ZIP. ^{[ 33 ]} El proyecto propuesto, titulado Document Packaging , contemplaba un "formato de archivo comprimido mínimo" compatible con ZIP, adecuado para su uso con varios estándares existentes, incluidos OpenDocument , Office Open XML y EPUB . Resolvería problemas como la necesidad de un estándar formal, la variedad de extensiones de ZIP, la inconveniencia de que una tecnología utilizada para estándares abiertos pudiera tener extensiones propietarias o patentes "submarinas" (es decir, que podrían surgir inesperadamente), la necesidad de una mejor internacionalización y el deseo de no fragmentar aún más la tecnología al pretender proporcionar una especificación alternativa al documento PKWARE APPNOTE.

En 2015, se publicó la norma ISO/IEC 21320-1 "Archivo contenedor de documentos - Parte 1: Núcleo", que establece que "Los archivos contenedores de documentos son archivos Zip conformes", haciendo referencia normativa al documento PKWARE APPNOTE. Requiere las siguientes restricciones principales del formato de archivo ZIP: ^{[ 34 ]}

• Los archivos en archivos ZIP solo pueden almacenarse sin comprimir o utilizando la compresión "deflate" (es decir, el método de compresión puede contener el valor "0" - almacenado o "8" - deflate). La patente del método de compresión "deflate" principal expiró a finales de 2010. ^{[ 35 ]}
• Las funciones de cifrado están prohibidas.
• Las funciones de firma digital (de SES) están prohibidas.
• Las funciones de "datos parcheados" (de PKPatchMaker) están prohibidas.
• Los archivos no pueden abarcar varios volúmenes ni estar segmentados.

Un archivo ZIP se identifica correctamente por la presencia de un registro de fin de directorio central , ubicado al final de la estructura del archivo para facilitar la adición de nuevos archivos. Si este registro indica que el archivo no está 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 desplazamiento dentro del archivo ZIP que apunte a los datos de la entrada. Esto permite obtener una lista de archivos del archivo con relativa rapidez, ya que no es necesario leer todo el archivo para ver la lista. Las entradas dentro del archivo ZIP también incluyen esta información, por redundancia, en un encabezado de archivo local . Dado que se pueden añadir archivos a los archivos ZIP, solo son válidos los archivos especificados en el directorio central al final del archivo. No es válido buscar encabezados de archivo locales en un archivo ZIP (excepto en el caso de archivos dañados), ya que el directorio central puede indicar que algunos archivos se han eliminado y otros se han actualizado.

Por ejemplo, podemos comenzar con un archivo ZIP que contenga los archivos A, B y C. A continuación, se elimina el archivo B y se actualiza el C. Esto se puede lograr simplemente añadiendo un nuevo archivo C al final del archivo ZIP original y agregando un nuevo directorio central que solo incluya el archivo A y el nuevo archivo C. Cuando se diseñó ZIP, la transferencia de archivos mediante disquetes era común, pero escribir en los discos era muy lento. Si se tenía un archivo ZIP grande, que posiblemente abarcara varios discos, y solo se necesitaba actualizar algunos archivos, en lugar de leer y reescribir todos los archivos, sería mucho más rápido leer el antiguo directorio central, añadir los nuevos archivos y luego añadir un directorio central actualizado.

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

Cada entrada almacenada en un archivo ZIP comienza con una cabecera local que contiene información sobre el archivo, como el comentario, el tamaño y el nombre, seguida de campos de datos adicionales opcionales y, a continuación, los datos del archivo, que pueden estar comprimidos o cifrados. Los campos de datos adicionales son clave para la extensibilidad del formato ZIP. Estos campos se utilizan para admitir el formato ZIP64, el cifrado AES compatible con WinZip, los atributos de archivo y las marcas de tiempo de archivos NTFS o Unix de mayor resolución. Es posible añadir otras extensiones mediante el campo adicional. Las herramientas ZIP deben, según la especificación, ignorar los campos adicionales que no reconozcan.

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

La especificación ZIP no incluye marcadores BOF ni EOF. Tradicionalmente, lo primero que contiene un archivo ZIP es una entrada ZIP, que se identifica fácilmente por la firma de su encabezado de archivo local . Sin embargo, esto no siempre es así, ya que la especificación ZIP no lo exige; en particular, un archivo autoextraíble comenzará con un encabezado de archivo ejecutable.

Las herramientas que leen correctamente los archivos ZIP deben buscar la firma del registro del directorio central al final y, posteriormente, los demás registros del directorio central indicados. No deben buscar entradas desde la parte superior del archivo ZIP, ya que (como se mencionó anteriormente en esta sección) solo el directorio central especifica dónde comienza un fragmento de archivo y que este no ha sido eliminado. El escaneo podría generar falsos positivos, dado que el formato no prohíbe que haya otros datos entre los fragmentos, ni que los flujos de datos del archivo contengan dichas firmas. Sin embargo, las herramientas que intentan recuperar datos de archivos ZIP dañados probablemente buscarán firmas de encabezado de archivo locales en el archivo; esto se complica debido a que el tamaño comprimido de un fragmento de archivo puede almacenarse después del fragmento, lo que dificulta el procesamiento secuencial.

La mayoría de las firmas terminan con el 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 archivos ZIP autoextraíbles de DOS, OS/2 y Windows tienen un archivo EXE antes del ZIP, por lo que comienzan con "MZ"; los archivos ZIP autoextraíbles para otros sistemas operativos pueden ir precedidos de un código ejecutable para extraer el contenido del archivo en esa plataforma).

La especificación .ZIP también admite la distribución de archivos comprimidos en varios sistemas de archivos. Originalmente concebida para almacenar archivos ZIP grandes en varios disquetes , esta función ahora se utiliza para enviar archivos ZIP por partes por correo electrónico o a través de otros medios de transporte o soportes 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 integrada 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 en cuenta la zona horaria , por lo que las marcas de tiempo solo tienen sentido si se conoce la zona horaria en la que se crearon.

En septiembre de 2006, PKWARE publicó una revisión de la especificación ZIP que permitía el almacenamiento de nombres de archivo utilizando UTF-8 , añadiendo finalmente compatibilidad con Unicode a ZIP. ^{[ 20 ]}

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

La especificación del formato de archivo .ZIP documenta los siguientes métodos de compresión: Almacenar (sin compresión), Reducir ( LZW ), Reducir (niveles 1–4; LZ77 + probabilístico), Implosionar, Deflate, Deflate64, bzip2 , LZMA , Zstandard , WavPack , PPMd y una variante LZ77 proporcionada por la instrucción CMPSC de IBM z/OS . ^{[ 39 ] [ 30 ]} 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 (antiguo IBM TERSE), nuevo IBM TERSE , IBM LZ77 z Architecture (PFS) y una variante JPEG. Se reservó un método "Tokenizar" para un tercero, pero nunca se le dio soporte. ^{[ 25 ]}

PKWARE abusa del término Implode : el Implode de DCL/TERSE es distinto del antiguo Implode de PKZIP, predecesor de Deflate. El Implode de DCL no está documentado en parte debido a su naturaleza propietaria, propiedad de IBM, pero Mark Adler ha proporcionado un descompresor llamado "blast" junto con zlib. ^{[ 40 ]}

ZIP admite un sistema de cifrado simétrico simple basado en contraseña , generalmente conocido como ZipCrypto. Está documentado en la especificación ZIP y se sabe que tiene graves fallos. En particular, es vulnerable a ataques de texto plano conocido , que en algunos casos se ven agravados por implementaciones deficientes de generadores de números aleatorios . ^{[ 5 ]} Los ordenadores que ejecutan Microsoft Windows nativo sin compresores de terceros pueden abrir, pero no crear, archivos ZIP cifrados con ZipCrypto, pero no pueden extraer el contenido de archivos que utilicen otro cifrado. ^{[ 41 ]}

Las nuevas características, incluidos los nuevos métodos de compresión y cifrado (por ejemplo, AES ), se han documentado en la Especificación del formato de archivo ZIP desde la versión 5.2. Un estándar abierto basado en AES desarrollado por WinZip ("AE-x" en APPNOTE) también es utilizado por 7-Zip y Xceed , pero algunos proveedores utilizan otros formatos. ^{[ 42 ]} PKWARE SecureZIP (SES, propietario) también admite 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 (véase §  Controversia sobre el cifrado fuerte ). ^{[ 43 ]}

El cifrado de nombres de archivo se introduce en la especificación de formato de archivo .ZIP 6.2, que cifra los metadatos almacenados en la sección del directorio central de un archivo comprimido, pero las secciones del encabezado local permanecen sin cifrar. Un compresor compatible puede falsificar los datos del encabezado local al usar el cifrado del 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.

El formato .ZIP original tenía un límite de 4 GiB ( 2³² ^bytes ) en varios aspectos (tamaño sin comprimir de un archivo, tamaño comprimido de un archivo y 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 la misma que la v4.5 de ninguna herramienta en particular), PKWARE introdujo las extensiones de formato "ZIP64" para sortear estas limitaciones, aumentando los límites a 16 EiB ( 2⁶⁴ ^bytes ). En esencia, utiliza una entrada de directorio central "normal" para un archivo, seguida de una entrada de directorio "zip64" opcional, que contiene los campos más grandes. ^{[ 44 ]}  

El formato del encabezado de archivo local (LOC) y del encabezado de archivo de directorio central (CDFH) es el mismo en ZIP y ZIP64. Sin embargo, ZIP64 especifica un campo adicional que el compresor puede agregar a dichos registros, con el fin de almacenar valores que no caben en los registros LOC o CDFH clásicos. Para indicar que los valores reales se almacenan en campos adicionales de ZIP64, se les asigna el valor 0xFFFF o 0xFFFFFFFF en el registro LOC o CDFH correspondiente. Si una entrada no cabe en el registro LOC o CDFH clásico, solo esa entrada debe trasladarse a un campo adicional de ZIP64. Las demás entradas pueden permanecer en el registro clásico. Por lo tanto, no todas las entradas que se muestran en la siguiente tabla se almacenarán en un campo adicional de ZIP64. Sin embargo, si aparecen, su orden debe ser el que se muestra en la tabla.

Por otro lado, el formato de EOCD para ZIP64 es ligeramente diferente de la versión ZIP normal. ^{[ 37 ]}

El EOCD64 no es necesariamente el último registro del archivo. Le sigue un localizador de fin de directorio central de 20 bytes y el registro EOCD clásico.

El Explorador de archivos en Windows XP no admite ZIP64, pero el Explorador en Windows Vista y versiones posteriores sí. Asimismo, algunas bibliotecas de extensión admiten ZIP64, como DotNetZip, QuaZIP ^{[ 45 ]} e IO::Compress::Zip en Perl. El zipfile integrado de Python lo admite desde la versión 2.5 y lo usa por defecto desde la versión 3.4. ^{[ 46 ]} El java.util.zip integrado de OpenJDK admite ZIP64 desde la versión Java 7. [ ^{47 ] La} API de Java de Android admite ZIP64 desde Android 6.0. ^{[ 48 ]} La utilidad de archivo de Mac OS Sierra no admite ZIP64 y puede crear archivos corruptos cuando se requiere ZIP64. ^{[ 49 ]} Sin embargo, el comando ditto incluido en Mac OS descomprime archivos ZIP64. ^{[ 50 ]} Las versiones más recientes de Mac OS incluyen las herramientas de línea de comandos zip y unzip de info-zip que sí admiten Zip64: para verificarlo, ejecute zip -v y busque "ZIP64_SUPPORT".

El formato de archivo .ZIP permite que un comentario contenga hasta 65 535 ( ^2¹⁶ − 1 ) bytes de datos al final del archivo, después del directorio central. ^{[ 37 ]} Además, debido a que el directorio central especifica el desplazamiento de cada archivo en el archivo comprimido con respecto al inicio, es posible que la primera entrada del archivo comience en un desplazamiento distinto de cero, aunque algunas herramientas podrían no procesar archivos comprimidos que no comiencen con una entrada de archivo en el desplazamiento cero. El programa gzip , por ejemplo, puede extraer una entrada de un archivo .ZIP si se encuentra en el desplazamiento cero.

Esto permite que aparezcan datos arbitrarios en el archivo, tanto antes como después de los datos del archivo ZIP, y que este pueda ser leído por una aplicación ZIP. Como consecuencia, es posible crear un archivo que sea a la vez un archivo ZIP funcional y de otro formato, siempre que este último admita datos arbitrarios al principio, al final o en la mitad. Los archivos autoextraíbles (SFX), compatibles con WinZip, aprovechan esta característica, ya que son archivos ejecutables ( .exe ) que cumplen con la especificación PKZIP AppNote.txt y pueden ser leídos por herramientas o bibliotecas ZIP compatibles.

Esta propiedad del formato .ZIP , y del formato JAR , que es una variante de ZIP, puede explotarse para ocultar contenido malicioso (como clases Java dañinas) dentro de un archivo aparentemente inofensivo, como una imagen GIF subida a la web. Se ha demostrado que esta vulnerabilidad, conocida como GIFAR , es un ataque eficaz contra aplicaciones web como Facebook. ^{[ 51 ]}

El tamaño mínimo de un archivo .ZIP es de 22 bytes. Un archivo zip vacío de este tipo contiene únicamente un registro de fin de directorio central (EOCD):50 4B 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

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 GiB menos 1 byte) para ZIP estándar. Para ZIP64, el tamaño máximo es de 18.446.744.073.709.551.615 bytes (2⁶⁴ −} 1 bytes ,  o 16 EiB menos  1 byte). ^{[ 52 ]}

Las versiones del formato anteriores a la 6.3.0 no admitían el almacenamiento de nombres de archivo en Unicode . ^{[ 64 ]} Según el estándar, ^{[ 64 ]} los nombres de archivo deberían almacenarse en la codificación CP437 , que es estándar para el IBM PC , ^{[ 64 ]} pero en la práctica, los archivadores de DOS utilizaban la codificación de caracteres instalada del sistema . El archivador integrado de Windows hasta la versión 11 también utilizaba la codificación "ANSI" del sistema correspondiente al idioma del sistema seleccionado para la compatibilidad con versiones anteriores de DOS al crear archivos.

Posteriormente, el estándar se actualizó para incluir dos opciones para almacenar nombres de archivo en Unicode: 1) cuando el bit 11 en el campo de indicador de bit de propósito general está activado, el nombre de archivo en el campo "Nombre de archivo" del encabezado debe considerarse como UTF-8 en lugar de una codificación de un solo byte, y 2) se agregó el campo adicional de ruta Unicode para almacenar el nombre de archivo en codificación UTF-8. ^{[ 64 ]} El siguiente algoritmo tiene en cuenta tanto el nuevo campo "nombre de archivo" como las prácticas históricas para extraer correctamente archivos con nombres que contienen caracteres no ingleses: ^{[ 65 ]}

1. Compruebe la presencia del campo adicional de ruta Unicode y, si existe, utilice el nombre de archivo que contiene, codificado en UTF-8.
2. Compruebe la presencia del indicador 11 en el campo de indicador de bits de propósito general y, si está activado, considere que la codificación del nombre de archivo en el campo "Nombre de archivo" es UTF-8.
3. Si el campo "sistema operativo de empaquetado" contiene el valor 11 (NTFS, Windows) y el valor del campo "versión del empaquetador" es mayor o igual a 20, considere que la codificación del nombre de archivo en el campo "nombre de archivo" es la codificación ANSI (Windows) correspondiente a la configuración regional del sistema, si se puede determinar; de lo contrario, utilice CP437.
4. Si el campo "sistema operativo de empaquetado" contiene el valor 0 (FAT, DOS) y el valor del campo "versión del empaquetador" está entre 25 y 40 inclusive, considere que la codificación del nombre de archivo en el campo "Nombre de archivo" del encabezado local es la codificación ANSI (Windows) y en el campo "Nombre de archivo" del encabezado central es la codificación OEM (DOS), correspondiente a la configuración regional del sistema si se puede determinar; de lo contrario, utilice CP437.
5. En otros casos, si el campo "Empaquetado del sistema operativo" contiene el valor 0 (FAT, DOS), 6 (HPFS, OS/2) o 11 (NTFS, Windows), considere que la codificación del nombre de archivo en el campo "Nombre de archivo" es la codificación OEM (DOS), que corresponde a la configuración regional del sistema si se puede determinar; de lo contrario, utilice CP437.
6. En todos los demás casos, considere que la codificación del nombre de archivo en el campo "Nombre de archivo" es la codificación del sistema operativo en el que se está ejecutando el descompresor.

Si se utiliza una codificación incorrecta para decodificar los nombres de archivo, los usuarios terminan viendo un conjunto caótico de caracteres, conocido como " mojibake ", en lugar de letras del alfabeto nacional. El algoritmo anterior intenta evitar este resultado. En lugar de la "configuración regional del sistema" y la "codificación del sistema", algunos programas permiten al usuario seleccionar la codificación no Unicode deseada.

En 2016, este problema se resolvió en el gestor de archivos y archivados far2l para Linux, BSD y Mac. ^{[ 66 ]} En 2024, se añadió una solución similar ^{[ 67 ]} a la versión de 7zip utilizada en la distribución Debian y sus derivados, y a la versión de unzip utilizada en la distribución Ubuntu y sus derivados. ^{[ 65 ]}