Lezione di storia: Che cos’è un file .txt? Perché i vecchi testi mostrano caratteri strani

Che cos’è un file .txt?

Apri un .txt in qualsiasi editor e vedi solo caratteri: lettere, cifre, punteggiatura, spazi e interruzioni di riga. Il formato è tutto qui. Non c’è intestazione, né font, né grassetto o corsivo, né dimensione della pagina, né traccia della lingua del testo. Ciò che il file contiene davvero è una sequenza di byte (numeri da 0 a 255), e il programma che lo apre deve decidere a quale carattere corrisponda ogni numero. L’estensione “.txt” dice a Windows soltanto quale programma proporre; non dice nulla su come leggere i byte. Per questo il testo semplice è uno dei formati più portabili mai creati, e anche uno dei più facili da leggere male.

Perché il mio file .txt mostra caratteri strani?

Perché il programma che legge il file usa una codifica dei caratteri diversa da quella del programma che lo ha scritto. La stessa lettera può essere memorizzata come byte diversi: é è il singolo byte E9 in Windows-1252, la code page che Microsoft descrive come quella abituale per l’inglese e altre lingue dell’Europa occidentale, ma i due byte C3 A9 in UTF-8. Se apri un file UTF-8 come Windows-1252, ogni é diventa é. L’apostrofo tipografico ’ (E2 80 99 in UTF-8) diventa ’. Un file UTF-8 che inizia con un byte order mark (BOM, spiegato più avanti) comincia con . Nel senso opposto, aprendo come UTF-8 un file Windows-1252, il byte E9 isolato non è UTF-8 valido e il programma mostra il carattere sostitutivo �.

I file dell’era DOS sbagliano in un altro modo. Sull’IBM PC originale lo stesso byte poteva essere ancora un altro carattere: nella code page 437, il set di caratteri del DOS, il byte 82 è é e i cinque byte C9 CD CD CD BB disegnano il bordo superiore di un riquadro (╔═══╗). Windows li legge come code page 1252 e mostra ‚ e ÉÍÍÍ», così la parola café diventa caf‚ e il riquadro del banner di un README si trasforma in lettere.

Nessun programma può sempre indovinare da solo. Nel 2007 Raymond Chen di Microsoft mostrò il dilemma del Blocco note con un file di due byte, D0 AE. Letto come Windows-1252 sono i caratteri Ю; letto come UTF-8 è la lettera cirillica Ю; letto come UTF-16 (due byte per carattere) è una singola sillaba dell’hangul coreano, diversa a seconda dell’ordine dei byte. Chen faceva notare che tutte e quattro le letture sono plausibili. Senza un’etichetta nel file, “strano” è semplicemente l’aspetto di un’ipotesi sbagliata.

1963: l’ASCII dà un numero a 128 caratteri

Perché il testo semplice potesse diventare un file, servivano numeri per i caratteri su cui macchine diverse fossero d’accordo. L’American Standards Association istituì nell’agosto 1960 un sottocomitato per i set di caratteri codificati e il 17 giugno 1963 approvò la norma X3.4-1963, l’American Standard Code for Information Interchange: l’ASCII. Era un codice a 7 bit con 128 valori per caratteri di controllo, cifre, punteggiatura e alfabeto inglese. L’edizione del 1963 era consapevolmente incompleta, con buona parte della tabella ancora da assegnare. Un avviso del 1967 sulla revisione approvata il 7 luglio 1967, X3.4-1967, diceva che la maggior parte dei partecipanti al progetto ASCII la considerava il primo vero completamento del codice di base a 7 bit.

Sette bit non stanno bene in un byte. Uno dei primi documenti a dire cosa fare è la RFC 20, scritta da Vint Cerf nell’ottobre 1969 per la prima ARPANET, la rete di ricerca che precedette Internet. Proponeva “ASCII standard a 7 bit inserito in un byte di 8 bit il cui bit più significativo è sempre 0”. È in quell’ottavo bit inutilizzato che iniziano i guai: quando un byte può contenere 256 valori, gli altri 128 restano liberi per chiunque voglia assegnarli.

CR, LF o entrambi: come finisce una riga

