ZIP (formato de archivo) - ZIP (file format)

Formato de archivo ZIP
Extensión de nombre de archivo .zip .zipx
Tipo de medio de Internet application/zip
Identificador de tipo uniforme (UTI) com.pkware.zip-archive
número mágico
Desarrollado por PKWARE, Inc.
Versión inicial 14 de febrero de 1989 ; Hace 32 años ( 14 de febrero de 1989 )
Último lanzamiento
6.3.9
(15 de julio de 2020 ; hace 14 meses ) ( 15 de julio de 2020 )
Tipo de formato Compresión de datos
Extendido a
Estándar APPNOTE de PKWARE
ISO / IEC 21320-1: 2015 (un subconjunto del formato de archivo ZIP 6.3.3)
¿ Formato abierto ?

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 fue creado originalmente en 1989 y se implementó por primera vez en PKWARE, Inc. 's PKZIP utilidad, como un reemplazo para el anterior ARC formato de compresión por Thom Henderson. El formato ZIP fue rápidamente admitido por 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 2000 (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 MIMEapplication/zip . Muchos programas utilizan ZIP como formato de archivo base, normalmente 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 con una cremallera prominente .

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 "moverse 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 .ZIP File Format Specification 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 entre el público Internet durante la década de 1990.

PKWARE e Infinity Design Concepts hicieron 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 se corresponde necesariamente con 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 a los productos PKZIP extraer 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 admiten las especificaciones 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 se publicaron. PKWARE publicó unas especificaciones de algunas características, como la compresión BZIP2 , la fuerte especificación de cifrado 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 archivo se pueden comprimir con DEFLATE y utilizar el cifrado PKWARE tradicional (ZipCrypto).
  • 2.1: (1996) Compresión Deflate64
  • 4.5: (2001) Formato zip de 64 bits documentado.
  • 4.6: (2001) Compresión BZIP2 (no publicado en línea hasta la publicación de APPNOTE 5.2)
  • 5.0: (2002) SES: DES , Triple DES , RC2 , RC4 compatible con 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 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) Almacenamiento de certificados documentados.
  • 6.2.0: (2004) Cifrado de directorio central documentado.
  • 6.3.0: (2006) Almacenamiento de nombre de archivo Unicode ( UTF-8 ) documentado. Lista ampliada de algoritmos de compresión compatibles ( LZMA , PPMd + ), algoritmos de cifrado ( Blowfish , Twofish ) y hashes.
  • 6.3.1: (2007) Valores 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) Cambios en el formato del documento para facilitar la referencia a la Nota de aplicación PKWARE de otras normas utilizando métodos como el Informe explicativo de referencia (RER) del JTC 1 según lo indicado por JTC 1 / SC 34 N 1621.
  • 6.3.4: (2014) Actualiza la dirección de la oficina de PKWARE, Inc.
  • 6.3.5: (2018) Métodos de compresión documentados 16, 96 y 99, época y precisión de la marca de tiempo de DOS, campos adicionales agregados para claves y descifrado, así como errores tipográficos 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) Se movió el ID del método de compresión Zstandard de 20 a 93, desaprobando el primero. ID de método documentado 94 y 95 ( MP3 y XZ respectivamente).
  • 6.3.9: (2020) Se corrigió un error tipográfico en la descripción de Alineación del flujo de datos.

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 dos últimos se aplican a los tipos de archivo apropiados cuando se selecciona la compresión "Mejor método".

Estandarización

En abril de 2010, ISO / IEC JTC 1 inició una votación para determinar si se debería iniciar un proyecto para crear un formato de Norma Internacional ISO / IEC compatible con ZIP. El proyecto propuesto, titulado Empaquetado 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, 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:

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

Diseño

Los archivos .ZIP son archivos que almacenan varios archivos. ZIP permite comprimir 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 utilizando 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 este procesamiento de acceso aleatorio no es fácilmente posible.

Un directorio se coloca al final de un archivo ZIP. Esto identifica qué archivos están en el ZIP e identifica en qué lugar 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 sus datos contenidos), 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 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 la estructura de directorio del archivo para brindar una mayor protección contra la pérdida de datos.

