ZIP de una descarga interrumpida

Un ZIP se escribe de principio a fin, pero se lee de fin a principio. Cada archivo que añadiste se guarda como una entrada de archivo local — una cabecera que empieza con la firma PK\x03\x04, con el nombre, el método de compresión (0 = almacenado, 8 = deflate) y luego los bytes comprimidos —, pero el índice autoritativo de dónde viven esas entradas es el directorio central (registros PK\x01\x02) escrito al final, justo antes del registro End Of Central Directory de 22 bytes, PK\x05\x06. Un extractor abre el archivo posicionándose al final y recorriéndolo hacia atrás en busca de esa firma PK\x05\x06 — hasta unos 65 557 bytes atrás, porque el registro termina con un campo de comentario de longitud variable. Solo tras encontrar el EOCD sabe cuántas entradas contiene el archivo y dónde empieza cada registro del directorio central.

Ahora imagina la descarga que se detuvo al 70 %. Los bytes que nunca llegaron son los que se escribieron los últimos: el directorio central y el EOCD. El extractor se posiciona al final, recorre hacia atrás, nunca ve PK\x05\x06 y se rinde antes de tocar un solo archivo. Ese es el origen exacto del "End-of-central-directory signature not found" de unzip, del "Unexpected end of archive" de 7-Zip y WinRAR, del "The Compressed (zipped) Folder is invalid" del Explorador, y del "Unable to expand … (Error 2)" de la Utilidad de Archivos de macOS. Ninguno significa que los archivos guardados estén revueltos — significan que la tabla de contenidos de la cola ha desaparecido.

Las descargas interrumpidas son especialmente propensas a esto por cómo se generan muchos ZIP. Un archivo montado sobre la marcha por un servidor — una "descargar todo" de un almacenamiento en la nube, el ZIP del código fuente de un repositorio de GitHub, un paquete de exportación — suele ir en streaming: el bit 3 del indicador de propósito general (0x0008) está activado, el tamaño comprimido y el CRC-32 de cada cabecera local se dejan a cero, y los valores reales se añaden después de los datos de la entrada en un descriptor de datos (PK\x07\x08). Para esos archivos, el directorio central es el único sitio donde los tamaños están garantizados, así que perder la cola es doblemente dañino para un extractor normal. El archivo a medio escribir que dejó tu navegador — un .crdownload de Chrome/Edge, un .part de Firefox, o un .zip que simplemente es más corto que el Content-Length de la respuesta — aún contiene cada entrada completa hasta el corte y nada posterior a él.

El rescate no necesita en absoluto el índice que falta, porque en un ZIP cada entrada local se describe a sí misma. En lugar de posicionarse al final, la herramienta recorre el archivo hacia delante desde el desplazamiento 0, deteniéndose en cada cabecera local PK\x03\x04 que encuentra, leyendo el nombre del archivo y el método de compresión, y luego descomprimiendo el flujo deflate que le sigue. Deflate se autotermina: un flujo es una secuencia de bloques y el bloque final lleva un bit BFINAL puesto a 1, así que el decodificador puede encontrar dónde terminan los datos de una entrada aunque el campo de tamaño de la cabecera local lo dejara a cero un escritor en streaming. Cuando el flujo termina limpiamente, la herramienta registra un archivo recuperado, se salta cualquier descriptor de datos PK\x07\x08 final y continúa hasta el siguiente PK\x03\x04. Esto se ejecuta como TypeScript puro en tu pestaña — sin binario unzip, sin transmitir nada.

El resultado es que cada archivo escrito por completo antes de la interrupción vuelve, en orden, con su nombre y su ruta de carpeta originales. Si la descarga murió a mitad del cuarto de diez archivos, obtienes los tres primeros intactos y un cuarto parcial o descartado; los seis que nunca llegaron no se pueden conjurar, pero nunca fueron el objetivo. Una entrada "almacenada" (método 0, sin compresión — habitual para contenidos ya comprimidos como JPEG o MP4 metidos dentro del ZIP) es aún más sencilla de rescatar: sus bytes se copian tal cual hasta el punto de truncamiento, así que hasta un archivo grande llegado a medias suele dar un fragmento inicial usable en lugar de nada.

Ninguna herramienta puede devolver bytes que nunca llegaron a tu disco. Si la conexión se cayó al 70 %, el último 30 % de los datos comprimidos no existe localmente, y nada — ni esta página, ni la "Reparación" de WinRAR, ni una suite de recuperación de pago — puede reconstruirlo. La única solución real para la cola que falta es volver a descargar el archivo desde el origen, idealmente con un cliente que admita peticiones de rango HTTP (range requests) para que una transferencia interrumpida se reanude donde se detuvo en lugar de reiniciarse. Si el servidor envió un ETag o un Content-Length, comparar esa longitud con el tamaño de tu archivo parcial te dice exactamente cuánto falta de verdad.

Unos cuantos límites honestos. Un ZIP cifrado (una contraseña puesta al comprimir, bit 0 del indicador de propósito general) no se puede recorrer sin la contraseña, porque los datos de la entrada son texto cifrado sin estructura deflate que seguir. Un archivo muy grande escrito en formato ZIP64 mantiene sus propias estructuras finales — el registro EOCD de ZIP64 (PK\x06\x06) y su localizador (PK\x06\x07) — que se pierden con la cola exactamente igual que el EOCD clásico, pero el recorrido hacia delante recupera las entradas locales sea cual sea el formato. Y una descarga tan corta que solo llegó un fragmento de la primera cabecera local no tiene nada que recorrer. Todo lo que hay entre esos extremos es recuperable.

Como toda la operación ocurre en tu navegador, el archivo nunca se copia a un servidor solo para mirar dentro — algo que importa cuando un paquete de "descargar todo" contiene documentos fiscales, historiales de chat exportados o código fuente privado. Puedes abrir la pestaña Red, ejecutar la recuperación y confirmar que no sale ni un byte del archivo de tu equipo.