ZIP (formato de archivo)

ZIP es un formato de archivo de almacenamiento que admite la compresión de datos sin pérdida . 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. ^[2] como reemplazo del formato de compresión ARC anterior de Thom Henderson. El formato ZIP fue rápidamente compatible con muchas utilidades de software distintas de PKZIP. Microsoft ha incluido soporte ZIP integrado (bajo el nombre de "carpetas comprimidas") en versiones de Microsoft Windows desde 1998 a través del complemento "Plus! 98" para Windows 98. El soporte nativo se agregó a partir del año 2000 en Windows ME. ^{[ cita requerida ]} Apple ha incluido soporte ZIP integrado en Mac OS X 10.3 (a través de BOMArchiveHelper, ahora Archive Utility ) y posteriores. La mayoría de los sistemas operativos gratuitos tienen soporte incorporado para ZIP de manera similar a Windows y macOS.

Los archivos ZIP generalmente usan las extensiones de archivo .zip o .ZIP y el tipo de medio MIME . ^[1] Muchos programas usan 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 presenta de manera destacada una cremallera .application/zip

El formato de archivo .ZIP fue diseñado por Phil Katz de PKWARE y Gary Conway de Infinity Design Concepts. El formato fue creado después de que Systems Enhancement Associates (SEA) presentara una demanda contra PKWARE alegando que los productos de archivo de esta última, llamados PKARC, eran derivados del sistema de archivo ARC de SEA. ^[3] El nombre "zip" (que significa "moverse a alta velocidad") fue sugerido por el amigo de Katz, Robert Mahoney. ^[4] 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. ^[4] La primera versión conocida de la especificación del formato de archivo .ZIP se publicó por primera vez como parte del paquete PKZIP ^{0.9 bajo el archivo APPNOTE.TXT en 1989. [ cita requerida ]} Al distribuir el formato de archivo zip dentro de APPNOTE.TXT, la compatibilidad con el formato de archivo zip proliferó ampliamente en Internet pública durante la década de 1990. ^[5]

PKWARE e Infinity Design Concepts publicaron un comunicado de prensa conjunto el 14 de febrero de 1989, liberando el formato de archivo .ZIP al dominio público . ^{[6] [7] [8] [9] [10]}

