Che cos’è un file TXT?

TXT è un formato di testo semplice che si apre in qualsiasi editor. Si usa per spostare dati fra programmi e l'archiviazione.

L’estensione è .txt e il nome per esteso è Plain Text. Contano entrambi meno di ciò che il file può contenere, ed è di questo che parla il resto della pagina.

Risale al 1963. La specifica è Unicode.

A un formato rimasto leggibile così a lungo si può affidare qualcosa che vuoi ritrovare fra dieci anni.

È pubblicata per intero, quindi la si può implementare partendo dal documento invece che per osservazione: è per questo che il formato compare in così tanti programmi, ed è per questo che file scritti vent’anni fa si aprono ancora. Una specifica pubblicata però non è la stessa cosa di una esente da royalty: dove un formato incapsula un codec, le licenze sui brevetti restano una questione a parte che lo standard non risolve.

TXT conserva il suo contenuto esattamente. Risalvarlo non cambia nulla, quindi puoi aprirlo, modificarlo e risalvarlo quante volte vuoi senza accumulare danni: è questo che ne fa un formato di lavoro e non di consegna.

Notepad, TextEdit e Visual Studio Code lo leggono, e così fanno quasi tutti i programmi dello stesso tipo.

Quando un file non si apre, il formato è raramente il problema: più spesso è il programma a essere più vecchio di lui. Convertire in qualcosa di più vecchio è la via d’uscita affidabile, ed è a questo che serve il resto di questo sito.

Qualsiasi browser attuale lo legge.

Puoi quindi metterlo su una pagina o allegarlo a un messaggio senza chiederti che cosa abbia installato chi lo riceve.

TXT è pensato per essere aperto e modificato. Tieni il file in questo formato per tutto il tempo in cui il lavoro va avanti, ed esporta da lì ogni volta che serve una copia finita.

Un file TXT è una successione di caratteri. Non ha intestazione, né struttura, né stili, né metadati, né versione: nulla che possa diventare obsoleto e nulla che richieda un programma specifico per essere interpretato. Questa è tutta la specifica, ed è per questo che un testo scritto nel 1970 si apre oggi con qualsiasi cosa e si aprirà fra cinquant’anni con qualunque cosa ci sarà allora.

Tutto il resto su questo sito è un formato in senso stretto: byte disposti perché un certo tipo di programma ricostruisca qualcosa. Il testo semplice non chiede nulla. È il terreno su cui si costruiscono gli altri, ed è per questo che HTML, CSV, JSON, Markdown, SRT e SVG sono, sotto la superficie, file di testo con convenzioni sopra.

I caratteri vengono salvati come numeri, e quale numero significhi quale carattere è la codifica. Oggi la risposta è UTF-8 ovunque, e ha la proprietà utile che un testo in inglese comune è identico byte per byte all’ASCII di cinquant’anni fa. In italiano no: le lettere accentate e gli apostrofi tipografici occupano due byte ciascuno e sono proprio ciò che si rovina.

I file vecchi non sono UTF-8 e nulla dentro il file lo dichiara. Un testo salvato su un Windows italiano di vent’anni fa è spesso in Windows-1252; in altre regioni può essere diverso. Apritelo presumendo UTF-8 e una parola accentata appare con due caratteri strani in mezzo, o con un rombo nero con dentro un punto interrogativo. I byte vanno bene: chi legge sta indovinando e indovina male. Qualsiasi editor decente permette di riaprire il file con un’altra codifica, e questo lo sistema all’istante senza digitare nulla.

Alcuni editor scrivono tre byte invisibili all’inizio di un file UTF-8 per dichiarare cosa sia. Su Windows è comune; in quasi tutto il resto è considerato un errore.

È invisibile per voi e chiarissimo per un programma. Un file di configurazione con quel segno non viene analizzato. Un CSV che lo porta ha una prima intestazione di colonna che non coincide con nulla. Uno script si rifiuta di eseguirsi con un messaggio poco utile. Se qualcosa rifiuta un file di testo senza motivo apparente, questa è la prima cosa da controllare: l’opzione si chiama «UTF-8 senza BOM».

