Cenni storici

Non voglio iniziare a sviscerare tutta la storia delle codifiche dei caratteri all’epoca dei primi calcolatori o dei primi sistemi di trasmissione, poiché questa interesserebbe un pubblico molto limitato, quindi direi di partire da tempi più recenti, i tempi in cui la maggior parte delle persone utilizzavano sistemi DOS o DOS compatibili.

MS-Dos e la ASCII

Nel sistema operativo MS-Dos e compatibili, la codifica dei caratteri, ovvero delle lettere, dei numeri, dei simboli e di quelli che sono chiamati semigrafici, era effettuata utilizzando un codice ad 8 bit, chiamato ASCII (American Standard Code for Information Interchange). Questo codice comprende, oltre alle due serie di lettere (maiuscole e minuscole) dell’alfabeto latino esteso, ai numeri, ai simboli matematici di base, anche una serie di «caratteri di controllo» mutuati dai sistemi di trasmissione delle telescriventi per gestire particolari situazioni.

In realtà la codifica ASCII veniva gestita con due tabelle distinte: i primi 128 caratteri formavano la lower ASCII, mentre i restanti 128 formavano la upper ASCII o ASCII estesa.
La codifica dei caratteri della lower ASCII può essere effettuata utilizzando soli 7-bit, e questa parte della tabella veniva condivisa da tutti i sistemi. Qui sono presenti i caratteri alfanumerici e i simboli matematici base.
La codifica dei successivi caratteri, che richiede 8-bit, era però gestita in modo differente. Invece che una singola tabella, sono state fornite una serie di tabelle differenti, con un set di caratteri diverso. Questo perché per esempio i caratteri accentati, che in italiano utilizziamo normalmente, non sono utilizzati in molte lingue, mentre per esempio i caratteri di lingue che utilizzano un alfabeto diverso da quello latino non sono usati in italiano.

Da qui, si è giunti ad avere i primi problemi: i sistemi americani, per esempio, utilizzavano la tabella numerata 437, che comprendeva una quantità aggiuntiva di simboli semigrafici e matematici, mentre per l’Europa occidentale, che utilizza lingue neolatine, era stata predisposta la codifica numerata 850.
Un file di testo scritto con un sistema americano e letto su una macchina italiana sarebbe stato molto probabilmente sbagliato, se fossero stati usati i simboli semigrafici e matematici aggiuntivi, e al tempo stesso, un testo italiano, contenente caratteri accentati, letto su una macchina americana sarebbe stato illeggibile perché agli accenti si sostituirebbero dei caratteri semigrafici. Anche i caratteri semigrafici comuni alle due non si trovavano nella stessa posizione.

Ovviamente i testi americani, scritti soltanto con i caratteri alfabetici latini, non avrebbero avuto problema, d’altronde era l’American Standard, non l’International Standard.

L’arrivo di Windows

Quando Windows, in particolare nella sua versione 3.1, ha iniziato a comparire sul mercato, le cose si complicarono ulteriormente. Partendo da un presupposto giusto (il fatto che i caratteri semigrafici perdessero la loro importanza in un ambiente grafico, e che quindi sarebbe stato preferibile unificare perlomeno tutte le lingue che usano l’alfabeto latino), si è arrivati ad una soluzione che ha creato problemi anche più grossi.

La codifica dei caratteri all’interno di Windows ha assunto dei comportamenti completamente diversi: invece di utilizzare l’ASCII, sono state utilizzate delle codifiche ANSI, ormai chiamate semplicemente Windows CodePages.
La codifica utilizzata, sia su sistemi americani che europei, comprendeva in un’unica tabella la maggior parte dei caratteri utili delle codifiche 437 e 850, rimuovendo i caratteri semigrafici, quindi permetteva ai file di venir letti in modo corretto in entrambi i continenti. Purtroppo però, visto che i caratteri erano loro stessi disposti in modo diverso all’interno della tabella ASCII estesa, questa codifica era a sua volta incompatibile con le varie codifiche ASCII estese.
Per non creare troppi e ovvi problemi, i primi 128 caratteri (la lower ASCII di nuovo) erano presi direttamente dalla ASCII originale, in modo da essere compatibili perlomeno i testi in inglese.