La especificación del formato de archivo .ZIP tiene su propio número de versión, que no necesariamente corresponde a los números de versión de la herramienta PKZIP, especialmente con PKZIP 6 o posterior. En varias ocasiones, PKWARE ha agregado características preliminares que permiten que los productos PKZIP extraigan archivos utilizando funciones avanzadas, pero los productos PKZIP que crean dichos archivos no están disponibles hasta la próxima versión principal. Otras empresas u organizaciones respaldan las especificaciones 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 los años 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 fuerte y otras, fueron publicadas por PKWARE unos años después de su creación. La URL de la especificación en línea se modificó 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) ^[1] Las entradas de archivo se pueden comprimir con DEFLATE y utilizar el cifrado PKWARE tradicional (ZipCrypto).
• 2.1: (1996) Compresión Deflate64
• 4.5: (2001) ^[12] Formato zip de 64 bits documentado.
• 4.6: (2001) Compresión BZIP2 (no publicada en línea hasta la publicación de APPNOTE 5.2)
• 5.0: (2002) SES: DES , Triple DES , RC2 , RC4 compatibles con cifrado (no publicado en línea hasta la publicación de APPNOTE 5.2)
• 5.2: (2003) ^{[13] [14]} Compatibilidad con cifrado AES para SES (definido en APPNOTE 5.1 ​​que no se publicó en línea) y AES de WinZip ("AE-x"); versión corregida de RC2-64 compatible con cifrado SES.
• 6.1: (2004) ^[15] Almacenamiento de certificados documentados.
• 6.2.0: (2004) ^[16] Cifrado de directorio central documentado.
• 6.3.0: (2006) ^[17] Almacenamiento documentado de nombres de archivo Unicode ( UTF-8 ). Lista ampliada de algoritmos de compresión ( LZMA , PPMd+ ), algoritmos de cifrado ( Blowfish , Twofish ) y hashes admitidos.
• 6.3.1: (2007) ^[18] Valores hash estándar corregidos para SHA-256/384/512.
• 6.3.2: (2007) ^[19] Método de compresión documentado 97 ( WavPack ).
• 6.3.3: (2012) ^[20] 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) JTC 1 según lo indicado por JTC 1/SC 34 N 1621.
• 6.3.4: (2014) ^[21] Actualiza la dirección de la oficina de PKWARE, Inc.
• 6.3.5: (2018) ^[22] Se documentaron los métodos de compresión 16, 96 y 99, la época y precisión de la marca de tiempo DOS, se agregaron campos adicionales para claves y descifrado, así como errores tipográficos y aclaraciones.
• 6.3.6: (2019) ^[23] Error tipográfico corregido.
• 6.3.7: (2020) ^[24] Se agregó el método de compresión Zstandard ID 20.
• 6.3.8: (2020) ^[25] Se trasladó el ID del método de compresión Zstandard de 20 a 93, lo que dejó obsoleto el anterior. Se documentaron los ID de método 94 y 95 ( MP3 y XZ respectivamente).
• 6.3.9: (2020) ^[26] Se corrigió un error tipográfico en la descripción de Alineación del flujo de datos.
• 6.3.10: (2022) ^[27] Se agregaron varios valores de atributos 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 utilizan métodos de compresión más nuevos que DEFLATE; específicamente, los métodos BZip, LZMA, PPMd, Jpeg y Wavpack. Los dos últimos se aplican a los tipos de archivos apropiados cuando se selecciona la compresión "Mejor método". ^{[28] [29]}

En abril de 2010, el ISO/IEC JTC 1 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. ^[30] El proyecto propuesto, titulado Document Packaging , 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 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". Requiere las siguientes restricciones principales del formato de archivo ZIP: ^[31]

• Los archivos en archivos ZIP solo se pueden almacenar sin comprimir o utilizando la compresión "deflate" (es decir, el método de compresión puede contener el valor "0" - almacenado o "8" - deflacionado).
• 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.

Los archivos .ZIP son archivos que almacenan varios archivos. ZIP permite comprimir los archivos que contienen mediante 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 mediante 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 archivos tar comprimidos , para los cuales este procesamiento de acceso aleatorio no es fácil.

Al final de un archivo ZIP se coloca un directorio que identifica qué archivos hay en el ZIP y 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 que un archivo ZIP se convierta en un archivo autoextraíble (aplicación que descomprime los datos que contiene), al anteponer el código del programa a un archivo ZIP y marcar el archivo como ejecutable. Almacenar el catálogo al final también permite ocultar un archivo comprimido agregándolo 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 los metadatos de cada entrada para proporcionar una mayor protección contra la pérdida de datos. El algoritmo CRC-32 fue aportado por David Schwaderer y se puede encontrar en su libro "C Programmers Guide to NetBIOS" publicado por Howard W. Sams & Co. Inc. ^[32]

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 registro de fin de directorio central indica un archivo no vacío, el nombre de cada archivo o directorio dentro del archivo debe especificarse en una entrada de directorio central , junto con otros metadatos sobre la entrada y un desplazamiento dentro del archivo ZIP, que apunte a los datos de la entrada real. Esto permite realizar un listado 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 a los 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 se han actualizado.

Por ejemplo, podemos empezar con un archivo ZIP que contiene los archivos A, B y C. Luego, se elimina el archivo B y se actualiza C. Esto se puede lograr simplemente agregando 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 por primera vez, transferir archivos mediante disquetes era algo común, pero escribir en discos consumí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 reescribir todos los archivos, sería sustancialmente más rápido simplemente leer el directorio central anterior, agregar los archivos nuevos y luego agregar un directorio central actualizado.

