.Los archivos ZIP son archivos que almacenan múltiples ficheros. ZIP permite comprimir los archivos contenidos utilizando 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. Como los ficheros de un archivo ZIP se comprimen individualmente, es posible extraerlos o añadir otros nuevos sin aplicar la compresión o descompresión a todo el archivo. Esto contrasta con el formato de los archivos tar comprimidos, para los que este tipo de procesamiento de acceso aleatorio no es fácilmente posible.
Al final de un archivo ZIP se coloca un directorio. Esto identifica qué archivos están en el ZIP e identifica en qué parte del ZIP se encuentra ese archivo. Esto permite a los lectores de ZIP cargar la lista de archivos sin leer todo el archivo ZIP. Los archivos ZIP también pueden incluir datos adicionales que no están relacionados con el archivo ZIP. Esto permite convertir un archivo ZIP en un archivo autoextraíble (aplicación que descomprime los datos que contiene), añadiendo el código del programa a un archivo ZIP y marcando el archivo como ejecutable. El almacenamiento del catálogo al final también permite ocultar un archivo comprimido anexá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 directorios del archivo para proporcionar una mayor protección contra la pérdida de datos.
StructureEdit
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 ficheros. 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 en el archivo ZIP, que apunta a los datos de entrada reales. Esto permite realizar un listado de ficheros del archivo con relativa rapidez, ya que no es necesario leer todo el archivo para ver la lista de ficheros. Las entradas dentro del archivo ZIP también incluyen esta información, por redundancia, en una cabecera de archivo local. Dado que los archivos ZIP pueden ser anexados, sólo son válidos los archivos especificados en el directorio central al final del archivo. Analizar un archivo ZIP en busca de cabeceras de archivos locales no es válido (excepto en el caso de archivos corruptos), ya que el directorio central puede declarar que algunos archivos han sido eliminados y otros han sido actualizados.
Por ejemplo, podemos empezar con un archivo ZIP que contiene los archivos A, B y C. El archivo B se elimina y el C se actualiza. Esto se puede conseguir simplemente añadiendo un nuevo archivo C al final del archivo ZIP original y añadiendo un nuevo directorio central que sólo contenga el archivo A y el nuevo archivo C. Cuando se diseñó el ZIP por primera vez, la transferencia de archivos por disquete era común, pero la escritura en los discos consumía mucho tiempo. Si usted tenía un archivo zip grande, posiblemente abarcando varios discos, y sólo necesitaba actualizar unos pocos archivos, en lugar de leer y volver a escribir todos los archivos, sería sustancialmente más rápido sólo leer el antiguo directorio central, anexar los nuevos archivos y luego anexar un directorio central actualizado.
El orden de las entradas de los ficheros en el directorio central no tiene por qué coincidir con el orden de las entradas de los ficheros en el archivo.
Cada entrada almacenada en un archivo ZIP es introducida por una cabecera de fichero local con información sobre el fichero como el comentario, el tamaño del fichero y el nombre del fichero, seguida de campos de datos «extra» opcionales, y luego los datos del fichero posiblemente comprimidos y posiblemente encriptados. Los campos de datos «extra» son la clave de la extensibilidad del formato ZIP. Los campos «extra» se aprovechan para soportar 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». Las herramientas ZIP están obligadas por la especificación a ignorar los campos Extra que no reconocen.
El formato ZIP utiliza «firmas» específicas de 4 bytes para denotar 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 4 bytes de la cabecera del archivo central.
No hay marcador BOF o EOF en la especificación ZIP. Convencionalmente lo primero en un archivo ZIP es una entrada ZIP, que puede ser identificada fácilmente por su firma de cabecera de archivo local. Sin embargo, este no es necesariamente el caso, ya que esto no es requerido por la especificación ZIP – más notablemente, un archivo auto-extraíble comenzará con una cabecera de archivo ejecutable.
Las herramientas que leen correctamente los archivos ZIP deben escanear la firma del registro del final del directorio central, y luego, según sea apropiado, los otros registros del directorio central indicados. No deben escanear las entradas de la parte superior del archivo ZIP, porque (como se ha mencionado anteriormente en esta sección) sólo el directorio central especifica dónde comienza un trozo de archivo y que no ha sido eliminado. El escaneo podría conducir a falsos positivos, ya que el formato no prohíbe que haya otros datos entre los chunks, 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 escanearán el archivo en busca de firmas de encabezados de archivos locales; esto se ve dificultado por el hecho de que el tamaño comprimido de un trozo de archivo puede almacenarse después del trozo de archivo, lo que dificulta el procesamiento secuencial.
La mayoría de las firmas terminan con el entero corto 0x4b50, que se almacena en ordenación little-endian. Visto como una cadena ASCII se lee «PK», las iniciales del inventor Phil Katz. Así, cuando un archivo ZIP se ve en un editor de texto, los dos primeros bytes del archivo suelen ser «PK». (Los ZIP autoextraíbles de DOS, OS/2 y Windows tienen un EXE antes del ZIP, por lo que comienzan con «MZ»; los ZIP autoextraíbles para otros sistemas operativos pueden ir precedidos de forma similar por un código ejecutable para extraer el contenido del archivo en esa plataforma.)
La especificación .ZIP también admite la propagación de archivos a través de múltiples archivos del sistema de archivos. Originalmente pensado para el almacenamiento de grandes archivos ZIP a través de múltiples disquetes, esta característica se utiliza ahora para el envío de archivos ZIP en partes a través de correo electrónico, o a través de otros transportes o medios extraíbles.
El sistema de archivos FAT de DOS tiene una resolución de marca de tiempo de sólo dos segundos; los registros de archivos ZIP imitan esto. Como resultado, la resolución de la marca de tiempo incorporada en los archivos ZIP es de sólo dos segundos, aunque se pueden utilizar campos adicionales para almacenar marcas de tiempo más precisas. El formato ZIP no tiene ninguna noción de zona horaria, por lo que las marcas de tiempo sólo tienen sentido si se sabe en qué zona horaria se crearon.
En septiembre de 2007, PKWARE publicó una revisión de la especificación ZIP que permite el almacenamiento de los nombres de los archivos utilizando UTF-8, añadiendo finalmente la compatibilidad con Unicode a ZIP.
Cabeceras de archivosEditar
Todos los valores multibyte de la cabecera se almacenan en orden little-endian de bytes. Todos los campos de longitud cuentan la longitud en bytes.
Cabecera del archivo localEditar
| Desplazamiento | Bytes | Descripción |
|---|---|---|
| 0 | 4 | Firma de la cabecera del archivo local = 0x04034b50 (leído como un número little-endian number) |
| 4 | 2 | Versión necesaria para extraer (mínimo) |
| 6 | 2 | Bandera de bits de propósito general |
| 8 | 2 | Método de compresión |
| 10 | Fecha de ú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 0xffffff para ZIP64) |
| 26 | 2 | Longitud del nombre del archivo (n) |
| 28 | 2 | Longitud del campo extra (m) |
| 30 | n | Nombre del archivo |
| 30+n | m | Campo extra |
El campo extra contiene una variedad de datos opcionales como atributos específicos del sistema operativo.atributos específicos del sistema operativo. Se divide en trozos, cada uno con un código de identificación de 16 bits y una longitud de 16 bits. Para ZIP64, siempre existe al menos un chunk (con código ID 0001 y tamaño de 32 bytes), véase más abajo.
A esto le siguen inmediatamente los datos comprimidos.
Descriptor de datosEditar
Si el bit en el offset 3 (0x08) del campo de banderas de propósito general está activado, entonces el CRC-32 y los tamaños de archivo no se conocen cuando se escribe la cabecera. Los campos de la cabecera local se rellenan con cero, y el CRC-32 y el tamaño se añaden en una estructura de 12 bytes (opcionalmente precedida por una firma de 4 bytes) inmediatamente después de los datos comprimidos:
| Desplazamiento | 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 | Sin comprimir size |
Cabecera del archivo del directorio centralEditar
La entrada del directorio central es una forma expandida de la cabecera local:
| Offset | Bytes | Descripción |
|---|---|---|
| 0 | 4 | Central Firma de la cabecera del archivo del directorio = 0x02014b50 |
| 4 | 2 | Versión realizada por |
| 6 | 2 | Versión necesaria para extraer (mínimo) |
| 8 | 2 | Bandera de bits de propósito general |
| 10 | 2 | Método de compresión |
| 12 | 2 | Hora de última modificación del archivo |
| 14 | Fecha de última modificación del archivo | |
| 16 | 4 | CRC-32 de datos sin comprimir |
| 20 | 4 | Tamaño comprimido (o 0xffffffff para ZIP64) |
| 24 | 4 | Tamaño sin comprimir (o 0xffffff para ZIP64) |
| 28 | 2 | Longitud del nombre del archivo (n) |
| 30 | 2 | Longitud del campo extra (m) |
| 32 | 2 | Longitud del comentario del archivo (k) |
| 34 | 2 | Número de disco donde comienza el archivo |
| 36 | 2 | Atributos internos del archivo |
| 38 | 4 | Atributos externos del archivo |
| 42 | 4 | Desplazamiento relativo de la cabecera del archivo local. Es el número de bytes entre el inicio del primer disco en el que se encuentra el archivo y el inicio de la cabecera del archivo local. Esto permite al software que lee el directorio central localizar la posición del archivo dentro del archivo ZIP. |
| 46 | n | Nombre del archivo |
| 46+n | m | Campo extra |
| 46+n+m | k | Comentario del archivo |
Final del registro del directorio central (EOCD)Editar
Después de todas las entradas del directorio central viene el registro del final del directorio central (EOCD), que marca el final del archivo ZIP:
| Offset | Bytes | Descripción |
|---|---|---|
| 0 | 4 | Final del directorio central firma = 0x06054b50 |
| 4 | 2 | Número de este disco |
| 6 | 2 | Disco donde comienza el directorio central comienza |
| 8 | 2 | Número de registros del directorio central en este disco |
| 10 | 2 | Número total de registros del directorio central |
| 12 | 4 | Tamaño del directorio central (bytes) |
| 16 | 4 | Desplazamiento del inicio del directorio central relativo al inicio del archivo |
| 20 | 2 | Longitud del comentario (n) |
| 22 | n | Comentario |
Esta ordenación permite crear un archivo ZIP en una sola pasada, pero el directorio central también se coloca al final del archivo para facilitar la extracción de archivos de varias partes (por ejemplop. ej., «varios disquetes»), como se ha comentado anteriormente.
Métodos de compresiónEditar
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, WavPack, PPMd, y una variante de 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 el 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 de JPEG. Se reservó un método «Tokenize» para un tercero, pero nunca se añadió soporte.
La palabra Implode está sobreutilizada por PKWARE: el DCL/TERSE Implode es distinto del antiguo PKZIP Implode, un predecesor de Deflate. El DCL Implode no está documentado en parte debido a su naturaleza propietaria en manos de IBM, pero Mark Adler ha proporcionado, sin embargo, un descompresor llamado «blast» junto a zlib.
EncryptionEdit
ZIP soporta un sencillo 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 serios defectos. En particular, es vulnerable a los ataques de texto plano conocido, que en algunos casos se ven agravados por las malas implementaciones de los generadores de números aleatorios.
Desde la versión 5.2 se han documentado nuevas características que incluyen nuevos métodos de compresión y cifrado (por ejemplo, AES). Un estándar abierto basado en AES desarrollado por WinZip («AE-x» en APPNOTE) es utilizado también por 7-Zip y Xceed, pero algunos vendedores utilizan otros formatos. PKWARE SecureZIP (SES, propietario) también admite los métodos de cifrado RC2, RC4, DES, Triple DES, el cifrado y la autenticación basados en certificados digitales (X.509) y el cifrado de cabeceras de archivos. Sin embargo, está patentado (véase § Polémica por el cifrado fuerte).
El cifrado del nombre del 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 de la cabecera local cuando se 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 de la cabecera local aún no están enmascarados.
ZIP64Edit
El formato .ZIP original tenía un límite de 4 GiB (232 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 (216) 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 concreta), PKWARE introdujo las extensiones de formato «ZIP64» para sortear estas limitaciones, aumentando los límites a 16 EiB (264 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 de la cabecera del archivo local y de la entrada del directorio central es el mismo en ZIP y ZIP64, pero para los tamaños siempre se almacena 0xffffff, y siempre existe un campo extra:
| Offset | Bytes | Descripción |
|---|---|---|
| 0 | 2 | Identificación del encabezado 0x0001 |
| 2 | 2 | Tamaño del trozo de campo extra (16, 24 o 28) |
| 4 | 8 | Tamaño original del archivo sin comprimir |
| 12 | 8 | Tamaño de los datos comprimidos |
| 20 | 8 | Desplazamiento del registro de cabecera local |
| 28 | 4 | Número del disco en el que comienza este archivo |
Por otro lado, el formato de EOCD para ZIP64 es ligeramente diferente al de la versión ZIP normal (véase la nota de aplicación de la sección 4.3.14).
| Offset | Bytes | Descripción |
|---|---|---|
| 0 | 4 | Firma del directorio central = 0x06064b50 |
| 4 | 8 | Tamaño del EOCD64 – 8 |
| 12 | 2 | Versión realizada por |
| 14 | 2 | Versión necesaria para extraer (mínimo) |
| 16 | 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 | n | Comentario (hasta el tamaño de EOCD64) |
Tampoco es necesariamente el último registro del archivo, puede seguir un localizador opcional de fin de directorio central (20 bytes adicionales al final).
El Explorador de Archivos de Windows XP no soporta ZIP64, pero el Explorador de Windows Vista y posteriores sí. Asimismo, algunas bibliotecas de extensión soportan ZIP64, como DotNetZip, QuaZIP e IO::Compress::Zip en Perl. El archivo zip integrado de Python lo soporta desde la versión 2.5 y por defecto desde la 3.4. El java.util.zip incorporado en OpenJDK soporta ZIP64 desde la versión Java 7. La API Java de Android soporta ZIP64 desde Android 6.0. La Utilidad de Archivo de Mac OS Sierra no soporta ZIP64, y puede crear archivos corruptos cuando se requiere ZIP64. Sin embargo, el comando ditto incluido en Mac OS puede descomprimir 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 sí son compatibles con ZIP64: para comprobarlo, ejecute zip -v y busque «ZIP64_SUPPORT».
Combinación con otros formatos de archivoEditar
El formato de archivo .ZIP permite incluir un comentario con un máximo de 65.535 (216-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 los archivos que no comiencen con una entrada de archivo en el desplazamiento cero.
Esto permite que haya datos arbitrarios en el archivo tanto antes como después de los datos del archivo ZIP, y que el archivo siga siendo 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 de trabajo y 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 soportada por WinZip, se aprovechan de esto, en el sentido de que son archivos ejecutables (.exe) que se ajustan a la especificación PKZIP AppNote.txt, y pueden ser leídos por herramientas o bibliotecas zip que cumplen con la normativa.
Esta propiedad del formato .ZIP, y del formato JAR que es una variante de ZIP, puede ser explotada para ocultar contenido no deseado (como clases Java dañinas) dentro de un archivo aparentemente inofensivo, como una imagen GIF subida a la web. Este exploit llamado GIFAR ha sido demostrado como un ataque efectivo contra aplicaciones web como Facebook.
LimitsEdit
El tamaño mínimo de un archivo .ZIP es de 22 bytes. Un archivo zip vacío de este tipo sólo contiene un registro de fin de directorio central (EOCD):
El tamaño máximo tanto del archivo comprimido como de los archivos individuales que contiene es de 4.294.967.295 bytes (232-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 (264-1 bytes, o 16 EiB menos 1 byte).
Extensiones propietariasEditar
Campo extraEditar
.El formato de archivo ZIP incluye una facilidad de campo extra dentro de las cabeceras de los archivos, que puede utilizarse para almacenar datos extra no definidos por las especificaciones ZIP existentes, y que permite a los archivadores compatibles que no reconocen los campos omitirlos de forma segura. Los ID de cabecera 0-31 están reservados para su uso por PKWARE. Los IDs restantes pueden ser utilizados por los proveedores de terceros para el uso propietario.
Controversia sobre el cifrado fuerteEditar
Cuando WinZip 9.0 beta pública fue lanzado en 2003, WinZip introdujo su propio cifrado AES-256, utilizando un formato de archivo diferente, junto con la documentación de la nueva especificación. Los estándares de cifrado en sí mismos no eran propietarios, pero PKWARE no había actualizado APPNOTE.TXT para incluir 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 director de producto de StuffIt, Mathew Covington, acusaron a PKWARE de retener la 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 en la que se describía un método para combinar ZIP y un cifrado fuerte para crear un archivo seguro.
Al final, PKWARE y WinZip acordaron dar soporte a los productos del otro. El 21 de enero de 2004, PKWARE anunció el soporte del formato de compresión AES basado en WinZip. En una versión posterior de la beta de WinZip, pudo soportar archivos ZIP basados en SES. Finalmente, PKWARE puso a disposición del público la versión 5.2 de la especificación del formato de archivo .ZIP, que documentaba SES. El proyecto de Software Libre 7-Zip también soporta AES, pero no SES en archivos ZIP (al igual que su puerto POSIX p7zip).
Cuando se utiliza el cifrado AES bajo 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 extra AES. Por el contrario, Strong Encryption Specification almacena el método de compresión en el segmento básico de la cabecera del archivo de Local Header y Central Directory, a menos que se utilice Central Directory Encryption para enmascarar/encriptar los metadatos.