L’ASCII codificò anche la meccanica della telescrivente. Come spiega Chen, il ritorno a capo (CR) riportava la testina di stampa alla colonna 0 senza far avanzare la carta, e l’avanzamento di riga (LF) faceva avanzare la carta di una riga senza muovere la testina, perciò per iniziare una nuova riga servivano entrambi. L’edizione 1968 dell’ASCII, riprodotta nella RFC 20, lascia che LF significhi “Nuova riga”, ma aggiunge che usarlo “richiede un accordo tra mittente e destinatario dei dati”. Quell’accordo non è mai arrivato del tutto. La stessa RFC 20 registra che i primi siti ARPANET non erano d’accordo: SRI usava un punto come carattere di fine riga, mentre UCLA usava il ritorno a capo.

CP/M, MS-DOS e Windows mantennero entrambi i caratteri, CRLF (i byte 0D 0A). Unix si accontentò di un solo LF (0A). L’annuncio di Microsoft del 2018 sul nuovo comportamento del Blocco note elenca le tre convenzioni che ora gestisce: fine riga Unix/Linux (LF), Macintosh (CR) e Windows (CRLF). Fino ad allora, diceva, il Blocco note mostrava correttamente solo le fine riga di Windows, quindi un file di testo creato su Unix o Linux appariva confuso. La correzione arrivò nelle build Insider di Windows 10 nel maggio 2018.

1981: gli altri 128 valori vanno ciascuno per la sua strada

L’IBM PC arrivò nel 1981 con byte a 8 bit e uno standard a 7 bit. David Bradley, uno dei suoi ingegneri, ricordò in seguito che il PC “usava il set di caratteri ASCII, un cambiamento radicale per un prodotto IBM” (i prodotti IBM precedenti usavano l’EBCDIC) e che, con 128 nuovi posti da riempire, il team li aveva riempiti con lettere di lingue straniere, grafica a blocchi e simboli matematici e greci. Disse che gli piaceva descrivere il set di caratteri come sviluppato in “una riunione di tre persone di quattro ore”. Il risultato è la code page 437, che Microsoft chiama la code page OEM (DOS) abituale per l’inglese: la sua metà superiore contiene lettere accentate, caratteri per tracciare linee e simboli.

Poi Windows costruì le proprie code page. La documentazione di Microsoft dice che la code page 1252 di Windows si basava in origine su una bozza dell’American National Standards Institute (ANSI) che divenne poi ISO 8859-1, ma fu implementata prima che lo standard fosse definitivo e non è identica. Le code page di Windows sono ancora comunemente chiamate “code page ANSI”, anche se sono di Microsoft. Tutte concordano con l’ASCII per i valori da 0 a 127 e divergono oltre: il byte E9 è é nella code page 1252, й nella code page cirillica 1251 e ι in quella greca 1253. Giapponese e cinese usavano code page a doppio byte, in cui alcuni byte hanno significato solo insieme al byte successivo. Microsoft osserva che nessuna singola code page copre tutto ciò che copre Unicode.

1992: Unicode e un sottobicchiere in un diner del New Jersey

Unicode scelse l’approccio opposto: un numero per ogni carattere, senza più destreggiarsi tra code page. Nella prima versione, dal 1991 al 1995, era una codifica a 16 bit; da Unicode 2.0, nel luglio 1996, copre l’intervallo da U+0000 a U+10FFFF. Ma un numero non è un file. Memorizzare direttamente valori a 16 bit nei file si scontrava con il software Unix dell’epoca, che si basava su byte ASCII come il byte nullo e la barra, e nel 1992 un comitato di X/Open stava valutando un modo adatto a Unix per memorizzare Unicode.

Rob Pike, allora ai Bell Labs, scrisse nel 2003 che UTF-8 “fu ideato, sotto i miei occhi, su un sottobicchiere in un diner del New Jersey una sera di settembre o giù di lì del 1992”. Alcuni membri del comitato avevano chiesto a lui e a Ken Thompson di esaminare la loro proposta. I due andarono a cena, Thompson mise a punto l’impacchettamento dei bit e poi telefonarono al comitato. Pike racconta che Thompson scrisse quella notte il codice di impacchettamento e spacchettamento e che entro venerdì il loro sistema operativo, Plan 9, funzionava solo con quello che sarebbe stato chiamato UTF-8. Archivi di posta recuperati dal collega Russ Cox collocano la proposta all’inizio di settembre 1992.