El orden de las entradas de archivo en el directorio central no necesita coincidir con el orden de las entradas de archivo en el archivo.

Cada entrada almacenada en un archivo ZIP se introduce mediante un encabezado de archivo local con información sobre el archivo, como el comentario, el tamaño y el nombre del archivo, seguido de campos de datos "extra" opcionales y, a continuación, los datos del archivo, posiblemente comprimidos y posiblemente cifrados. Los campos de datos "extra" son la clave para la extensibilidad del formato ZIP. Los campos "extra" se aprovechan 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. Otras extensiones son posibles a través del campo "extra". La especificación exige que las herramientas ZIP ignoren los campos extra que no reconocen.

El formato ZIP utiliza "firmas" específicas de 4 bytes para indicar las distintas estructuras del archivo. Cada entrada del 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 del directorio central comienza con la firma de encabezado del archivo central de 4 bytes .

En la especificación ZIP no hay ningún marcador BOF o EOF. Por lo general, lo primero que hay en un archivo ZIP es una entrada ZIP, que se puede identificar fácilmente por su firma de encabezado de archivo local . Sin embargo, esto no es necesariamente 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 el final de la firma del registro del directorio central y luego, según corresponda, los otros 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 puede llevar a falsos positivos, ya que el formato no prohíbe que haya otros datos entre los 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 encabezado de archivo 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 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 ve un archivo ZIP en un editor de texto, los primeros dos bytes del archivo suelen ser "PK". (Los ZIP autoextraíbles de DOS, OS/2 y Windows tienen un EXE antes del ZIP, por lo que comienzan con "MZ"; los ZIP autoextraíbles para otros sistemas operativos pueden estar precedidos de un código ejecutable para extraer el contenido del archivo en esa plataforma).

La especificación .ZIP también permite distribuir archivos entre varios archivos del sistema de archivos. Esta característica, que en un principio estaba pensada para el almacenamiento de archivos ZIP de gran tamaño en varios disquetes , ahora se utiliza 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 preveía el almacenamiento de nombres de archivos utilizando UTF-8 , agregando finalmente compatibilidad Unicode a ZIP. ^[17]

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

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), de modo que pueden seguir dos valores de 64 bits (los tamaños sin comprimir y comprimido). Otra extensión de archivo local común es 0x5455 (o "UT"), que contiene marcas de tiempo UNIX UTC de 32 bits.

A esto le siguen inmediatamente los datos comprimidos.

Si el bit en el desplazamiento 3 (0x08) del campo de indicadores de propósito general está establecido, 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 8 bytes de longitud en lugar de 4 bytes (consulte la sección 4.3.9.2 ^[34] ). 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 rellenan con ceros, y el CRC-32 y el tamaño se añaden en una estructura de 12 bytes (precedida opcionalmente por una firma de 4 bytes) inmediatamente después de los datos comprimidos:

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

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

Este ordenamiento 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 archivos de varias partes (por ejemplo, "varios disquetes") , como se explicó anteriormente.

La especificación del formato de archivo .ZIP documenta los siguientes métodos de compresión: Store (sin compresión), Shrink ( LZW ), Reduce (niveles 1–4; LZ77 + probabilístico), Implode, Deflate, Deflate64, bzip2 , LZMA , Zstandard , WavPack , PPMd y una variante LZ77 proporcionada por la instrucción IBM z/OS CMPSC. ^{[35] [27]} El método de compresión más comúnmente 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. Un método "Tokenize" se reservó para un tercero, pero nunca se agregó soporte. ^[22]

La palabra Implode se usa en exceso en PKWARE: el DCL/TERSE Implode es distinto del antiguo PKZIP Implode, predecesor de Deflate. El DCL Implode 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. ^[36]

