«Unexpected end of archive» — qué significa y qué se recupera aún

El error exacto, y qué te está diciendo

Según la herramienta que abra el archivo, cambia la redacción pero no el significado. WinRAR muestra:

Unexpected end of archive, y a menudo junto a él The archive is either in unknown format or damaged.

7-Zip redacta el mismo fallo como Unexpected end of data o, cuando el daño alcanza el principio del archivo, Cannot open the file as archive. En Linux o macOS, el comando unzip informa de unexpected end of file o del más preciso End-of-central-directory signature not found.

Todas y cada una de esas cadenas describen una única situación: la herramienta se quedó sin archivo antes de lo que el formato decía que debería. Un ZIP o un RAR tienen una forma definida, con estructuras concretas que se supone que están en sitios conocidos. Cuando el archivo es más corto de lo que esa forma exige, la herramienta llega al final de forma inesperada y se detiene. Eso es lo que significa «unexpected» aquí. No es un fallo aleatorio, y no suelen ser datos revueltos. Es un archivo al que le falta la parte final.

Un ZIP guarda su índice justo al final

Para entender por qué es tan perjudicial que falte la parte final, ayuda saber cómo está distribuido un ZIP. Un archivo comprimido son dos cosas cosidas juntas. Primero vienen las entradas: cada archivo que añadiste, comprimido y escrito uno tras otro, y cada uno precedido por una pequeña cabecera local que da su nombre y su tamaño. Segundo, después de todas las entradas, viene el directorio central: una tabla que lista todos los archivos del conjunto y el desplazamiento exacto en bytes donde empieza cada uno.

Un ZIP guarda primero los archivos y, al final, el directorio que los lista. Una descarga truncada pierde el directorio, no los archivos anteriores a él.

El directorio central es el índice del archivo. Cuando haces doble clic en un ZIP, la herramienta salta al final, lee ese directorio y lo usa para mostrarte la lista de archivos. Poner el índice al final es deliberado: permitía que el formato ZIP original añadiera archivos a un conjunto sin reescribirlo entero. El problema es que la única estructura que una herramienta necesita primero es la única que se guarda la última, así que cualquier daño que empiece al final del archivo cae de lleno sobre el índice. Es el mismo patrón que hace frágil a una hoja de cálculo, porque unarchivo .xlsx es en realidad un ZIP con su propio directorio al final.

Por qué una descarga cortada pierde el índice, no los archivos

Un ZIP se escribe y se transfiere de principio a fin. Cuando una descarga se atasca, una sincronización en la nube se rinde o se saca un pendrive USB a mitad de la copia, el archivo que aterriza en tu disco es lo que llegara antes de la interrupción: la parte inicial está intacta y la final simplemente no está. Como el directorio vive al final, es la primera baja de cualquier truncamiento. Las entradas del principio, los archivos comprimidos de verdad, siguen ahí sin tocar.

Esa es toda la razón por la que el error es tan recuperable. La herramienta no encuentra el directorio, así que se niega a abrir el archivo de la forma normal e informa de un final inesperado. Pero los archivos en sí nunca fueron el problema. Una pasada de reparación ignora el directorio ausente y recorre el archivo desde el principio, leyendo cada cabecera local, tomando los datos comprimidos que la siguen y reconstruyendo un directorio nuevo a partir de lo que encuentra. El archivo vuelve a abrirse, listando cada entrada que sobrevivió físicamente.

Una comprobación rápida distingue el truncamiento de algo peor: compara el tamaño del archivo con el original si lo conoces. Un archivo de 240 MB que llegó como 180 MB es un truncamiento de manual, y los 60 MB que faltan no están dañados, están en otra parte. Por eso también volver a descargar es el primer paso. Los bytes que faltan siguen existiendo en el origen, y una copia limpia gana a cualquier rescate de una parcial. Si el archivo venía de una descarga web o de un adjunto de correo, prueba esa vía antes de reparar. La versión específica de Windows de esta misma historia, donde el extractor integrado del Explorador es más estricto que las herramientas de arriba, se trata en «La carpeta comprimida (en zip) no es válida».

Extracción parcial: sacar lo que sobrevivió

Cuando no hay una copia limpia disponible, la extracción parcial es el objetivo realista, y a menudo es un resultado muy bueno. Como cada entrada lleva su propia cabecera local y su propio bloque comprimido, los archivos guardados antes del corte son independientes de los perdidos después de él. Una herramienta de reparación lee el archivo de forma secuencial y recupera cada entrada hasta que llega al punto donde los datos se truncaron. El resultado no es de todo o nada; es «volvieron 42 de 50 archivos», siendo los ocho que faltan los que aún iban en camino cuando la transferencia se detuvo.

Hay un caso límite que merece nombrarse con honestidad. El archivo que queda justo en el corte suele estar a medias: su cabecera y la primera parte de sus datos comprimidos llegaron, pero el resto no. Ese archivo puede extraerse como una versión truncada de sí mismo, o no descomprimirse en absoluto, según el formato y hasta qué punto avanzado cayera el corte. Todo lo anterior a él se extrae sin problemas. Así que una expectativa razonable es: archivos completos hasta el corte, un archivo posiblemente dañado en la frontera, y nada más allá. La opción «mantener archivos dañados» de WinRAR y los ajustes equivalentes de otras herramientas existen precisamente para volcar ese archivo de la frontera por lo que valga.

Cuándo no hay realmente nada que hacer

La reparación estructural reconstruye el índice alrededor de los datos que sobrevivieron. No puede fabricar datos que no están ahí, y unas cuantas situaciones quedan fuera de lo que cualquier herramienta puede hacer. Ser directo sobre ellas te ahorra tiempo:

• El daño está en medio del flujo, no al final. DEFLATE, la compresión que usa el ZIP, no tiene redundancia: es un flujo continuo donde cada parte depende de lo que vino antes. Si hay bytes corruptos o que faltan dentro del bloque comprimido de un archivo, en lugar de un corte limpio al final, la descompresión pierde la sincronía en el daño y todo lo que sigue a ese punto del archivo es irrecuperable. Puede que aún obtengas el principio de ese archivo, pero no el archivo entero.
• El archivo está cifrado. Un archivo protegido con contraseña o cifrado con AES puede repararse estructuralmente, con su directorio reconstruido y sus entradas de nuevo listadas, pero los datos comprimidos siguen cifrados. Sin la contraseña, las entradas recuperadas no se pueden descifrar en archivos utilizables. La reparación arregla el contenedor; no rompe el cifrado, y ninguna herramienta legítima afirma lo contrario.
• Falta una parte necesaria de un conjunto multivolumen.Un archivo dividido (.z01, .z02, o .part1.rar y compañía) guarda un único flujo continuo repartido por varios archivos. Si una parte intermedia nunca llegó, el flujo tiene un hueco real, y los volúmenes posteriores al hueco no se pueden unir a los anteriores.
• El archivo está casi vacío. Un archivo que volvió como unos pocos kilobytes de un original de varios megabytes, o que se lee como casi todo ceros, no contiene entradas reales que recuperar. Ese es un problema de descarga o de recuperación, no de reparación.

Fuera de esos casos, un archivo truncado es uno de los problemas de corrupción más amables a los que enfrentarse, porque la propia distribución del formato hace que los archivos supervivientes sean alcanzables de uno en uno.