"Unexpected end of archive"

Il messaggio che vedi è un indizio forte su quale strumento e quale formato hai davanti — vale la pena decodificarlo prima di fare qualsiasi altra cosa, perché ognuno fallisce in un punto leggermente diverso.

• WinRAR — "Unexpected end of archive." Il classico. WinRAR ha raggiunto la fine del file mentre l'intestazione di un blocco o il marcatore di fine archivio dicevano ancora che doveva esserci dell'altro. Vale sia per i .rar sia per gli ZIP che WinRAR apre.
• 7-Zip — "Unexpected end of data" (a volte "Unexpected end of archive"). 7-Zip distingue un troncamento pulito ("end of data") da una firma sbagliata ("is not archive") da un byte alterato ("Data error"). "End of data" significa in particolare che il flusso si è fermato a metà — un troncamento, non uno scombinamento.
• Info-ZIP unzip — "cannot find zipfile directory … End-of-central-directory signature not found." unzip cerca all'indietro dalla coda il marcatore PK\x05\x06 e non lo trova mai, quindi non riesce nemmeno a costruire l'elenco dei file. I dati possono essere integri; è l'indice a essere sparito.
• Esplora risorse di Windows — "The compressed (zipped) folder is invalid." L'estrattore integrato è il meno specifico di tutti. Di solito è la stessa storia dell'EOCD mancante — vedi "Compressed folder is invalid" per quella esatta formulazione.
• Utility Archivio di macOS — "Error 2 – No such file or directory." Notoriamente opaco: il "file" che non riesce a trovare è il record della central directory che si aspettava alla fine. Stesso troncamento, messaggio unicamente inutile.
• Python zipfile — BadZipFile: File is not a zip file, oppure un errore su .read(). Se l'EOCD manca, zipfile si rifiuta del tutto di aprire; se solo una voce finale è troncata, apre senza problemi e fallisce soltanto quando leggi quel membro.
• GNU tar / gzip — "Unexpected EOF in archive" / "unexpected end of file." Una struttura del tutto diversa (nessun indice centrale) — trattata più avanti.

Se la tua formulazione è in questo elenco, hai quasi certamente un file corto, non uno scombinato — e il recupero è lo stesso indipendentemente da quale strumento l'ha segnalato.

Ogni formato di archivio conserva una piccola struttura critica che dice "l'archivio è completo ed ecco dove è indicizzato il suo contenuto". Quella struttura vive in fondo o vicino alla coda del file — che è esattamente la regione che un troncamento distrugge per prima. Sapere quale marcatore manca ti dice quanto è recuperabile.

• ZIP — End Of Central Directory (PK\x05\x06). Uno ZIP è una sequenza di voci locali (ognuna inizia con PK\x03\x04), poi una central directory di record PK\x01\x02, infine l'EOCD di 22 byte. L'EOCD è l'indice. Gli archivi grandi o oltre i 4 GB aggiungono un record EOCD ZIP64 (PK\x06\x06) e un localizzatore (PK\x06\x07) subito prima. Perdi la coda e perdi l'indice — ma non le voci locali, che si autodescrivono.
• RAR 4 — blocco di fine archivio (HEAD_TYPE 0x7B). Dopo la firma Rar!\x1A\x07\x00, RAR4 memorizza blocchi decodificabili in modo indipendente e termina con un blocco conclusivo. I file precedenti al taglio si decodificano ancora; un RAR creato con un record di recupero può ricostruire direttamente i blocchi mancanti.
• RAR 5 — intestazione di fine archivio (header di tipo 5). Firma Rar!\x1A\x07\x01\x00, un formato di intestazione ridisegnato, stessa idea: un'intestazione di fine dedicata che un troncamento rimuove.
• 7z — lo Start Header punta a un End Header in coda. Dopo la firma 37 7A BC AF 27 1C e due byte di versione c'è uno Start Header di 20 byte che contiene NextHeaderOffset, NextHeaderSize e un CRC — un puntatore al database delle intestazioni proprio alla fine del file. Tronca il file e quel puntatore mira oltre l'ultimo byte. Peggio ancora, .7z usa per impostazione predefinita la compressione solida, concatenando i file in un unico flusso, così una coda perduta può rompere ogni file dopo l'ultimo blocco completo.

Lo schema è universale: i metadati di cui l'estrattore ha bisogno per primi sono memorizzati per ultimi, quindi sono i metadati che un troncamento uccide per primi. Ecco perché "unexpected end" è così comune ed ecco perché i dati stessi di solito sono ancora recuperabili.

Tar è quello fuori dagli schemi, e merita una nota a sé perché la diagnosi è diversa. Un .tar non ha alcun indice centrale: è una semplice sequenza di record da 512 byte — un blocco di intestazione per file (l'intestazione ustar con nome, dimensione e una somma di controllo), poi i dati del file riempiti fino al successivo confine di 512 byte. L'archivio è dichiarato concluso da due blocchi consecutivi di 512 byte tutti a zero. Se quei blocchi zero finali non sono mai arrivati, tar stampa "Unexpected EOF in archive" anche se ogni file scritto per intero è perfettamente estraibile — tar percorre semplicemente i record dall'inizio alla fine, quindi recupera tutto fino al byte a cui si è esaurito.

Un .tar.gz (o .tgz) avvolge quel flusso tar in gzip. Un membro gzip è un'intestazione di 10 byte (1F 8B 08 …), il flusso deflate e un trailer di 8 byte che contiene un CRC-32 dei dati non compressi e l'ISIZE (dimensione originale mod 2³²). Troncalo e gzip segnala "unexpected end of file" — decomprime correttamente fino al taglio, poi non ha alcun trailer con cui verificare. Il recupero segue lo stesso principio dello ZIP: decodificare in avanti fin dove i byte integri lo permettono.

"Unexpected end" è il sintomo. La causa decide la mossa migliore, e sono tre:

• Un download del browser che si è bloccato o è stato annullato. Se l'archivio veniva da un link e il trasferimento non è mai finito (un .crdownload/.part rimasto lì, un "Failed – Network error"), la meccanica esatta di quali byte sopravvivono è particolare — vedi un download ZIP interrotto.
• Un file cloud che sembra completo ma non lo è. Drive, Dropbox e OneDrive possono consegnarti una pagina di errore HTML rinominata .zip, oppure una sincronizzazione parziale — un troncamento che si traveste da corruzione. Per distinguere un file corto da un vero bit-rot, vedi come diagnosticare un archivio cloud danneggiato.
• L'origine stessa è corta. Se l'originale è davvero privo della sua coda, nessuno strumento può inventare i byte assenti — ma IntactFile estrae comunque tutto ciò che è stato scritto prima del taglio. Trascinalo qui sopra per recuperare le voci integre.

In ogni caso il recupero è identico e gira interamente nella tua scheda: IntactFile ignora il marcatore di fine mancante, scandaglia in avanti dall'inizio del file catturando ogni voce integra e decomprime ciò che i byte sopravvissuti permettono — puro TypeScript, nessuna utility di archiviazione installata, e puoi guardare la scheda Rete confermare che zero byte di un archivio privato lasciano mai la tua macchina.