ZIP admite un sistema de cifrado simétrico basado en contraseñas conocido generalmente como ZipCrypto. Está documentado en la especificación ZIP y se sabe que tiene graves defectos. En particular, es vulnerable a ataques de texto plano conocidos , que en algunos casos se ven agravados por implementaciones deficientes de generadores de números aleatorios . ^{[5] Las computadoras que funcionan con} Microsoft Windows nativo sin archivadores de terceros pueden abrir, pero no crear, archivos ZIP cifrados con ZipCrypto, pero no pueden extraer el contenido de los archivos que utilizan un cifrado diferente. ^[37]

Desde la versión 5.2, se han documentado nuevas características, incluidos nuevos métodos de compresión y cifrado (por ejemplo, AES ), en la Especificación de formato de archivo ZIP. 7-Zip y Xceed también utilizan un estándar abierto basado en AES desarrollado por WinZip ("AE-x" en APPNOTE) , pero algunos proveedores utilizan otros formatos. ^[38] PKWARE SecureZIP (SES, propietario) también admite 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 (consulte § Controversia sobre cifrado fuerte). ^[39]

El cifrado de nombres de archivo se introdujo 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 del encabezado local permanecen sin cifrar. Un archivador compatible puede falsificar los datos del encabezado local cuando utiliza 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 GB (2,32 ^{bytes ) en varias cosas (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,16} -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 superar estas limitaciones, aumentando los límites a 16  EB (2,64 ^bytes ). En esencia, utiliza una entrada de directorio central "normal" para un archivo, seguida de una entrada de directorio "zip64" opcional, que tiene los campos más grandes. ^[40]

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 se puede agregar a esos registros a discreción del compresor, cuyo propósito es 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 establecen en 0xFFFF o 0xFFFFFFFF en el registro LOC o CDFH correspondiente. Si una entrada no cabe en el registro LOC o CDFH clásico, solo se requiere mover esa entrada a un campo adicional de ZIP64. Las otras entradas pueden permanecer en el registro clásico. Por lo tanto, no todas las entradas que se muestran en la siguiente tabla pueden almacenarse 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. ^[33]

Tampoco es necesariamente el último registro del archivo. A continuación aparece 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 posteriores sí. ^{[ cita requerida ]} Del mismo modo, algunas bibliotecas de extensión son compatibles con ZIP64, como DotNetZip, QuaZIP ^[41] e IO::Compress::Zip en Perl. El zipfile integrado de Python lo admite desde la versión 2.5 y lo usa de forma predeterminada desde la 3.4. ^[42] El java.util.zip integrado de OpenJDK es compatible con ZIP64 desde la versión Java 7. [ ^{43] La API Java} de Android es compatible con ZIP64 desde Android 6.0. ^[44] La utilidad Archive de Mac OS Sierra no es compatible con ZIP64 y puede crear archivos dañados cuando se necesitaría ZIP64. ^[45] Sin embargo, el comando ditto que viene con Mac OS descomprimirá los archivos ZIP64. ^[46] Más reciente ^{[ ¿cuándo? ]} Las versiones de Mac OS se entregan con las herramientas de línea de comandos zip y unzip de info-zip que admiten Zip64: para verificar, ejecute zip -v y busque "ZIP64_SUPPORT".

El formato de archivo .ZIP permite que un comentario que contenga hasta 65.535 (2 ¹⁶ −1) bytes de datos aparezca al final del archivo después del directorio central. ^[33] 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 en un desplazamiento distinto de cero, aunque algunas herramientas, por ejemplo gzip , no procesarán archivos de archivo que no comiencen con una entrada de archivo 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 el archivo pueda ser leído por una aplicación ZIP. Un efecto secundario de esto es que es posible crear un archivo que sea a la vez un archivo ZIP funcional y otro formato, siempre que el otro formato tolere datos arbitrarios al final, al principio o al medio. Los archivos autoextraíbles (SFX), del formato compatible con WinZip, aprovechan esto, 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 ser explotada para ocultar contenido malicioso (como clases Java dañinas) dentro de un archivo aparentemente inofensivo, como una imagen GIF cargada en la web. Se ha demostrado que este exploit, denominado GIFAR, es un ataque eficaz contra aplicaciones web como Facebook. ^[47]

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):
[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 del archivo comprimido como de los archivos individuales que contiene es de 4.294.967.295 bytes (2,32 ⁻¹ bytes, o 4 GB menos 1 byte) para el formato ZIP estándar. Para el formato ZIP64, el tamaño máximo es de 18.446.744.073.709.551.615 bytes (2,64 ⁻¹ bytes, o 16 EB menos 1 byte). ^[48]

Se ha propuesto un perfil de archivo ZIP optimizado para búsqueda (SOZip) ^[49] para el formato ZIP. Dicho archivo contiene uno o varios archivos comprimidos con Deflate que están organizados y anotados de 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 archivos comprimidos grandes directamente desde un archivo .zip sin descompresión previa. Combina el uso de vaciados de bloques ZLib emitidos a intervalos regulares con un archivo de índice oculto que asigna los desplazamientos del archivo sin comprimir a los desplazamientos en el flujo comprimido. Los lectores ZIP que no conocen esa extensión pueden leer un archivo compatible con SOZip normalmente e ignorar las características extendidas que admiten la capacidad de búsqueda eficiente.

El formato de archivo .ZIP incluye una función de campo adicional dentro de los encabezados de archivo, que se puede utilizar para almacenar datos adicionales no definidos por las especificaciones ZIP existentes y que permite a los archivadores compatibles que no reconocen los campos omitirlos de forma segura. Los identificadores de encabezado 0 a 31 están reservados para el uso de PKWARE. Los proveedores externos pueden utilizar los identificadores restantes para uso exclusivo.

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. ^[50] Los estándares de cifrado en sí 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 productos 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 todavía estaba incompleto.

En otra iniciativa controvertida, PKWare solicitó una patente el 16 de julio de 2003 que describe un método para combinar ZIP y un cifrado fuerte para crear un archivo seguro. ^[51]

Al final, PKWARE y WinZip acordaron dar soporte a los productos de cada uno. El 21 de enero de 2004, PKWARE anunció el soporte del formato de compresión AES basado en WinZip. ^[52] En una versión posterior de la versión beta de WinZip, fue capaz de soportar archivos ZIP basados ​​en SES. ^[53] PKWARE finalmente lanzó la versión 5.2 de la Especificación de formato de archivo .ZIP al público, 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 ).