Internet

Ma quando il problema pare risolto, perché finalmente Europa e America potevano comunicare direttamente senza intoppi, è la situazione attorno che inizia a cambiare. Invece di singoli elaboratori, si arriva ad un coinvolgimento globale degli utenti di computer in un’unica, grande, immensa Rete globale… Internet.

L’arrivo su Internet di tutti i vari sistemi eterogenei (MS-Dos, Windows, Unices vari), cominciò a far capire come l’uso di tutte queste codifiche rendeva difficile lo scambio di informazioni da un sistema all’altro. Posta elettronica, gruppi di discussione, pagine web, chat, ognuno di questi servizi, usato da utenti in lingua inglese, non creava nessun problema, ma quando veniva usato da utenti di sistemi diversi, in diverse parti del mondo, in lingue che richiedono caratteri diversi dall’alfabeto base, finiva per creare problemi di comprensibilità e di lettura.

Una soluzione poteva essere quella di utilizzare la codifica Unicode, che invece di essere a soli 8 bit ne utilizza 16, riuscendo a inserire in un’unica tabella oltre 65 mila caratteri. Purtroppo però usare questa codifica significherebbe anche raddoppiare la dimensione di ogni file di testo, cosa poco pratica per una Internet in cui i più fortunati riuscivano a raggiungere i 33.6 kbps.

Si intravide la luce: far in modo che i vari computer in tutto il mondo capissero la differenza tra le codifiche, e potessero riuscire a convertire da una all’altra senza perdita di dati. Questo fu uno dei compiti assegnati al MIME (per la posta elettronica e i gruppi di discussione) e ai meta tag di HTML.