Estructura

Diseño interno ZIP-64

Un archivo ZIP se identifica correctamente por la presencia de un registro al final del 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 desplazamiento 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 el archivo completo 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 los archivos especificados en el directorio central al final del archivo son válidos. Escanear un archivo ZIP en busca de encabezados de archivos locales no es válido (excepto en el caso de archivos corruptos), ya que el directorio central puede declarar que algunos archivos se han eliminado y otros 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 consumía mucho tiempo. Si tuviera un archivo zip grande, posiblemente que abarque 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 nuevos archivos 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 introduce mediante un encabezado de archivo local con información sobre el archivo, como el comentario, el tamaño del archivo y el nombre del archivo, seguido de campos de datos "adicionales" opcionales, y luego 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 "adicionales" se aprovechan para admitir el formato ZIP64, el cifrado AES compatible con WinZip, los atributos de archivo y las marcas de tiempo de los archivos NTFS o Unix de mayor resolución. Otras extensiones son posibles a través del campo "Extra". 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 indicar las distintas estructuras del 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 la firma del encabezado del archivo local . Sin embargo, este no es necesariamente el caso, ya que no lo requiere la especificación ZIP; 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 tales 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 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 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 primeros dos 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 también 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 en varios archivos del sistema de archivos. Originalmente pensada para el almacenamiento de archivos ZIP grandes en varios disquetes , esta función ahora se usa para enviar archivos ZIP en partes por correo electrónico, o sobre 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 la 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 2007, PKWARE publicó una revisión de la especificación ZIP que proporciona el almacenamiento de nombres de archivos usando UTF-8 , finalmente agregando 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

Encabezado de archivo local
Compensar Bytes Descripción
0 4 Firma del encabezado del archivo local = 0x04034b50 (PK ♥ ♦ o "PK \ 3 \ 4")
4 2 Versión necesaria para extraer (mínimo)
6 2 Indicador de bits de propósito general
8 2 Método de compresión; por ejemplo, ninguno = 0, DEFLATE = 8 (o "\ 0x08 \ 0x00")
10 2 Hora de la última modificación del archivo
12 2 Fecha de última modificación del archivo
14 4 CRC-32 de datos sin comprimir
18 4 Tamaño comprimido (o 0xffffffff para ZIP64)
22 4 Tamaño sin comprimir (o 0xffffffff para ZIP64)
26 2 Longitud del nombre de archivo ( n )
28 2 Longitud de campo adicional ( m )
30 norte Nombre del archivo
30+ n metro Campo adicional

El campo adicional contiene una variedad de datos opcionales, como atributos específicos del sistema operativo. Se divide en registros, cada uno con al menos una firma de 16 bits y una longitud de 16 bits. Un registro de campo adicional de archivo local ZIP64, por ejemplo, tiene la firma 0x0001 y una longitud de 16 bytes (o más), por lo que pueden seguir dos valores de 64 bits (los tamaños comprimido 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.

A esto le siguen inmediatamente los datos comprimidos.

Descriptor de datos

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. Los campos en el encabezado local se llenan con cero, y el CRC-32 y el tamaño se agregan en una estructura de 12 bytes (opcionalmente precedidos por una firma de 4 bytes) inmediatamente después de los datos comprimidos:

Descriptor de datos
Compensar Bytes Descripción
0 0/4 Firma del descriptor de datos opcional = 0x08074b50
0/4 4 CRC-32 de datos sin comprimir
4/8 4 Tamaño comprimido
8/12 4 Tamaño sin comprimir

Encabezado del archivo del directorio central

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

Encabezado del archivo del directorio central
Compensar Bytes Descripción
0 4 Firma del encabezado del archivo del directorio central = 0x02014b50
4 2 Versión realizada por
6 2 Versión necesaria para extraer (mínimo)
8 2 Indicador de bits de propósito general
10 2 Método de compresión
12 2 Hora de la última modificación del archivo
14 2 Fecha de última modificación del archivo
dieciséis 4 CRC-32 de datos sin comprimir
20 4 Tamaño comprimido (o 0xffffffff para ZIP64)
24 4 Tamaño sin comprimir (o 0xffffffff para ZIP64)
28 2 Longitud del nombre de archivo ( n )
30 2 Longitud de campo adicional ( m )
32 2 Longitud del comentario del archivo ( k )
34 2 Número de disco donde comienza el archivo
36 2 Atributos de archivos internos
38 4 Atributos de archivos externos
42 4 Desplazamiento relativo del encabezado del archivo local. Este es el número de bytes entre el inicio del primer disco en el que se encuentra el archivo y el inicio del encabezado del archivo local. Esto permite que el software que lee el directorio central localice la posición del archivo dentro del archivo ZIP.
46 norte Nombre del archivo
46+ n metro Campo adicional
46+ n + m k Comentario de archivo

Fin del registro del directorio central (EOCD)

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

Fin del registro del directorio central (EOCD)
Compensar 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 Disco 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 del directorio central (o 0xffff para ZIP64)
12 4 Tamaño del directorio central (bytes) (o 0xffffffff para ZIP64)
dieciséis 4 Desplazamiento del inicio del directorio central, relativo al inicio del archivo (o 0xffffffff para ZIP64)
20 2 Longitud del comentario ( n )
22 norte 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 archivos de varias partes (por ejemplo, "varios disquetes") , como discutido 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), Implode, Deflate, Deflate64, 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 (antiguo IBM TERSE), nuevo IBM TERSE , IBM LZ77 z Architecture (PFS) y una variante JPEG. Se reservó un método "Tokenize" para un tercero, pero nunca se agregó soporte.