Al utilizar 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 adicional de AES. ^[54] 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 Directorio central, a menos que se utilice el Cifrado de directorio central para enmascarar/cifrar metadatos.

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

Algunas bibliotecas de desarrollo con licencia de código abierto son libzip , libarchive e Info-ZIP . Para Java: Java Platform, Standard Edition contiene el paquete "java.util.zip" para manejar archivos .ZIP estándar ; la biblioteca Zip64File admite específicamente archivos grandes (más grandes que 4 GB) y trata los archivos .ZIP mediante 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 las características del sistema de archivos Unix, como los identificadores de usuarios y grupos, los permisos de archivos y la compatibilidad con enlaces simbólicos. La implementación de Apache Ant es consciente de estos aspectos hasta el punto de que puede crear archivos con permisos Unix predefinidos. Las implementaciones de Info-ZIP también saben cómo utilizar 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 de Windows de Info-ZIP también admiten permisos de sistemas de archivos NTFS e intentarán traducir los permisos de NTFS a permisos de 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 soporte para la compresión .ZIP en el Explorador desde que se lanzó el paquete Microsoft Plus! para Windows 98. Microsoft llama a esta característica "Carpetas comprimidas". No todas las características .ZIP son compatibles con la capacidad de Carpetas comprimidas de Windows. Por ejemplo, el cifrado no es compatible con la edición Windows 10 Home, ^[55] aunque puede descifrar. La codificación de entrada Unicode no es compatible hasta Windows 7 , mientras que los archivos divididos y distribuidos no son legibles ni escribibles por la función Carpetas comprimidas, ni tampoco se admite el cifrado AES. ^[56] La compatibilidad con .zip de Windows surgió de una adquisición de "VisualZip" escrito por Dave Plummer . ^{[57] [58] [59]}