Windows termina una riga con due caratteri, ritorno a capo e avanzamento riga. Tutto il resto ne usa uno solo, l’avanzamento riga. Entrambe le forme sono legittime e il file non annuncia quale usa.

I sintomi sono vecchi ma non spariti: un file di origine Unix aperto nel vecchio Blocco note come una singola riga enorme, o un file Windows che mostra un segno in più alla fine di ogni riga in uno strumento Unix. Gli editor attuali lo gestiscono in silenzio e sanno convertire. Dove morde ancora è nel controllo di versione, quando un intero file appare modificato perché l’editor di qualcuno ha riscritto tutti i fine riga, e negli script, dove un ritorno a capo di troppo si infila in un nome file e smette di funzionare tutto.

Nel durare. Se qualcosa deve poter essere letto fra trent’anni senza presumere nulla sul software disponibile, deve essere testo. Questo copre appunti, verbali, trascrizioni, configurazioni, dump di dati e tutto ciò che un archivista vi ringrazierà per aver conservato così.

E negli strumenti. Il testo si cerca, si filtra, si ordina, si confronta e si modifica con un numero enorme di programmi che non sanno nulla dei vostri dati. Una differenza fra due versioni è leggibile. Un sistema di controllo versione può unire le modifiche di due persone. Nulla di tutto ciò è possibile con un documento binario, ed è il motivo per cui tanto lavoro tecnico avviene in formati che sembrano primitivi accanto alle alternative.

I log e le esportazioni arrivano a diversi gigabyte, e la maggior parte degli editor cerca di caricare tutto in memoria. Un elaboratore di testi semplicemente si rifiuta; un editor generico può bloccare la macchina.

Gli strumenti che reggono leggono a blocchi: un editor di codice serio, un paginatore o le utility da riga di comando fatte apposta. Su qualsiasi sistema, guardare le prime e le ultime cinquanta righe risponde a quasi tutte le domande senza aprire nulla: sopra si vede cosa sia il file e sotto se il processo che lo ha scritto è arrivato a terminare.

La prima è un PDF. Si estrae lo strato di testo che il PDF già porta dentro, nel browser e senza caricare nulla: escono tutte le pagine, unite da una riga vuota. Ciò che non esce è l’impaginazione — non c’è rilevamento delle colonne né correzione dell’ordine di lettura, quindi un documento a due colonne esce nell’ordine in cui il file salvava il contenuto — né le tabelle, che restano senza separatori. E serve che ci sia uno strato di testo: una scansione restituisce un errore che lo spiega invece di un file vuoto.

La seconda è il riconoscimento ottico su un’immagine, anch’esso nel browser, con Tesseract e con i modelli ospitati qui invece che scaricati da terzi. Ci sono quattro lingue disponibili, l’italiano fra queste, e scegliere la lingua sbagliata non dà un errore ma un testo plausibile e falso. L’output è testo semplice senza alcuna pulizia: gli a capo e le righe vuote escono esattamente come li ha prodotti il riconoscitore. È di gran lunga il motore più lento del sito, e l’unico che può sbagliare con sicurezza invece di limitarsi a essere imperfetto.

Dal TXT esce solo una conversione, a PDF, e la esegue LibreOffice in un nostro contenitore. È quindi fra quelle che caricano il file: il testo viaggia verso api.quinvert.com, viene salvato con un nome neutro in una cartella temporanea che si cancella al termine e anche su ogni percorso di errore, e il contenitore non ha accesso a internet. Il tetto qui è di 25 MB per file, contro i 100 MB delle conversioni risolte nel browser.

Quanto al contenuto, passare testo in PDF è un cambio di contenitore e non di sostanza. Fissa l’aspetto, lo rende stampabile e produce qualcosa che si apre uguale per tutti; l’impaginazione viene composta con font sostitutivi di metrica compatibile. Il file di testo resta la versione modificabile, cercabile e confrontabile, ed è per questo che di solito conviene conservare entrambi.