Il database "History" di Chrome è malformato

La tua cronologia non è salvata in un formato proprietario — è un database SQLite che risiede nella directory del profilo di Chrome: su Windows %LOCALAPPDATA%\Google\Chrome\User Data\Default\History, su macOS ~/Library/Application Support/Google/Chrome/Default/History e su Linux ~/.config/google-chrome/Default/History (Chromium usa ~/.config/chromium/…, Edge …/Microsoft/Edge/…, Brave …/BraveSoftware/Brave-Browser/…). Il file si chiama History senza estensione, ed è per questo che molti non si rendono conto di poterlo aprire in un qualsiasi strumento SQLite — rinomina una copia in History.db e DB Browser for SQLite la leggerà all'istante.

All'interno ci sono le tabelle che compongono il tuo registro di navigazione. urls conserva una riga per ogni pagina che hai visitato — le sue colonne sono id, url, title, visit_count, typed_count, last_visit_time e hidden. visits è la linea temporale: ogni riga ha una chiave esterna url che rimanda a urls.id, un visit_time, un from_visit che punta alla visita precedente (così si ricostruiscono le catene avanti/indietro) e una maschera di bit transition il cui byte basso è il tipo principale (LINK = 0, TYPED = 1, AUTO_BOOKMARK = 2, RELOAD = 8). Accanto a esse ci sono keyword_search_terms, downloads e downloads_url_chains, segments/segment_usage (che alimentano le scorciatoie della Nuova scheda) e una piccola tabella meta con le righe version e last_compatible_version che indicano a Chrome quale schema sta guardando.

Un dettaglio fa inciampare chiunque esporti la cronologia: i timestamp non sono in tempo Unix. last_visit_time e visit_time sono memorizzati come microsecondi dal 1601-01-01 00:00:00 UTC (l'epoca di Chrome/WebKit). Per leggerne uno come data normale, dividi per 1.000.000 e sottrai 11.644.473.600 secondi. Il recupero conserva gli interi grezzi esattamente come si trovano sul disco, quindi le date sopravvivono alla ricostruzione — le converti soltanto dopo.

Un database SQLite è un array piatto di pagine di dimensione fissa — Chrome usa il valore predefinito di 4096 byte. La pagina 1 porta l'intestazione e lo schema; ogni tabella, incluse urls e visits, è un b-tree le cui pagine interne puntano verso le pagine foglia che contengono le tue righe reali. Chrome esegue il database History in modalità WAL (write-ahead logging), quindi accanto a esso vedrai normalmente file gemelli chiamati History-wal e History-shm; le versioni più vecchie e alcuni profili lasciano invece un journal di rollback chiamato History-journal.

Proprio quel meccanismo di file gemelli è il punto da cui si insinua il danno. Se la macchina va in blackout, il disco si riempie o Chrome viene terminato a metà di un checkpoint, un frame del WAL può essere riscritto solo a metà nel file principale — una singola pagina interna resta con un puntatore di cella incoerente o con un conteggio di pagine che non corrisponde alla dimensione del file. SQLite segue quel puntatore, trova qualcosa che non è una pagina b-tree valida e si ferma con Error: database disk image is malformed (11) — codice di risultato SQLITE_CORRUPT. Esegui PRAGMA integrity_check e vedrai i dettagli: righe come *** in database main ***, Page 214: btreeInitPage() returns error code 11, row 1803 missing from index urls_url_index o wrong # of entries in index visits_url_index.

La cosa importante: il motore si ferma alla prima incoerenza, ma le pagine che non ha mai raggiunto sono di solito perfette, e le tue righe sono ancora intatte nelle loro pagine foglia. È la stessa storia dell'indice moov mancante di un video o della directory centrale rotta di uno ZIP — a rompersi è stata la mappa, non i dati. Ecco perché una ricostruzione a livello di pagina recupera così tanto là dove aprire il file normalmente non recupera nulla.

Un file History malformato non si ripara sul posto — si legge tutto ciò che è ancora decodificabile e lo si scrive in un database nuovo di zecca, esattamente come funziona il comando .recover di SQLite. Lo scanner legge ogni pagina localmente, ricostruisce lo schema a partire dalle definizioni sopravvissute, poi percorre il b-tree di ogni tabella e decodifica i record autodescrittivi nelle sue pagine foglia. Le righe che la catena di puntatori non riesce più a raggiungere vengono trovate con una scansione grezza delle pagine, e tutto ciò che si decodifica ma non corrisponde a nessuna tabella conosciuta viene scritto in una tabella lost_and_found invece di essere scartato.

In pratica, questo restituisce l'essenziale della tua cronologia: la tabella urls (indirizzi, titoli di pagina, visit_count, last_visit_time), la linea temporale visits con i suoi tipi di transition e le sue catene from_visit, e — dove le loro pagine sono intatte — keyword_search_terms, downloads e i dati di segments. Se hai ancora il file gemello History-wal, aggiungilo nello slot opzionale dopo aver rilasciato il file principale: i suoi frame confermati vengono sovrapposti prima della scansione, così la ricostruzione riflette l'ultima transazione confermata invece dell'ultimo checkpoint — spesso le ultime ore di navigazione. L'output è un file SQLite nuovo e apribile che scarichi; rinominalo di nuovo in History, mettilo nella cartella del profilo con Chrome chiuso e la tua cronologia riappare, oppure interrogalo semplicemente in un qualsiasi visualizzatore SQLite.

Il recupero restituisce ciò che è fisicamente presente; non può inventare ciò che è stato sovrascritto. Le righe che sono state troncate in fondo al file, o le cui pagine sono state riutilizzate dopo una cancellazione, sono sparite — nessuno strumento può riportarle indietro. La perdita più grande con Chrome nello specifico è il tempo: quando Chrome apre un file History che considera malformato, spesso lo cancella e ne crea uno nuovo e vuoto all'istante, così l'originale danneggiato viene sovrascritto sul posto. Se è già successo, chiudi Chrome immediatamente e recupera da un backup o da una copia vecchia di History/History-wal — il file vuoto che l'ha sostituito non ha nulla al suo interno da trovare.

Due avvertenze minori, dette con chiarezza. I valori recuperati tornano come la loro classe di archiviazione su disco, quindi l'affinità dichiarata di una colonna potrebbe non essere riapplicata — i timestamp restano gli interi di microsecondi corretti, li converti solo tu. E i dati recuperati da un database danneggiato sono sempre sospetti: lo dice la documentazione stessa di SQLite, e poiché una scansione grezza legge anche le pagine della freelist, un URL cancellato in precedenza può occasionalmente riaffiorare. Il report di recupero indica tabella per tabella cosa è uscito e cosa è stato estratto con la scansione grezza. Niente di tutto questo richiede un server: il file History — che è una mappa di ogni posto in cui sei stato — viene letto dal tuo disco e ricostruito nella tua scheda, e puoi osservare la scheda Rete per confermare che escono 0 byte.