PKWARE utiliza en exceso la palabra Implode : el Implode DCL / TERSE es distinto del antiguo Implode PKZIP, un predecesor de Deflate. El DCL Implode no está documentado en parte debido a su naturaleza de propiedad en poder de IBM, pero Mark Adler ha proporcionado un descompresor llamado "blast" junto con zlib.

Cifrado

ZIP admite un sistema de cifrado simétrico basado en contraseña simple , generalmente conocido como ZipCrypto. Está documentado en la especificación ZIP y se sabe que tiene graves defectos. En particular, es vulnerable a los ataques de texto plano conocido , que en algunos casos se ven agravados por implementaciones deficientes de generadores de números aleatorios .

Las nuevas características que incluyen 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. A WinZip -desarrollado estándar abierto basado en AES ( "AE-x" en AppNote) se utiliza también por 7-Zip y Xceed , pero algunos proveedores utilizan otros formatos. 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 (ver § Fuerte controversia sobre cifrado ).

El cifrado del nombre de archivo se introduce en la Especificación 6.2 del formato de archivo .ZIP, 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 al utilizar 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 .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 ) 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 las extensiones de formato "ZIP64" para sortear 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.

El formato del encabezado del archivo local (LOC) y la entrada del directorio central (CEN) es el mismo en ZIP y ZIP64. Sin embargo, ZIP64 especifica un campo adicional que puede agregarse 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 señalar que los valores reales se almacenan en campos adicionales ZIP64, se establecen en 0xFFFF o 0xFFFFFFFF en el registro LOC o CEN correspondiente.

Campo adicional de información ampliada Zip64
Compensar Bytes Descripción
0 2 ID de encabezado 0x0001
2 2 Tamaño del fragmento de campo adicional (8, 16, 24 o 28)
4 8 Tamaño de archivo original sin comprimir
12 8 Tamaño de los datos comprimidos
20 8 Desplazamiento del registro de encabezado local
28 4 Número del disco en el que se inicia este archivo

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

Zip64 Fin del registro del directorio central (EOCD64)
Compensar Bytes Descripción
0 4 Fin de la firma del directorio central = 0x06064b50
4 8 Tamaño del EOCD64 - 12
12 2 Versión realizada por
14 2 Versión necesaria para extraer (mínimo)
dieciséis 4 Número de este disco
20 4 Disco donde comienza el directorio central
24 8 Número de registros del directorio central en este disco
32 8 Número total de registros del directorio central
40 8 Tamaño del directorio central (bytes)
48 8 Desplazamiento del inicio del directorio central, relativo al inicio del archivo
56 norte Comentario (hasta el tamaño de EOCD64)

