Codificare in esadecimale

L’esadecimale ha sedici simboli, quindi ogni cifra copre quattro bit e due cifre coprono esattamente un byte. È una corrispondenza perfetta ed è tutta la ragione per cui questa notazione esiste: leggere un byte in binario richiede otto simboli, in decimale richiede un numero variabile, in esadecimale sempre due.

Un carattere invece non ha una lunghezza fissa. In UTF-8 le lettere dell’alfabeto inglese occupano un byte, le accentate due, la maggior parte dei simboli tre, gli emoji quattro. Contare i byte di un dump e credere di aver contato i caratteri è l’errore che porta a troncare una stringa in mezzo a una lettera.

Perché è quello che c’è. Il web è UTF-8 per specifica, i file di testo prodotti dagli strumenti moderni sono UTF-8, e un dump prodotto in un’altra codifica va interpretato conoscendo quale, cosa che nessuna stringa dichiara di per sé.

Il caso che ancora capita in Italia è Latin-1, cioè ISO 8859-1, ereditato da vecchi database e da qualche export contabile: lì una `à` è un byte solo, `e0`. Se il tuo dump ha `e0` dove ti aspetti una lettera accentata, non è UTF-8, e quella è già la diagnosi: la stringa viene da un sistema che non è mai stato convertito.

Ogni ambiente ha la sua convenzione, e sono tutte in uso contemporaneamente. Gli spazi sono la forma dei dump prodotti dagli editor esadecimali; i due punti sono la forma delle impronte di certificato e degli indirizzi MAC; nessun separatore è la forma di un campo di database, di un hash o di un letterale in un file sorgente; le virgole servono per incollare in un array.

La scelta non cambia i dati e cambia se l’altra parte li accetta. Vale la pena sceglierla guardando dove il valore andrà a finire, perché convertire un dump da una forma all’altra a mano è il tipo di lavoro noioso in cui si perde un byte senza accorgersene.

`c3` e `C3` sono lo stesso byte, quindi la scelta è puramente di scrittura. Le minuscole sono la convenzione degli strumenti Unix e della maggior parte dei formati moderni; le maiuscole compaiono nelle impronte dei certificati e in parecchi strumenti Windows.

Diventa una differenza vera in un posto solo: il confronto testuale. Due sistemi che scrivono lo stesso hash in due casi diversi producono un mancato riscontro, ed è un difetto che si presenta come «i dati non corrispondono» invece che come «la scrittura è diversa». Un confronto fra valori esadecimali va fatto senza distinzione di caso, sempre.

È l’uso più utile di questa pagina. Due stringhe che sullo schermo sono identiche e che un confronto dichiara diverse contengono quasi sempre qualcosa che non si vede, e in esadecimale quel qualcosa diventa evidente.

I sospettati abituali sono tre. `c2 a0` è lo spazio unificatore, che arriva da un copia-incolla da una pagina web o da un documento di videoscrittura. `ef bb bf` all’inizio è il BOM, lasciato da un editor Windows. E `e2 80 99` è l’apostrofo tipografico, quello che Word e i telefoni producono al posto di quello dritto: è tre byte invece di uno, e in italiano compare praticamente in ogni frase, il che lo rende la causa numero uno delle stringhe che sembrano uguali e non lo sono.

Un ritorno a capo è `0a` su Linux e su macOS, e `0d 0a` su Windows. Non si vedono in nessun editor, e sono la spiegazione più frequente di due file che dovrebbero essere identici e hanno hash diversi.

La differenza si accumula: su un file di mille righe sono mille byte. È anche il motivo per cui Git ha un’opzione di conversione automatica dei fine riga, e per cui quell’opzione crea problemi propri quando è impostata in modo diverso su due macchine dello stesso progetto. Vedere `0d 0a` in un dump è la conferma che serve prima di andare a cercare altrove.

L’esadecimale è fatto per essere letto: due cifre per byte, corrispondenza diretta, si può contare con un dito sullo schermo. Il prezzo è la dimensione, perché occupa il doppio dell’originale.

Il Base64 è fatto per essere trasportato: occupa un terzo in più invece del doppio, e in cambio è illeggibile — non c’è nessun modo di guardare una stringa Base64 e dire quale byte sta in quinta posizione. La regola pratica segue da qui: esadecimale quando devi guardare i byte, Base64 quando devi spedirli.

Il prefisso `0x` è una convenzione dei linguaggi di programmazione per dire che il numero che segue è in base sedici, e riguarda un numero singolo: `0x41` è il numero 65. Non è parte della notazione dei byte.

Per questo un dump non si scrive con `0x` davanti a ogni byte, ed è un errore comune quando si copia un valore da un debugger. Il prefisso serve dove c’è un valore solo — un colore, una maschera di bit, un punto di codice — e in un dump di trenta byte produce sessanta caratteri di rumore. Questa pagina non lo aggiunge; la pagina di decodifica lo accetta lo stesso, perché con i dump copiati da un debugger capita.

Quello che si porta a un codificatore esadecimale è spesso un valore che sta dando problemi: una stringa presa da un database, il nome di un cliente con un carattere strano dentro, una chiave che non corrisponde. Sono dati reali, guardati proprio perché qualcosa non torna.

La conversione è aritmetica su ogni byte e avviene nella scheda: non parte nessuna richiesta e nel senso del GDPR non c’è nessuna comunicazione da giustificare. È anche il motivo per cui la pagina funziona su una macchina scollegata dalla rete, che è esattamente la situazione in cui si guardano i byte di qualcosa.