UTF-8 memorizza ogni carattere in uno-quattro byte. I 128 caratteri ASCII mantengono il loro valore a byte singolo e nessun byte di altri caratteri assomiglia all’ASCII, quindi un file ASCII puro è già UTF-8 valido. Tutto il resto occupa da due a quattro byte, con bit iniziali che indicano al lettore la lunghezza della sequenza: é diventa C3 A9. La RFC 3629 di François Yergeau (novembre 2003) ne fece uno standard di Internet, e le FAQ di Unicode lo chiamano “la forma preferita per i file di testo Unicode”.

Il BOM, e perché il Blocco note doveva indovinare

UTF-16 memorizza i caratteri in unità da 16 bit, quindi il lettore deve conoscere anche l’ordine dei byte. La risposta di Unicode è un carattere, U+FEFF, posto proprio all’inizio del file come firma: il byte order mark. In UTF-8 compare come i byte EF BB BF, e le FAQ di Unicode sono esplicite: lì non ha nulla a che fare con l’ordine dei byte, indica solo che il file è UTF-8. Aggiungono che alcuni programmi non lo prevedono (la prima riga di uno script shell Unix, che inizia con #!, ne è un esempio) e che un protocollo come le “convenzioni Microsoft per i file .txt” può richiederlo. Un .txt può quindi iniziare con un BOM oppure no, e quando non c’è, il programma deve indovinare.

Il post di Chen del 2007 sul “problema della codifica dei file del Blocco note” spiega perché indovinare non finisce mai bene. I file con BOM sono facili. Senza BOM, la maggior parte dei file di testo in circolazione era ANSI a 8 bit, anche alcuni file UTF-8 e UTF-16 erano senza BOM, e ogni regola che provava favoriva un gruppo e ne danneggiava un altro. Il suo esempio: il comando cmd /u /c dir >results.txt scrive un file UTF-16 senza BOM.

Microsoft cambiò il Blocco note in due passi. Nel 2018 imparò le fine riga Unix e Mac. Poi, nella build Insider 18298 di Windows 10 del 10 dicembre 2018, Microsoft aggiunse l’opzione di salvare in UTF-8 senza BOM, la rese predefinita per i nuovi file e mise la codifica nella barra di stato, spiegando che UTF-8 senza BOM è retrocompatibile con l’ASCII e funziona meglio con il Web, “dove UTF-8 è diventato la codifica predefinita”. La modifica raggiunse tutti con Windows 10 versione 1903, l’aggiornamento di maggio 2019. Prima, un nuovo file del Blocco note usava per impostazione predefinita ANSI.

2007 e dopo: UTF-8 conquista il Web

Google riferì che nel dicembre 2007 Unicode divenne per la prima volta la codifica più frequente nelle pagine web da esso indicizzate, superando ASCII e le codifiche dell’Europa occidentale a distanza di dieci giorni l’una dall’altra. W3Techs riporta oggi UTF-8 sul 99,1% dei siti web di cui riesce a identificare la codifica (novembre 2026). È una statistica sui siti web. I file di testo rimasti su vecchi dischi non hanno mai fatto parte di quel passaggio, e nessuno è tornato a ricodificarli.

Perché i .txt dei vecchi dischi sembrano ancora illeggibili nel 2026

Il software di oggi presume UTF-8, ma molto testo fu scritto prima: README del DOS, primi appunti di Windows, esportazioni di programmi che non girano più, e-mail o registri salvati come testo. Sono nella code page del PC che li ha prodotti, che dipendeva dalla sua lingua e dalla versione di Windows, e non portano alcuna etichetta. Aggiungi fine riga di un altro sistema e ogni tanto un file UTF-16 senza BOM, e la stessa estensione .txt nasconde più formati senza relazione tra loro. Molti sono file legacy su cui nessuno può più interrogare il programma originale.

Legacy File Converter elenca il testo semplice (.txt) tra i documenti nella pagina Tipi di file supportati e li converte sul tuo PC Windows in formati moderni come DOCX, PDF, Markdown o HTML; non viene caricato nulla. Poi confronta lettere accentate, virgolette e simboli con l’originale e conserva il file originale. Per altri formati che sotto sono soprattutto testo, vedi la Lezione di storia: Che cos’è un file .csv?, dove un BOM mancante fa inciampare Excel, e la Lezione di storia: Che cos’è un file .rtf?.