ZIP di un download interrotto

Uno ZIP viene scritto dall'inizio alla fine, ma viene letto dalla fine all'inizio. Ogni file che hai aggiunto è memorizzato come voce di file locale — un'intestazione che inizia con la firma PK\x03\x04, che porta con sé il nome, il metodo di compressione (0 = memorizzato, 8 = deflate) e a seguire i byte compressi —, ma l'indice autorevole di dove vivono quelle voci è la directory centrale (record PK\x01\x02) scritta per ultima, subito prima del record End Of Central Directory da 22 byte, PK\x05\x06. Un estrattore apre il file posizionandosi alla fine e percorrendolo all'indietro in cerca di quella firma PK\x05\x06 — fino a circa 65.557 byte indietro, perché il record termina con un campo commento di lunghezza variabile. Solo dopo aver trovato l'EOCD sa quante voci contiene l'archivio e dove inizia ciascun record della directory centrale.

Ora immagina il download fermatosi al 70 %. I byte che non sono mai arrivati sono quelli scritti per ultimi: la directory centrale e l'EOCD. L'estrattore si posiziona alla fine, percorre all'indietro, non vede mai PK\x05\x06 e si arrende prima di toccare un solo file. È questa l'origine esatta del "End-of-central-directory signature not found" di unzip, dell'"Unexpected end of archive" di 7-Zip e WinRAR, del "The Compressed (zipped) Folder is invalid" dell'Esplora file, e dell'"Unable to expand … (Error 2)" dell'Utility Archivio di macOS. Nessuno di questi significa che i file memorizzati siano stravolti — significano che la tabella dei contenuti in coda è scomparsa.

I download interrotti sono particolarmente soggetti a questo per come vengono generati molti ZIP. Un archivio assemblato al volo da un server — uno "scarica tutto" da un'archiviazione cloud, lo ZIP gemello del tarball del codice sorgente di un repository GitHub, un pacchetto di esportazione — di solito viene inviato in streaming: il bit 3 dell'indicatore di uso generale (0x0008) è attivo, la dimensione compressa e il CRC-32 di ogni intestazione locale vengono lasciati a zero, e i valori reali vengono aggiunti dopo i dati della voce in un descrittore di dati (PK\x07\x08). Per quegli archivi la directory centrale è l'unico posto in cui le dimensioni sono garantite, così perdere la coda è doppiamente dannoso per un estrattore normale. Il file scritto a metà che il tuo browser si è lasciato dietro — un .crdownload di Chrome/Edge, un .part di Firefox, o un .zip semplicemente più corto del Content-Length della risposta — contiene comunque ogni voce completa fino all'interruzione e nulla di successivo.

Il recupero non ha affatto bisogno dell'indice mancante, perché in uno ZIP ogni voce locale si descrive da sé. Invece di posizionarsi alla fine, lo strumento percorre il file in avanti dall'offset 0, fermandosi a ogni intestazione locale PK\x03\x04 che trova, leggendo il nome del file e il metodo di compressione, e poi decomprimendo il flusso deflate che segue. Deflate si autotermina: un flusso è una sequenza di blocchi e il blocco finale porta un bit BFINAL impostato a 1, così il decoder può trovare dove finiscono i dati di una voce anche quando il campo dimensione dell'intestazione locale è stato lasciato a zero da uno scrittore in streaming. Quando il flusso termina in modo pulito, lo strumento registra un file recuperato, salta l'eventuale descrittore di dati PK\x07\x08 finale e continua fino alla successiva PK\x03\x04. Tutto questo gira come puro TypeScript nella tua scheda — senza binario unzip, senza trasmettere nulla.

Il risultato è che ogni file scritto per intero prima dell'interruzione torna, in ordine, con il nome e il percorso di cartella originali. Se il download è morto a metà del quarto di dieci file, ottieni i primi tre intatti e un quarto parziale o scartato; i sei che non sono mai arrivati non si possono evocare, ma non erano quello il punto. Una voce "memorizzata" (metodo 0, senza compressione — comune per contenuti già compressi come JPEG o MP4 inseriti dentro lo ZIP) è ancora più semplice da recuperare: i suoi byte vengono copiati tali e quali fino al punto di troncamento, così anche un file grande arrivato a metà dà spesso un frammento iniziale utilizzabile invece di niente.

Nessuno strumento può restituire byte che non sono mai arrivati sul tuo disco. Se la connessione è caduta al 70 %, l'ultimo 30 % dei dati compressi non esiste in locale, e niente — né questa pagina, né la "Riparazione" di WinRAR, né una suite di recupero a pagamento — può ricostruirlo. L'unica vera soluzione per la coda mancante è riscaricare l'archivio dalla sorgente, idealmente con un client che supporti le richieste di intervallo HTTP (range requests), così un trasferimento interrotto può riprendere da dove si è fermato invece di ripartire da capo. Se il server ha inviato un ETag o un Content-Length, confrontare quella lunghezza con la dimensione del tuo file parziale ti dice esattamente quanto manca davvero.

Qualche limite onesto. Uno ZIP cifrato (una password impostata al momento della compressione, bit 0 dell'indicatore di uso generale) non può essere percorso senza la password, perché i dati della voce sono testo cifrato senza struttura deflate da seguire. Un archivio molto grande scritto in formato ZIP64 mantiene proprie strutture finali — il record EOCD di ZIP64 (PK\x06\x06) e il suo localizzatore (PK\x06\x07) — che si perdono con la coda esattamente come l'EOCD classico, ma il percorso in avanti recupera comunque le voci locali qualunque sia il formato. E un download così corto da aver ricevuto solo un frammento della primissima intestazione locale non ha nulla da percorrere. Tutto ciò che sta tra questi due estremi è recuperabile.

Poiché l'intera operazione avviene nel tuo browser, l'archivio non viene mai copiato su un server solo per guardarci dentro — cosa che conta quando un pacchetto "scarica tutto" contiene documenti fiscali, cronologie di chat esportate o codice sorgente privato. Puoi aprire la scheda Rete, eseguire il recupero e confermare che non esce nemmeno un byte del file dalla tua macchina.