Repáralo ahora
- Suelta el archivo
- La reparación ocurre en local
- Descarga el resultado
La opción «Descargar carpeta» de Google Drive y «Descargar como .zip» de Dropbox fallan igual cuando se cae la conexión: te quedas con un ZIP que ninguna herramienta abre. La razón casi siempre es de lo más corriente — el archivo está truncado, le falta el índice de la cola — y no que su contenido esté revuelto. Suelta el archivo arriba y la herramienta lee su estructura real en tu navegador, localiza las entradas que se escribieron por completo antes de que se detuviera la transferencia y extrae esas, en lugar de rechazar todo el archivo. No se sube nada.
Truncamiento frente a bit-rot: dos fallos distintos, una etiqueta
Dos problemas completamente distintos reciben el mismo nombre de «archivo dañado», y la solución depende de cuál tengas. El truncamiento significa que el archivo es corto: la descarga se detuvo antes de que llegara el último byte, así que al archivo le falta la cola. El bit-rot —aquí, un error de bytes introducido durante el tránsito— significa que el archivo tiene la longitud correcta pero algunos bytes están mal: un bloque volteado o en ceros en algún punto intermedio. Distinguirlos lleva diez segundos y lo decide todo sobre lo que puedes recuperar.
Comprueba primero el tamaño. Tanto Google Drive como Dropbox muestran el número real de bytes en el panel de detalles del archivo; compáralo con la copia de tu disco. Si la tuya es más pequeña, está truncada — sin más. Un ZIP truncado ha perdido su registro End Of Central Directory —la firma PK\x05\x06 que vive en los últimos 22 bytes largos del archivo—, así que un extractor que busca al final para leer el índice encuentra basura o nada. Por eso unzip dice End-of-central-directory signature not found o cannot find zipfile directory, 7-Zip y WinRAR dicen «Unexpected end of archive», y el extractor integrado de Windows dice «The Compressed (zipped) Folder is invalid.»
Si el tamaño coincide pero la extracción sigue fallando, tienes bit-rot. El índice está presente, así que la herramienta entra en el archivo y falla archivo por archivo: 7-Zip informa «Data error» o «CRC failed», y unzip -t imprime bad CRC contra las entradas concretas. Cada entrada ZIP guarda un CRC-32 de sus datos sin comprimir tanto en su cabecera local como en el directorio central; cuando los bytes descomprimidos no dan ese valor, la herramienta sabe que ese archivo está dañado — pero los demás normalmente no lo están.
Por qué una descarga de la nube daña un archivo, para empezar
Las transferencias interrumpidas truncan archivos más que ninguna otra cosa, y el almacenamiento en la nube añade sus propios matices. Cuando usas «Descargar carpeta» de Drive o «Descargar como .zip» de Dropbox, el servidor construye el ZIP sobre la marcha y te lo envía en streaming. Como está comprimiendo mientras envía, no conoce de antemano el tamaño ni el CRC de cada archivo, así que activa el bit 3 de propósito general en cada entrada y escribe el CRC y los tamaños después de los datos comprimidos, en un descriptor de datos (PK\x07\x08). Si la conexión se cae a mitad del flujo, te queda un prefijo limpio de un ZIP válido pero sin directorio central alguno — truncamiento de manual.
Las carpetas grandes lo empeoran porque cruzan el umbral de ZIP64: más de 65.535 archivos o 4 GiB de datos. Un archivo ZIP64 mantiene un registro EOCD ZIP64 PK\x06\x06 y un localizador PK\x06\x07 justo al final — todavía más metadatos de cola que perder cuando la transferencia se detiene antes de tiempo.
Dos trampas propias de la nube se hacen pasar por corrupción. Primera: Google Drive se niega a analizar en busca de virus los archivos grandes y sirve una página HTML intermedia en lugar de los bytes; si obtuviste el enlace con wget, curl o un script, tu «.zip» puede empezar en realidad por <!DOCTYPE html> en vez de PK\x03\x04 — es una página web, no un archivo comprimido. Segunda: los gestores de descarga por segmentos que cogen un archivo en rangos de bytes en paralelo pueden dejar un hueco o un bloque duplicado cuando un rango falla en silencio, produciendo un archivo de longitud completa con el centro dañado: bit-rot, no truncamiento. Abrir el archivo en un visor hexadecimal y comprobar si los primeros cuatro bytes son 50 4B 03 04 (PK\x03\x04) te dice al instante si siquiera tienes un ZIP.
Qué extrae realmente el rescate
Suelta el archivo arriba y la herramienta ignora el índice que falta o que no se puede leer y recorre el archivo hacia delante desde el principio, capturando cada cabecera de archivo local PK\x03\x04 y descomprimiendo el flujo deflate que le sigue mientras aguanten los bytes. En un archivo truncado, cada entrada que se escribió por completo antes del corte vuelve intacta; solo el único archivo que quedó a caballo del punto de truncamiento vuelve parcial o se pierde. En el caso del bit-rot, las entradas cuyo CRC-32 sigue cuadrando se extraen con normalidad, y la herramienta marca la entrada concreta cuyo hash falla en lugar de condenar todo el archivo. Esto es TypeScript puro ejecutándose en tu pestaña — sin binario unzip, sin transmitir nada.
RAR y 7z siguen el mismo principio sobre estructuras distintas. Un RAR (firma Rar!\x1a\x07\x00 en la v4, Rar!\x1a\x07\x01\x00 en la v5) almacena los archivos en bloques independientes, así que los anteriores al daño aún se decodifican, y un RAR creado con un registro de recuperación se repara mucho mejor porque ese registro existe precisamente para reconstruir los bloques que faltan. Un .7z (firma 7z\xBC\xAF\x27\x1C) es el caso frágil: mantiene su base de datos de cabeceras en la cola y normalmente usa compresión sólida que encadena muchos archivos en un único flujo, así que una cola perdida o un error de bytes a mitad del flujo puede romper la descompresión de todo lo que viene después del último bloque intacto. La herramienta rescata lo que permiten los bloques supervivientes y lo dice con claridad cuando un flujo sólido no se puede continuar.
El límite honesto: los bytes que faltan siguen faltando
Nada puede recuperar bytes que nunca llegaron a tu disco. Si la descarga se detuvo al 70 %, el último 30 % de los datos comprimidos sencillamente no existe en local, y ninguna herramienta —ni esta, ni la propia función Repair de WinRAR, ni una suite de recuperación de pago— puede inventarlo. La verdadera solución para el truncamiento es volver a descargar desde Drive o Dropbox, evitando a ser posible una carpeta comprimida en el servidor: baja el archivo original directamente, o la carpeta en lotes más pequeños, para que la transferencia tenga más probabilidades de terminar.
El bit-rot dentro de un flujo comprimido es igual de implacable al nivel del único archivo dañado. Deflate es un flujo con estado —un solo bit volteado descarrila la decodificación Huffman/LZ77 a partir de ese punto—, así que la entrada afectada suele volver truncada en el error, aunque su CRC-32 te dijera exactamente qué archivo se llevó el golpe. Los archivos cifrados (ZIP AES-256, protección por contraseña de RAR o 7z) no se pueden escanear sin la contraseña, porque las entradas son texto cifrado. Lo que el rescate evita de forma fiable es que un archivo que llegó a medias sea una pérdida total: si nueve de diez archivos llegaron, no hay razón para perder los nueve mientras se persigue el décimo. Y como todo se ejecuta en local, un archivo con registros financieros, código fuente o documentos personales nunca se copia a un servidor desconocido solo para mirar dentro — abre la pestaña Red y confirma que no sale ni un byte.
Qué puede y qué no puede reparar
Puede reparar
- Un ZIP truncado por una descarga de Drive/Dropbox interrumpida — las entradas escritas antes del corte se recuperan recorriendo las cabeceras locales PK\x03\x04
- Bit-rot en una entrada: los archivos cuyo CRC-32 aún se verifica se extraen con normalidad, y la entrada dañada se marca en lugar de tumbar todo el archivo
- Carpetas comprimidas en el servidor que envían descriptores de datos en streaming (PK\x07\x08) y perdieron su directorio central por una conexión caída
- Descargas de carpeta ZIP64 (más de 65.535 archivos o 4 GiB) a las que les falta el registro PK\x06\x06 y el localizador PK\x06\x07 de la cola
- Archivos RAR en los que los bloques anteriores al daño aún se decodifican — muchísimo mejor con un registro de recuperación
- Archivos 7z hasta el último bloque de compresión (sólida) completo que sobrevivió
No puede reparar
- Cualquier archivo cuyos datos comprimidos estaban después del punto de truncamiento — esos bytes nunca llegaron a tu disco (mejor vuelve a descargar)
- Un «.zip» que en realidad es la página HTML de análisis antivirus de Google Drive — es una página web, no un archivo comprimido
- La única entrada golpeada por un error de bytes a mitad del flujo, pasado el punto donde se rompió su flujo deflate
- Un flujo sólido 7z más allá de su último bloque intacto (los archivos posteriores de la cadena no se pueden descomprimir)
- Archivos cifrados / protegidos con contraseña sin la contraseña (las entradas son texto cifrado)
Si una reparación falla, te decimos por qué (datos que faltan frente a estructura dañada), y nunca se te cobra por una reparación fallida.