Decodificare esadecimale

Spazi, due punti, virgole, a capo e prefissi `0x` vengono tolti prima di qualunque altra cosa, perché un dump arriva nella forma dello strumento che lo ha prodotto e ripulirlo a mano è esattamente il lavoro che si vuole evitare.

Quello che non si può ignorare è il conteggio. Un byte sono due cifre, quindi un numero dispari di cifre significa che manca qualcosa: una copia incompleta, un carattere perso in un a capo, un prefisso interpretato male. In quel caso non c’è nessuna interpretazione corretta — riempire con uno zero a sinistra o a destra dà due risultati diversi ed entrambi inventati — quindi viene detto invece di essere indovinato.

Un dump è spesso un file e non una stringa: un PNG, un pacchetto di rete, una struttura binaria. In quei casi non esiste nessun testo dietro, e la risposta corretta è dirlo insieme al numero di byte trovati.

La riga dei primi byte è già una diagnosi. `89 50 4e 47` è un PNG, `ff d8 ff` è un JPEG, `25 50 44 46` è un PDF, `50 4b 03 04` è uno ZIP e quindi anche un file di Office o un JAR. Se il tuo dump comincia con una di queste, non stai guardando del testo mal codificato ma un file, e la domanda successiva riguarda cosa ci faccia lì.

L’UTF-8 ha una struttura leggibile a occhio. I byte sotto `80` sono ASCII e valgono un carattere ciascuno; da `c2` a `df` comincia un carattere da due byte, da `e0` a `ef` uno da tre, da `f0` a `f4` uno da quattro. I byte da `80` a `bf` sono continuazioni e non compaiono mai da soli.

Per un testo italiano la regola pratica è più corta: un `c3` è quasi sempre l’inizio di una lettera accentata, perché `c3 a0` è `à`, `c3 a8` è `è` e `c3 b9` è `ù`. E un `e2` all’inizio di tre byte è quasi sempre punteggiatura tipografica o un simbolo di valuta: `e2 80 99` è l’apostrofo curvo, `e2 82 ac` è il simbolo dell’euro.

Se un dump comincia con `ef bb bf`, quello è il byte order mark in UTF-8: un carattere invisibile che alcuni editor di Windows mettono all’inizio di un file. Nel testo decodificato non si vede, e nel confronto fra due file conta come tre byte di differenza.

I danni sono di due specie. Nei formati che vogliono un inizio preciso rompe tutto: un JSON che comincia con un BOM viene rifiutato con un errore alla colonna 1 che non indica niente di visibile, e un file CSV mostra il primo nome di colonna con un carattere strano davanti. In un file di testo qualsiasi non fa niente, ed è per questo che sopravvive per anni prima di causare un problema.

Un dump in cui le lettere si alternano a `00` — `54 00 65 00 73 00 74 00` — non è UTF-8 danneggiato: è UTF-16, dove ogni carattere del repertorio latino occupa due byte e il secondo è quasi sempre zero.

È la codifica interna di Windows e di parecchie API, quindi si incontra in export di database, in file di registro e in stringhe estratte da eseguibili. Riconoscerla è tutto, perché un decodificatore UTF-8 su quei byte produce un carattere valido alternato a un carattere nullo, cioè un testo che sembra a metà corretto — la forma di guasto che manda a cercare nel posto sbagliato più a lungo di un errore netto.

Quando i byte non formano UTF-8 valido, si potrebbe provare a leggerli come Latin-1: in quella codifica ogni byte è un carattere, quindi qualcosa esce sempre. Ed è precisamente il motivo per cui qui non si fa.

Un risultato che esce sempre non distingue mai fra un testo in un’altra codifica e un file binario: entrambi diventano una fila di caratteri plausibili, e chi legge non ha modo di sapere se quello che vede è il contenuto o un artefatto. Dire «questi byte non sono UTF-8 valido» è un’informazione; consegnare una lettura arbitraria è la sua assenza travestita da risposta.

Un caso ricorrente è un valore esadecimale che si vuole decodificare e che non è affatto testo codificato: un hash, un’impronta di certificato, una chiave. Sono byte casuali per costruzione, quindi il risultato non sarà mai leggibile.

Il conteggio è la scorciatoia. Sedici byte sono un MD5, venti uno SHA-1, trentadue uno SHA-256; se il tuo dump ha una di quelle lunghezze, non c’è nessun testo dietro e la domanda giusta è un’altra — che cosa produce quell’hash, non che cosa dice. Le pagine sugli hash di questo sito partono da lì.

Non c’è nessuna vista a colonne in stile editor esadecimale, con offset a sinistra e ASCII a destra. Sarebbe utile su un file e non su quello che si incolla in un campo di testo, e riprodurla male è peggio che non averla: la colonna ASCII di un editor vero ha regole precise su cosa mostrare al posto di un byte non stampabile.

Non c’è nemmeno un tentativo di riconoscimento del formato oltre a dire che i byte non sono testo. Indovinare un tipo di file dai primi byte funziona nella maggior parte dei casi e sbaglia in silenzio negli altri, ed è il genere di comodità che fa fidare di una risposta che non è mai stata verificata.

Un dump esadecimale arriva quasi sempre da qualcosa che sta andando storto: una cattura di rete, un campo di database che si comporta male, un messaggio d’errore con dentro un payload. Sono dati di produzione, con dentro quello che c’era nei dati di produzione.

La conversione avviene nella scheda, quindi quei byte non arrivano a noi e non compaiono in nessun log. È l’unica versione che regga quando il dump viene da un ambiente in cui una politica interna vieta di incollare i dati altrove — e in quel caso la verifica è il pannello di rete, non una frase su una pagina.