Purtroppo, ancora per qualche anno i sistemi per la gestione di questi servizi non erano in grado di gestire informazioni ad 8-bit, quindi per risolvere il problema si giunse a soluzioni distinte ed incompatibili.
Per la posta elettronica e i gruppi di discussione, la soluzione utilizzata da molti client era quella di utilizzare il quoted-printable. Praticamente invece di inviare un codice ad 8-bit, veniva inviata una stringa del tipo =FF dove FF è la rappresentazione in esadecimale del codice del carattere da inserire.
Per i protocolli di trasferimento, come HTTP, il trucco è stato simile: %FF, dove FF rappresenta la stessa cosa. Per questo capita spesso che, accedendo ad aree personali di utenti unix, indicate solitamente con ~username, questo venga codificato in %7Eusername.
Infine, in HTML, le cose furono più complesse, perché si era voluto far in modo di definire una serie di caratteri «standard» che fossero codificabili arbitrariamente. Il risultato fu l’uso delle entità come per esempio © o è, ed eventualmente l’uso dell’escape dei caratteri particolari ({).
In modo simile, anche il LaTeX utilizza delle speciali entità, come per esempio copyright, se non si specifica una codifica ben definita.

La via degli standard: ISO8859

Infine, le cose cominciarono a migliorare, con la formazione da parte dell’International Standard Organization, di una serie di codifiche ad 8-bit unificate. Questo standard definisce 16 codifiche utilizzate a seconda del tipo di alfabeto che una lingua utilizza. Per esempio, la prima parte (ISO8859-1, chiamata anche Latin1) definisce una codifica (ancora una volta incompatibile con le precedenti ASCII e WindowsCP) per le lingue occidentali moderne, – in realtà ISO8859-1, per quanto standard di fatto per la maggior parte degli usi, dovrebbe essere deprecato, visto che in questa versione mancano il simbolo dell’euro (€) e la Ÿ utilizzata in alcune lingue. Per risolvere questi problemi il (fortunatamente compatibile) successore di ISO8859-1 è ISO8859-15 chiamato appunto Latin1+Euro. – che viene utilizzata come standard per tutte le applicazioni che non definiscono una codifica differente.

L’uso di questi set di caratteri permette allo scambio di informazioni tra sistemi eterogenei di non rischiare la perdita di informazioni: sapendo la rappresentazione delle informazioni e la codifica utilizzata, è possibile convertire queste in un altra rappresentazione utilizzabile nel sistema utilizzato.

Certo, non è ancora la soluzione più sicura per comunicazioni più vaste, come per esempio i progetti di software libero, in cui gli stessi file sorgente, in testo semplice, sono modificati da moltissime persone diverse senza che sia possibile indicare in modo certo e non fraintendibile la loro codifica, oppure per le chat come IRC, dove ogni messaggio viene inviato da un sistema diverso senza che ci sia un accordo «insindacabile» su che codifica utilizzare (analizzerò più avanti questo problema).

Infine, UTF-8

Per una comunità aperta alle esigenze di tutti i linguaggi, Unicode sarebbe stata la soluzione migliore. Ma il raddoppio della dimensione di tutte le informazioni che possono essere codificate con la tabella ASCII base è un problema non facilmente sormontabile.

Per risolvere questo problema, è stato ideato UTF-8. La codifica UTF-8 è una codifica a lunghezza variabile, dove in pratica i caratteri della ASCII base sono codificati esattamente allo stesso modo, mentre tutti i caratteri estesi vengono definiti con una sequenza di più di 8-bit (16 o 24, a seconda di quanti ne siano necessari per indicare la tabella e il carattere). Il risultato è che le informazioni che sono inviate in ASCII pura non occupano un solo byte più del necessario, mentre sono solo i singoli caratteri estesi a “pesare” di più.

Purtroppo, anche UTF-8 ha i suoi svantaggi, primo tra tutti che il sistema (e il programma) utilizzato per la comunicazione deve sapere come trattare questa rappresentazione. Questo problema sta venendo col tempo risolto, ed ormai tutti i sistemi operativi, anche se non utilizzano UTF-8 principalmente, sono capaci di gestire le informazioni codificate in questo modo.

L’overhead, ovvero il peso aggiunto dai caratteri estesi, all’interno dei documenti HTML e LaTeX (giusto per fare un esempio) è tra l’altro inferiore usando UTF-8 che utilizzando le entità definite da questi linguaggi. Stessa cosa vale per i messaggi di posta elettronica codificati in quoted-printable, inoltre è possibile utilizzare gli editor di testo (che supportano UTF-8) in modo molto più naturale.

Problemi pratici e soluzioni

Voglio ora dare uno sguardo ai vari problemi pratici creati dalle diverse codifiche e al modo in cui qusti sono stati risolti nel tempo, e parlare di eventuali soluzioni alternative che possono essere più pratiche nel tempo corrente.

Newsgroups e posta elettronica

Questi sono i due più classici esempi di problema, perché classicamente i client di Microsoft hanno sempre utilizzato le loro proprie codifiche nell’invio dei messaggi, risultando quindi illeggibili per ogni altro sistema o client.

La soluzione utilizzata per più tempo è stata semplicemente quella di non utilizzare i caratteri accentati, e di utilizzare invece i simboli ' o `. Questa soluzione, per quanto valida e utilizzata ancora da molti, è a mio avviso però inutile al momento. Con la standardizzazione dei set di caratteri, e la creazione di UTF-8, la cosa più pratica da fare è semplicemente utilizzare le lettere accentate in modo normalissimo, e lasciare ai client il compito di effettuare la decodifica. Se qualcuno stesse utilizzando un client che non è capace di effettuare la decodifica dei caratteri in ISO8859-1 o -15, il problema è del suo client, esistono alternative per ogni cosa.

Questo è quindi il mio consiglio: non maltrattate l’italiano, non siamo negli anni ’80.. usate pure le accentate.

Pagine web

Il problema più grave che si può avere con le pagine web è quello che molte persone hanno scritto le proprie pagine utilizzando FrontPage o FrontPage Express, creando quindi delle pagine codificate in WindowsCP, che è una delle peggiori cose che si possa fare.

La soluzione consigliata da molti «puristi» è quella di utilizzare la codifica ASCII 7-bit anche qui, e di utilizzare le entità definite da HTML. Io sconsiglio questa soluzione, perché per quanto minimo, crea un certo overhead che può, considerato in totale, essere un problema. Per essere pratici, la cosa più semplice è quella di definire il set di caratteri utilizzato dalla pagina come ISO8859-15 e di utilizzare i caratteri ad 8-bit normalmente o, ancora migliore, utilizzare UTF-8. Il motivo per cui considero questa una soluzione migliore è che molte persone utilizzano UTF-8 come codifica principale, quindi per vedere una pagina UTF-8 non devono effettuare nessuna ricodifica. Per esempio MacOSX utilizza come unica codifica, se non diversamente specificato, UTF-8.

Ricordiamoci che se inizialmente HTTP era utilizzato solo per trasferire file ASCII, ormai viene utilizzato anche per il trasferimento di file binari, quindi non sono più problemi fornire dei file codificati ad 8 bit.

Nomi di files

I nomi di files sono una questione abbastanza complessa. Finché vengono utilizzati solo su una macchina, ognuno potrebbe essere libero di utilizzare la codifica che preferisce. In realtà, penso che la cosa migliore sia anche qui di utilizzare UTF-8 liberamente. Il motivo è che questa codifica diventerà per forza di cose lo standard negli anni futuri, proprio per la continua globalizzazione delle comunicazioni, ed è sempre meglio essere in anticipo sui tempi che in ritardo. In fondo, non crea troppi problemi.

L’unico problema che può esserci è quando i file sono pubblicati su Internet, visto che, mentre FTP pare gestirli più che bene, HTTP ha problemi a gestire nomi di file codificati in UTF-8, essendo previsto l’uso solo di ASCII a 7 bit. Per questo, se dovete pubblicare un file su un server HTTP, il mio consiglio è quello di chiamarlo in un «modo Unix», ovvero corto, senza spazi, e usando sigle.

Io ho iniziato ad utilizzare UTF-8 in locale quando mi sono reso conto che avendo una rete di sistemi eterogenei, usando UTF-8 avrei evitato qualsiasi problema di comunicazione tra le macchine, visto che in questa codifica è possibile rappresentare praticamente qualsiasi carattere esistente.

Internet Relay Chat

Questo è il problema sicuramente più grosso. IRC è un servizio nato, come ogni altro, in America, dove il problema delle codifiche è molto poco sentito, visto che un testo inglese utilizza solo ASCII 7-bit. Inoltre, molti vecchi client non avevano nessuna possibilità di utilizzare qualcosa di diverso dalla codifica di sistema.

I problemi quindi non sono facilmente risolvibili, e vanno analizzati caso per caso. Possono esserci delle richieste relative ad un singolo canale, che vuole utilizzare una sola codifica, o altre relative all’intera rete.

Per esempio, utilizzando i servizi di AzzurraNet, la codifica «standard de facto» è ISO8859-15 (o -1, visto che sono pienamente compatibili, a parte i simboli mancanti, ovvio), poiché la maggior parte degli utenti è di lingua italiana, e questa codifica è la più compatibile possibile.
Invece, su una rete più globale, come FreeNode, è richiesto l’uso di UTF-8, perché possono incontrarsi persone che parlano italiano, arabo, ebraico, giapponese e via dicendo, e non è possibile continuare a cambiare la codifica per parlare con varie persone (il protocollo IRC non definisce un modo per indicare in che codifica sia ogni singolo messaggio).

Utilizzare una codifica «fuori dal comune» può creare problemi agli altri utenti del servizio, che faranno maggior fatica a intendere i messaggi, mentre l’uso del metodo suindicato per la posta elettronica, evitando di utilizzare le accentate, è una storpiatura della lingua, oltre che una precauzione ormai inutile. Anche qui, se il client non riuscisse a decodificare una determinata codifica, la colpa è sua, poiché nel 2005 non è più possibile fermarsi a quello che si faceva negli anni ’80.

Postfazione

Questo testo è probabilmente pieno di errori, dovuti al fatto che la storia delle codifiche la conosco perlopiù a spanne, non sono andato a cercare in maniera precisa date, eventi, e supporti.

Il mio obiettivo era solo quello di fornire delle spiegazioni al motivo per cui i problemi delle codifiche dei caratteri sono stati posti, e indicare cosa serve fare, e cosa è superfluo, per una convivenza pacifica. Come ho già espresso in un altro mio articolo, continuare con delle precauzioni e procedure di molto tempo fa serve solo a sentirsi sulle spine e forzati a comportarsi in modo non naturale, non portando ulteriori benefici alle persone.