"Unexpected end of archive"

El mensaje que ves es una pista sólida sobre qué herramienta y qué formato tienes entre manos — vale la pena descifrarlo antes de hacer nada, porque cada una falla en un punto ligeramente distinto.

• WinRAR — "Unexpected end of archive." El clásico. WinRAR llegó al final del archivo mientras la cabecera de un bloque o el marcador de fin de archivo aún decían que debía haber más. Vale tanto para los .rar como para los ZIP que WinRAR abre.
• 7-Zip — "Unexpected end of data" (a veces "Unexpected end of archive"). 7-Zip distingue un truncamiento limpio ("end of data") de una firma incorrecta ("is not archive") y de un byte alterado ("Data error"). "End of data" significa en concreto que el flujo se detuvo a medias — un truncamiento, no un revoltijo.
• Info-ZIP unzip — "cannot find zipfile directory … End-of-central-directory signature not found." unzip busca hacia atrás desde la cola tratando de hallar PK\x05\x06 y nunca lo encuentra, así que ni siquiera puede construir su lista de archivos. Los datos pueden estar bien; lo que se ha perdido es el índice.
• Explorador de Windows — "The compressed (zipped) folder is invalid." El extractor integrado es el menos específico de todos. Suele ser la misma historia del EOCD ausente — consulta "Compressed folder is invalid" para ese mensaje exacto.
• Utilidad de Archivo de macOS — "Error 2 – No such file or directory." Famosamente opaco: el "archivo" que no encuentra es el registro del directorio central que esperaba al final. El mismo truncamiento, con un mensaje excepcionalmente inútil.
• Python zipfile — BadZipFile: File is not a zip file, o un error al hacer .read(). Si falta el EOCD, zipfile se niega siquiera a abrir; si solo una entrada tardía está truncada, abre sin problema y falla únicamente cuando lees ese miembro.
• GNU tar / gzip — "Unexpected EOF in archive" / "unexpected end of file." Una estructura completamente distinta (sin índice central alguno) — la tratamos más abajo.

Si tu mensaje está en esta lista, casi con seguridad tienes un archivo corto, no uno revuelto — y la recuperación es la misma sin importar qué herramienta lo haya informado.

Todo formato de archivo comprimido guarda una pequeña estructura crítica que dice "el archivo está completo y aquí está indexado su contenido." Esa estructura vive en la cola del archivo, o cerca de ella — que es justo la región que un truncamiento destruye primero. Saber qué marcador falta te dice cuánto se puede rescatar.

• ZIP — End Of Central Directory (PK\x05\x06). Un ZIP es una serie de entradas locales (cada una empezando por PK\x03\x04), luego un directorio central de registros PK\x01\x02 y, por último, el EOCD de 22 bytes. El EOCD es el índice. Los archivos grandes o de más de 4 GB añaden un registro EOCD ZIP64 (PK\x06\x06) y un localizador (PK\x06\x07) justo antes. Pierde la cola y pierdes el índice — pero no las entradas locales, que se describen a sí mismas.
• RAR 4 — bloque de fin de archivo (HEAD_TYPE 0x7B). Tras la firma Rar!\x1A\x07\x00, RAR4 almacena bloques decodificables de forma independiente y termina con un bloque de cierre. Los archivos anteriores al corte siguen decodificándose; un RAR creado con un registro de recuperación puede reconstruir de golpe los bloques que faltan.
• RAR 5 — cabecera de fin de archivo (tipo de cabecera 5). Firma Rar!\x1A\x07\x01\x00, un formato de cabecera rediseñado, la misma idea: una cabecera de final dedicada que un truncamiento elimina.
• 7z — la Start Header apunta a una End Header en la cola. Tras la firma 37 7A BC AF 27 1C y dos bytes de versión hay una Start Header de 20 bytes con NextHeaderOffset, NextHeaderSize y un CRC — un puntero a la base de datos de cabeceras al final mismo del archivo. Trunca el archivo y ese puntero apunta más allá del último byte. Peor aún, .7z usa por defecto compresión sólida, encadenando los archivos en un único flujo, así que una cola perdida puede romper todos los archivos posteriores al último bloque completo.

El patrón es universal: los metadatos que el extractor necesita primero se guardan los últimos, así que son los metadatos que un truncamiento mata primero. Por eso "unexpected end" es tan frecuente y por eso los datos en sí suelen seguir siendo recuperables.

Tar es la excepción, y merece su propia nota porque el diagnóstico es distinto. Un .tar no tiene ningún índice central: es una secuencia plana de registros de 512 bytes — un bloque de cabecera por archivo (la cabecera ustar con nombre, tamaño y una suma de comprobación), y luego los datos del archivo rellenados hasta el siguiente límite de 512 bytes. El archivo se declara terminado con dos bloques consecutivos de 512 bytes todo a cero. Si esos bloques de cero finales nunca llegaron, tar imprime "Unexpected EOF in archive" aunque cada archivo que se escribió por completo sea perfectamente extraíble — tar simplemente recorre los registros de principio a fin, así que recupera todo hasta el byte en que se quedó sin datos.

Un .tar.gz (o .tgz) envuelve ese flujo tar en gzip. Un miembro gzip es una cabecera de 10 bytes (1F 8B 08 …), el flujo deflate y un tráiler de 8 bytes con un CRC-32 de los datos sin comprimir y el ISIZE (el tamaño original módulo 2³²). Trúncalo y gzip informa de "unexpected end of file" — descomprime correctamente justo hasta el corte y luego no tiene tráiler contra el que verificar. El rescate sigue el mismo principio que en ZIP: decodificar hacia delante todo lo que permitan los bytes intactos.

"Unexpected end" es el síntoma. La causa decide tu mejor jugada, y hay tres:

• Una descarga del navegador que se atascó o se canceló. Si el archivo venía de un enlace y la transferencia nunca terminó (un .crdownload/.part que se quedó, un "Failed – Network error"), la mecánica de qué bytes exactos sobreviven es particular — consulta una descarga de ZIP interrumpida.
• Un archivo de la nube que parece completo pero no lo está. Drive, Dropbox y OneDrive pueden entregarte una página de error HTML renombrada como .zip, o una sincronización parcial — un truncamiento que se hace pasar por corrupción. Para distinguir un archivo corto de una degradación de bits real, consulta cómo diagnosticar un archivo comprimido dañado de la nube.
• El origen mismo es corto. Si al original le falta de verdad su cola, ninguna herramienta puede inventar los bytes ausentes — pero IntactFile aun así extrae todo lo escrito antes del corte. Suéltalo arriba para rescatar las entradas intactas.

En todos los casos, el rescate en sí es idéntico y se ejecuta enteramente en tu pestaña: IntactFile ignora el marcador de final ausente, escanea hacia delante desde el principio del archivo capturando cada entrada intacta y descomprime lo que los bytes supervivientes permitan — TypeScript puro, sin ninguna utilidad de archivos instalada, y puedes mirar la pestaña Red para confirmar que jamás salen de tu equipo ni un solo byte de un archivo privado.