OpenDocument Format (ODF) comenzó a utilizar el formato de archivo zip en 2005, ODF es un formato abierto para documentos de oficina de todo tipo, este es el formato de archivo predeterminado utilizado en Collabora Online , LibreOffice y otros. ^[60] Microsoft Office comenzó a utilizar el formato de archivo zip en 2006 para sus archivos Office Open XML .docx, .xlsx, .pptx, etc., que se convirtieron en el formato de archivo predeterminado con Microsoft Office 2007 .

Las versiones del formato anteriores a la 6.3.0 no admitían el almacenamiento de nombres de archivos en Unicode . ^[61] Según el estándar, ^[61] los nombres de archivos se deben almacenar en la codificación CP437 , que es estándar para IBM PC , ^[61] pero en la práctica, los archivadores DOS usaban la codificación de caracteres instalada del sistema . El archivador integrado de Windows hasta la versión 11 también usaba la codificación DOS correspondiente al idioma del sistema seleccionado para compatibilidad con versiones anteriores al crear archivos. Posteriormente, el estándar se actualizó para incluir dos opciones para almacenar nombres de archivos en Unicode: 1) cuando se establece el bit 11 en el campo de indicador de bit de propósito general, 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. ^[61] Algunas versiones de archivadores en la plataforma Windows también han usado codificación ANSI en el pasado. Por lo tanto, para extraer correctamente archivos con nombres que contienen caracteres no ingleses, es necesario: ^[62]

1. Verifique la presencia del campo adicional de ruta Unicode y, si existe, utilice el nombre de archivo que figura en él, codificado en UTF-8.
2. Verifique la presencia del indicador 11 en el campo Indicador de bit de propósito general y, si está configurado, considere que la codificación del nombre de archivo en el campo "Nombre de archivo" sea 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 una; 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), correspondiente 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 del sistema operativo en el que se ejecuta el descompresor.

Algunas implementaciones de descompresores zip no implementaron este algoritmo o lo implementaron solo parcialmente, como resultado, al ver el contenido de un archivo o extraerlo, los usuarios veían un conjunto caótico de caracteres, conocido como "mojibake", en lugar de letras del alfabeto nacional. En 2016, este problema se solucionó en el administrador de archivos y archivos far2l para Linux, BSD y Mac. ^[63] En 2024, se agregó una solución similar ^[64] 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. ^[62]

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. Asimismo, 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 consistencia. Otros formatos y programas comunes con nombres similares con diferentes formatos nativos incluyen 7-Zip , bzip2 y rzip .

El factor de compresión máximo teórico para un flujo DEFLATE sin procesar es de aproximadamente 1032 a uno, ^[65] pero al explotar el formato ZIP de maneras no deseadas, se pueden construir archivos ZIP con índices de compresión de miles de millones a uno. Estas bombas zip se descomprimen en tamaños extremadamente grandes, abrumando la capacidad del equipo en el que se descomprimen. ^[66]

• Comparación de archivadores de archivos
• Comparación de formatos de archivo
• Lista de formatos de archivo

• Nota de aplicación .ZIP archivada el 17 de julio de 2017 en la página de inicio de Wayback Machine para el archivo .ZIP actual e histórico de PKWARE
• ISO/IEC 21320-1:2015 — Archivo contenedor de documentos — Parte 1: Núcleo
• Archivos Zip: Historia, explicación e implementación
• Reducir, encoger e implosionar: los métodos de compresión Zip tradicionales
• Espejo APPNOTE.TXT
• Estructura del archivo PKZip Especificaciones de formato, tablas gráficas