Tra il mondo Unix e il mondo Windows esistono molte barriere che complicano l’interscambio di dati: una di questa barriere è la codifica del carattere di “a capo”.
Nell’epoca del Cloud, della Blockchain e dell’Intelligenza Artificiale sembra assurdo doversi confrontare con problemi come questo, ma succede.
Il carattere di “a capo”, come quello che fa suonare un campanello o il carattere di “spazio”, sono semplicemente caratteri come tutti gli altri, ognuno con la propria codifica. Quando pensiamo ad un file di testo – come ad un video o ad un audio – dovremmo sempre pensarlo come uno stream ininterrotto di bit tutti in fila. In binario non esistono “a capo” ma è solo una nostra rappresentazione perché siamo abitutati a fogli non infiniti. In realtà sarebbe meglio pensare ad un nastro infinito come quello della macchina di Turing.
Nella codifica ASCII (American Standard Code for Information Interchange), che è una delle codifiche più vecchie da cui si sono evolute quelle moderne fino all’onnicomprensivo UTF-16, il carattere di “a capo” o “nuova linea” è codificato con il numero decimale 10, in esadecimale A, in ottale 0x12, in binario a 8 bit 00001100. Il suo simbolo è LF (Line-Feed) e spesso viene visualizzato negli editor di testo con ^M e viene codificato con la sequenza \n nell’ambito delle espressioni regolari.
Per indicare il carattere corrispondente ad un codice x useremo questa notazione: CHR(x)
Sennonché Microsoft ha codificato in modo custom il carattere di a capo come l’unione di due caratteri: nei file prodotti con Windows troveremo che il carattere di a capo è CR + LF (Carriage-Return + Line-Feed), quindi CHR(10) + CHR(12) . Per Linux/Unix e MacOSX (che è un fork di Unix) è semplicemente LF.
Carriage Return sarebbe il movimento di ritorno all’inizio della riga, ma (soprattutto per chi ricorda le macchine per scrivere come la Olivetti Lettera 22) c’è anche l’avanzamento di una riga del foglio dovuto idealmente alla rotazione del rullo che trasporta la carta, che è proprio il Line Feed. Tutte cose che ormai si sono perse nella nebbia.
Il carattere di CR nella tabella ASCII è identificato con il codice 14 = Hex D = 0x14 = 00001110.
Negli editor vediamo sempre prima il carattere ^M e poi la linea va a capo, quindi la sequenza in cui si succedono i caratteri è CR + LF.
Quando importiamo in Linux un file di testo puro proveniente da Windows (a proposito: non sto parlando di cose antiquate e sorpassate: nella scrittura di software utilizzare file di testo puro è la regola perché i sorgenti sono e rimangono scritti così), vedremo alla fine di ogni riga il carattere ^M e poi il resto a capo.
Di solito gli editor possono anche avere l’opzione di ignorare e non mostrare i caratteri di CR (^M) per cui aprendo il file non vediamo niente di strano.
Ma è possibile visualizzarli con questi comandi per esempio:
$ cat -v testo.txt ciao,^M come va?
Per rimuovere i caratteri di CR ci sono molti modi, ad esempio utilizzando sed (Stream EDitor, potentissimo) oppure più semplicemente questo:
$ dos2unix testo.txt $ cat -v testo.txt ciao, come va?
Poi c’è anche da dire che utility come FTP operano automaticamente la conversione quando si trasferiscono file tra sistemi eterogenei per cui di solito non ci preoccupiamo di questo aspetto. Di solito.
Commenti recenti