di  -  giovedì 27 agosto 2009

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.

14 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    LF, CR o CR + LF: qual è lo “standard” per i file di testo? | succoso
     scrive: 

    […] LF, CR o CR + LF: qual è lo “standard” per i file di testo? […]

  • # 2
    Fabio
     scrive: 

    Un paio di anni fa, quando stavo facendo la tesi, sono IMPAZZITO perché uno script in Linux non mi andava, diceva che c’era un errore in fondo alla prima riga, quando ero sicurissimo che fosse corretto (era un ciclo FOR, nulla di trascendentale). E alla fine ho capito che era dovuto al fatto che il file era stato creato con un editor per Windows e quindi conteneva i caratteri CR/LF, e per Linux il carattere CR era un errore di sintassi e si inchiodava tutto.

    Secondo me, in questi casi bisognerebbe adottare il principio di seguire strettamente le specifiche nelle cose che si fanno ma essere molto più tolleranti in ciò che proviene dall’esterno. In altre parole: Linux vuole solo LF? Ok, i file creati da Linux hanno solo LF; d’altra parte, se mi ritrovo un file con CR oppure CR/LF, faccio finta di niente e lo accetto lo stesso.

    Oppure nel dare il messaggio d’errore spiego chiaramente che il carattere extra è un CR e che la soluzione consiste nel prendere un editor di testi serio e convertire il formato del file in Linux.

    Mi avrebbe risparmiato ore di disperazione…

  • # 3
    Giacomo
     scrive: 

    Hehe, ricordo ancora i programmini su Aminet per le conversioni testo da MS-DOS ad Amiga e viceversa..

  • # 4
    D
     scrive: 

    “Secondo me, in questi casi bisognerebbe adottare il principio di seguire strettamente le specifiche nelle cose che si fanno ma essere molto più tolleranti in ciò che proviene dall’esterno.”

    Sarebbe stato più logico invece seguire la direttiva originaria.
    La commissione ASCII non era lì a discutere di porcini e l’ISO non aveva alcun diritto di cambiare le carte in tavola.

    I “geni” di unix e co. avevano deciso motu proprio ?
    Una bastonata secca sulle dita e di corsa ad adattarsi invece di fare i bastian contrari che la storia recente c’ha mostrato chiaramente cos’ha portato questa mania del voler fare sempre di testa propria fregandosene di standard e direttive vari.
    Se perfino davanti ad una banalità così sono riusciti ad andare fuori dalle righe, non mi stupisco di molte evoluzioni successive.

  • # 5
    Fabio
     scrive: 

    “Sarebbe stato più logico invece seguire la direttiva originaria.”

    Ah, beh, su quello sono d’accordissimo! :-) Quello che intendevo dire è: una volta fatta la “scissione”, bisognava fare in modo di renderla meno dolorosa possibile. Così invece non è stato…

  • # 6
    pvs
     scrive: 

    scusa, ma non ho capito il senso di questa frase:
    “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.”

    potresti approfondire, in particolare, la seconda parte?

  • # 7
    CereS
     scrive: 

    @pvs:

    Ti faccio un esempio semplicissimo.
    Prendi la prima pagina della divina commedia e la scrivi su un editor di testo, diciamo notepad su Windows e gedit su Linux.
    Anche se il testo è esattamente lo stesso i due file, una volta salvati, saranno di dimensioni diverse, nella fattispecie il file salvato con Windows sarà più grande di X byte (dove X è il numero delle righe del testo)
    Non solo, poniamo di salvare lo stesso file anche con Mac (mi sfugge il nome dell’editor predefinito) è si vero che la dimensione sarà la stessa identica del file salvato su linux ma il contenuto binario no poiché i ritorni di riga saranno codificati con LF su uno e CR sull’altro.
    Creando l’md5 per ogni file si otterranno 3 risultati completamente diversi anche se, in realtà, il contenuto visibile all’occhio umano è esattamente lo stesso.

  • # 8
    diggita.it
     scrive: 

    LF, CR o CR + LF: qual è lo “standard” per i file di testo?…

    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 …

  • # 9
    Flare
     scrive: 

    «lo standard è stato portato avanti da una commissione di un’agenzia che sarebbe poi stata chiamata ASCII, e che sarebbe poi dovuto esser ratificato anche da un’altra agenzia, la ISO.»

    Penso che qua tu ti sia confuso (forse per la somiglianza): ASCII non è il nome di un’agenzia. L’American Standard Code for Information Interchange (ASCII) è stato sviluppato da una sottocommissione dell’American Standards Association (ASA), l’attuale American National Standards Institute (ANSI).

    Rispondendo agli altri: l’ISO non è solo America, ISO = International Organization for Standardization (e ha sede in Svizzera). Ha tutto il diritto di mettere d’accordo le varie organizzazioni nazionali, piuttosto che imporre quello di una. Ricordo che ASCII, come dice anche l’acronimo, inizialmente era stato pensato come uno dei tanti standard nazionali.

    I lavori sull’ASCII sono durati diversi anni a partire dal 1963. Commodore si basava sulla prima versione.

    Multics è degli anni ’60. Quelli che lo svilupparono prendendo decisioni “motu proprio” erano (rullo di tamburi) quelli del MIT, General Electrics e Bell Labs. Multics fu pieno di cose geniali, senza virgolette, e idee innovative. Non so perché optarono per il solo LF, ma negli anni ’60 risparmiare un byte per linea non era poco e comunque l’ISO era d’accordo. Di sicuro non lo fecero tanto per fare i bastian contrari.

    Il CR+LF in MS-DOS degli anni ’80 (poi in Windows) era semplicemente una delle tante cose che aveva preso da CP/M.

  • # 10
    Cesare Di Mauro
     scrive: 

    @pvs: è una questione che riguarda prettamente la programmazione. In Unix aprire un file binario o testuale è la stessa cosa e vengono gestiti allo stesso modo.

    In Windows no: devi specificare all’apertura quale tipo di file vuoi aprire per poter gestire correttamente i fine riga.

    Questo perché il carattere di escape utilizzato, ‘\n’, assume un valore diverso a seconda del tipo di codifica scelta per il fine riga dal sistema.
    E’ un singolo carattere nei sistemi Unix. Viene convertito in una coppia di caratteri internamente quando si lavora su file di testo nei sistemi Windows.

    @Flare: per quanto riguarda il nome dell’agenzia hai ragione, fu poi chiamata ANSI. Correggo subito (la memoria a volte fa brutti scherzi di associazione di informazioni diverse).

    Per quanto riguarda ISO e ASCII, questi due sono standard diversi. ISO ha ratificato l’esistente standard ASCII, apportando dei cambiamenti.

    Quindi se si cita ASCII si parla di uno standard ben preciso che è diverso da quello poi ratificato dall’ISO.

    I lavori dello standard iniziarono nel 1960, e la prima versione arrivò già nel ’63. Successivamente furono apportate delle modifiche che portarono ad altre versioni dello standard.

    Per quanto riguarda l’ISO, soltanto nel ’67 fu accettato l’ASCII del ’63 come base del successivo standard ISO 646, che fu ratificato soltanto nel ’72, quindi dopo quasi 10 anni dalla prima pubblicazione della prima versione dell’ASCII.

    Multics come progetto è INIZIATO nel ’64, quando la prima versione dell’ASCII era già stata pubblicata e, quindi, resa disponibile a tutti.

    Considerato che si tratta di un progetto di compagnie americane, non credo che queste non fossero al corrente delle specifiche dello standard. Semplicemente non hanno voluto seguirne pienamente le direttive per un proprio tornaconto, come ho spiegato prima.

    E’ vero che usando un solo byte c’era un risparmio, ma altri progetti si attenevano ugualmente allo standard, rispettandone le specifiche.
    D’altra parte se si chiama “standard”, ci sarà un motivo, no? ;)

    L’ISO ha deciso diversamente. Potevano benissimo estendere ASCII mantenendone la piena compatibilità, ma non l’hanno fatto.
    Bontà loro, visto che ASCII era già stato pubblicato da diverso tempo, e la loro decisione ha contribuito a creare la confusione che ancora oggi ci ritroviamo.

  • # 11
    Gian
     scrive: 

    Il tuo prof. non sbagliava perchè evidentemnte lui ragionava prendendo in considerazione l’ASCII a 8bit mentre tu quello a 7bit.

  • # 12
    Cesare Di Mauro
     scrive: 

    L’ASCII è uno standard rigorosamente a 7 bit, come puoi leggere tu stesso dal draft del ’63:

    http://wps.com/projects/codes/X3.4-1963/page5.JPG
    http://wps.com/projects/codes/X3.4-1963/page7.JPG

    In particolare il secondo link è piuttosto chiaro in merito.

  • # 13
    Gian
     scrive: 

    si però utilizzare il termine ASCII, omettendo “esteso”, per la codifica a 8 bit non è certo motivo di reato.

  • # 14
    Cesare Di Mauro
     scrive: 

    Il problema è che esiste una moltitudine di codifiche a 8 bit, e molte di esse prendono ASCII come “base” o come “spunto” (cioé alterando qualcosa, come ha fatto l’ISO).

    Per ASCII, però, s’intende una cosa ben precisa. Ed è una codifica a 7 bit.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.