Man mano che l’informatica passava dai pochi centri di ricerca elitari ad applicazioni commerciali sempre più vaste, il problema dell’interoperabilità assumeva una connotazione via via più importante, tanto che negli ultimi tempi è divenuto un tema molto dibattuto e sentito, che ha portato alla definizione e accettazione di nuovi standard a garanzia dell’interscambiabilità dei dati.
Ciò non deve indurci a pensare che il problema dello scambio delle informazioni sia stato posto soltanto di recente, e che le soluzioni siano altrettanto “giovani”. Infatti già nei primi anni ’60 fu ratificato uno standard, divenuto poi rapidamente il punto di riferimento per la codifica delle informazioni di tipo testuale, che fa capo all’arcinoto ASCII…
I file di testo furono una delle prime strutture dati ideate per immagazinare particolari tipi di informazioni piuttosto comuni, che prevedevano che i dati fossero distribuiti in un elenco ordinato di righe costituite da caratteri.
Lo standard ASCII nacque per specificare in maniera chiara l’associazione fra un determinato simbolo (o carattere) e la sua precisa codifica (numerica), per un totale di 128 elementi (anche se il mio primo professore di informatica dell’ITIS, nonostante le mie rimostranze, ribadiva che fossero 256). Gli elementi a sua volta si dividono in due grandi categorie: quelli stampabili e di controllo.
I primi li troviamo normalmente visualizzati: lettere, cifre numeriche, punteggiatura, ecc. I secondi sono utilizzati per implementare delle funzionalità “speciali”, come il fine riga, di pagina, dell’intero documento, o per controllare la trasmissione dei dati (utilizzati in particolari protocolli), ecc., e non sono “visualizzabili” (alla loro posizione non corrisponde un simbolo grafico a video o in stampa).
Una soluzione, questa, semplice ed elegante che ha fatto la fortuna di questo standard, rendendolo per tantissimo tempo quello più utilizzato e contribuendo a diffondere il concetto di file di testo codificato in ASCII quale veicolo preferenziale per i documenti testuali.
Eppure, nonostante le ottime premesse e l’ampio uso, ancora oggi ci ritroviamo in difficoltà nel manipolare qualunque file di testo ASCII, a causa delle scelte autonomamente effettuate per quanto riguarda il concetto di identificatore di “fine riga”. Ciò comporta sostanzialmente due problemi: quello del significato attribuitogli, e quello della codifica adottata per indicarlo.
Il primo riguarda la possibilità di definire tale elemento in qualità di separatore di una riga dalla successiva, oppure di terminatore di riga. Nel primo caso, l’ultima riga non avrà appesa alla fine la codifica di “fine riga”. Nel secondo caso sarà in dotazione a tutte le righe.
Ci saranno, quindi, sistemi che per manipolare file di testo pretendono che ogni riga sia accompagnata dal suo terminatore, e altri che, invece, lo usano soltanto se è necessario (se sono presenti due righe da separare) e per i quali, anzi, la presenza della codifica di fine riga al termine del documento testuale comporta la creazione e, quindi, la presenza di un’ultima riga vuota.
Già quest’esempio ci mostra quali inconvenienti sorgono per i file di testo, ma ben peggiore è lo stato in cui si è arrivati col secondo caso, cioé con la codifica dell’identificatore di fine riga, che a oggi presenta ben tre soluzioni adottate: LF, CR, oppure CR e a seguire LF (quindi due caratteri / elementi, contro l’unico delle altre due codifiche).
E’ difficile risalire alle reali cause che portarono a una scelta piuttosto che a un’altra, ma penso che siano da attribuire più che altro al pragmatismo del momento, cioé ai problemi che all’epoca si volevano o dovevano risolvere.
Infatti per le stampanti fu ovvia l’adozione dell’accoppiata CR + LF, poiché il primo comportava il ritorno della testina di stampa all’inizio della riga (la prima colonna), mentre il secondo l’avanzamento alla riga successiva. In questo modo la stampante si ritrovava pronta a stampare all’inizio della seguente riga.
Furono i s.o. a far sprofondare nel caos la situazione. Alcuni, come Unix e AmigaOS, adottarono il solo LF; altri, come i Pet di Commodore e MacOS, il solo CR; altri ancora, come CP/M ed MS-DOS, l’accoppiata CR + LR.
Il risultato fu che, a parte gli scontati problemi di interscambio dei file di testo, mandando in stampa così com’era un documento editato su un sistema Unix, si assisteva a una sorta di “dente di sega“, col testo che veniva continuamente spostato a destra producendo originali sezioni triangolari. Un documento del Mac, invece, produceva una singola riga quasi del tutto nera a causa della continua sovrapposizione dei caratteri. Col DOS, invece, nessun problema.
L’uso del singolo carattere è certamente molto comodo per chi sviluppa sistemi operativi e linguaggi di programmazione, avendo la non trascurabile proprietà di rendere perfettamente equivalenti file di testo e binari. Viceversa, chi adotta i due caratteri rende la gestione dei file di testo più complicata e, soprattutto, richiede espressamente una gestione separata dei due tipi di file.
La creazione di uno standard in teoria dovrebbe servire proprio a evitare casi come questi, ma in realtà la non perfetta chiarezza ha causato tutti questi problemi che ancora oggi ci trasciniamo.
Ciò non è esattamente vero, poiché lo standard è stato portato avanti da una commissione di un’agenzia, l’ASA (che sarebbe poi stata chiamata ANSI), e che sarebbe poi dovuto esser ratificato anche da un’altra agenzia, la ISO.
ASA emanò come direttiva l’uso di CR + LF per segnalare la fine di una riga, mentre ISO successivamente ratificò anche l’uso di LF (probabilmente per far rientrare anche i sistemi Multics e il successore Unix, che era già diffusi e per i quali gli sviluppatori avevano deciso di adottare motu proprio soltanto LF).
Un pastrocchio, insomma, anche se i sistemi più diffusi rimangono fedeli all’originale direttiva ASCII, che è stata anche adottata dai protocolli ratificati per le informazioni che si scambiano su internet, rete nata per favorirne l’interscambiabilità e dove si spera che, memori di questi errori, tutti si adeguino seguendo rigidamente gli standard ratificati.