Tampoco es necesariamente el último registro del archivo. A continuación, aparece un localizador de final 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 extensiones admiten ZIP64, como DotNetZip, QuaZIP e IO :: Compress :: Zip en Perl. Python 's incorporado en soportes ZipFile que desde 2.5 y por defecto que desde 3.4. El java.util.zip integrado de OpenJDK es compatible con ZIP64 desde la versión Java 7 . La API de Android Java es compatible con ZIP64 desde Android 6.0. La utilidad de archivo de Mac OS Sierra no es compatible con ZIP64 y puede crear archivos corruptos cuando se requiera ZIP64. Sin embargo, el comando ditto enviado con Mac OS descomprimirá los archivos ZIP64. Las versiones más recientes de Mac OS incluyen 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".

Combinación con otros formatos de archivo

El formato de archivo .ZIP permite que se produzca un comentario que contenga hasta 65 535 (2 16 −1) bytes de datos al final del 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 en 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 antes y 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 tanto un archivo ZIP funcional como otro formato, siempre que el otro formato tolere datos arbitrarios al final, al principio o en el medio. Los archivos autoextraíbles (SFX), de la forma admitida por WinZip, aprovechan esto, ya que son archivos ejecutables ( .exe ) que se ajustan a la especificación PKZIP AppNote.txt y que pueden leerse mediante bibliotecas o herramientas zip compatibles .

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

Limites

El tamaño mínimo de un archivo .ZIP es de 22 bytes. Un archivo zip vacío de este tipo 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 4.294.967.295 bytes (2 32 −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 64 −1 bytes, o 16 EB menos 1 byte).

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 permite a los archivadores compatibles que no reconocen los campos omitirlos de manera segura. Los ID de encabezado 0–31 están reservados para uso de PKWARE. Los ID restantes pueden ser utilizados por proveedores externos para uso propietario.

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í no eran propietarios , pero PKWARE no había actualizado APPNOTE.TXT para incluir la Especificación de cifrado fuerte (SES) desde 2001, que había sido utilizada 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 describe un método para combinar ZIP y cifrado fuerte para crear un archivo seguro.

Al final, PKWARE y WinZip acordaron respaldar los productos de cada uno. 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ó la versión 5.2 de la Especificación de formato de archivo .ZIP al público, que documentó 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, con el método de compresión real almacenado en un campo de datos adicional AES. Por el contrario, Strong Encryption Specification almacena el método de compresión en el segmento de encabezado de archivo básico de Local Header y Central Directory, a menos que se utilice Central Directory Encryption para enmascarar / cifrar metadatos.

Implementación

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

Algunas bibliotecas de desarrollo con licencia bajo un acuerdo 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 (de más de 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 soporte para las características del sistema de archivos Unix, como ID de usuario y grupo, permisos de archivo y soporte para enlaces simbólicos. La implementación de Apache Ant los conoce en la medida en 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 Info-ZIP de Windows también son compatibles con los permisos del sistema de archivos NTFS y harán un intento de traducir de los permisos NTFS a los permisos Unix o viceversa al extraer archivos. Esto puede resultar en combinaciones potencialmente no deseadas, por ejemplo, archivos .exe que se crean en volúmenes NTFS con el permiso ejecutable denegado.

¡Las versiones de Microsoft Windows han incluido soporte para la compresión .ZIP en Explorer desde Microsoft Plus! El paquete se lanzó para Windows 98. Microsoft llama a esta función "Carpetas comprimidas". No todas las funciones .ZIP son compatibles con la función Carpetas comprimidas de Windows. Por ejemplo, el cifrado no es compatible con Windows 10 Home Edition, aunque puede descifrar. La codificación de entrada Unicode no es compatible hasta Windows 7 , mientras que los archivos divididos y distribuidos no se pueden leer ni escribir con la función Carpetas comprimidas, ni el cifrado AES es compatible.

Microsoft Office comenzó a usar 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 .

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. 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 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 formas no deseadas, se pueden construir archivos ZIP con relaciones 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.

Ver también

Referencias

enlaces externos

Especificaciones de formato: