Utf-8

Negli ultimi tempi ho dato un po’ i numeri, nel senso che ho esplorato le varie forme che i numeri possono avere in giro per il mondo. Oggi in quasi tutti i Paesi, indipendentemente dal sistema di scrittura, i numeri hanno la stessa forma, tuttavia sono ancora in uso numeri dalla forma diversa rispetto a quella che conosciamo, almeno in sei delle lingue supportate da OpenOffice, e ci sono residui dei vecchi sistemi di numerazione, ad esempio quello inventato dai romani, che i software sanno gestire automaticamente per numerare le pagine o i capitoli, o quello ebraico, che si può usare al massimo per indicare l’anno. E in passato sono esistiti altri sistemi ormai in disuso, che però hanno un loro posto in Unicode e vengono utilizzati ogni tanto per scopi decorativi, vedi i numeri Maya sulle banconote del Guatemala.

Un gioco semplice che si può fare con i numeri è quelli di disporli sul quadrante dell’orologio. Se ne trovano a bizzeffe, online, di prodotti realizzati in questo modo: coi numeri cinesi, con quelli binari... Basta trovare i glifi, disporli in cerchio, montarci il dispositivo di un normale orologio e prima o poi qualcuno da qualche parte del mondo vedrà la foto del prodotto e potrebbe decidere di acquistarlo. Con le tecnologie attuali non bisogna neanche fare chissà quale investimento, produrre uno stock... Se arriva l’ordinazione stampi il quadrante, altrimenti no. Non ci si perde niente.

A me non va di spendere soldi per un prodotto del genere, ma nessuno mi vieta di farmene una copia digitale. Basta scaricare il codice javascript che disegna un orologio in una pagina html e cambiare i numeri. Che ci vuole?

Ho provato metterci i numeri cuneiformi. Nessun problema se aprivo la pagina da Pc, ma aprendola da smartphone veniva fuori un po’ di spazzatura. Anziché comparire i glifi della scrittura cuneiforme, venivano fuori lettere latine accentate, legature, cose che non c’entravano niente.

Cos’era andato storto? Evidentemente il software leggeva un byte alla volta. La pagina era un po’ troppo scarna. Bisognava aggiungere una riga di programmazione:

meta charset: “utf-8”

L’ho fatto, e mi è comparso il consiglio di metterlo nella sezione Head invece che nel Body.

Ho eseguito, e tutto è andato per il verso giusto. Adesso nella pagina compaiono i caratteri cuneiformi anche da smartphone. Prelevati da dove, visto che non ho specificato nel codice il nome di un font che li supporti? Da un qualche Noto elaborato da Google, immagino.

Ma cosa significa utf-8?

 

Ore 11:35:49. Se è facile stampare il fondale per un orologio a lancette, sarebbe più complicato (o impossibile) realizzare una radiosveglia con un quadrante personalizzato. Ma una simulazione software può essere ottenuta a costo zero, in una pagina web, con qualche nozione di javascript. I glifi che si vedono in quest'immagine sono tratti dal Segoe UI Historic.

Negli anni Ottanta gli home computer avevano un set di soli 256 caratteri. Questo perché ogni lettera di un testo occupava un byte di memoria, e in un byte ci può entrare un solo numero tra 0 e 255. Ovviamente era possibile personalizzare il set, sostituendo le lettere greche a quelle latine. Ma questo andava bene se si aveva un documento solo in greco. E se uno doveva scrivere nello stesso documento sia parole greche che italiane o inglesi come poteva fare a spiegare al software che bisognava cambiare ogni volta set di caratteri? Come trovare una soluzione che andasse bene a tutti i produttori di software?

È stato creato un consorzio, Unicode, che ha assegnato un valore univoco a qualunque lettera di qualunque alfabeto esistente o esistito. E che periodicamente continua ad aggiungere glifi alla lista, ad esempio a mano a mano che vengono proposte nuove emoji.

La a dell’alfabeto latino è associata al numero 97, la b al 98, la c al 99 e così via. La alfa dell’alfabeto greco è la numero 945.

E avanti così per le migliaia di glifi dell’alfabeto cinese, per i geroglifici o per il cuneiforme.

Senonché nasce un nuovo problema. Perché per memorizzare un numero come 945 non si può utilizzare un solo byte per carattere, ma ne servono due. E ne servirebbero tre o quattro per i numeri più alti.

Questo significherebbe raddoppiare o triplicare la quantità di memoria necessaria per memorizzare un testo perché la lettera a non sarebbe più 97 ma 0-97, o 0-0-97, in due o tre byte. E inoltre non ci sarebbe compatibilità con i testi scritti nel passato. Le lettere abc si memorizzavano impostando i byte a 97-98-99, ma nel momento in cui dedichiamo tre byte a ciascuna lettera ecco che questa sequenza verrebbe interpretata non come un’insieme di tre lettere ma come una lettera unica 979899 (semplifico senza mettere la notazione esadecimale).

La soluzione che è stata inventata è geniale: è la codifica utf-8, in base alla quale i numeri fino a 127 vanno letti da soli, quelli superiori, a seconda del loro valore, vanno letti con uno, due o tre byte di continuazione, oppure sono byte di continuazione.

Per cui la sequenza di byte 97-98-99-206-145 viene letta in questo modo: 97 è minore di 128, quindi viene letto da solo, è la lettera numero 97, quindi la a minuscola dell’alfabeto latino; 98 è la b; 99 è la c. 206 è maggiore di 128, quindi non va letto da solo, ma con un byte successivo. È come se si dicesse: vai alla tabella 206 e prendi la lettera col numero indicato dal prossimo byte.

Il byte successivo è 145, maggiore di 128, quindi non va letto da solo ma come continuazione di una sequenza cominciata nel byte precedente. In questo caso la lettera 145 della tabella 206 è la alfa dell’alfabeto greco.

Con tre byte è lo stesso, ma con un livello in più: così come nei libri c’è un paragrafo primo nel capitolo uno e un paragrafo primo nel capitolo due, così in Utf-8 ci sono vari caratteri indicati dal byte 145, in tabelle diverse che possono essere indicate dal byte precedente, in capitoli diversi indicati dal byte ancora precedente, in sezioni diverse.

Ho semplificato sperando di rendere l’idea a chi non è programmatore. Comunque questo sistema è geniale perché permette di gestire tutte le lingue del mondo nella stessa pagina senza dovere aggiungere delle istruzioni al software sul fatto che si sta cambiando lingua e che bisogna prendere i byte a gruppi anziché singolarmente.

Ogni volta che apriamo una pagina di Wikipedia il browser è alle prese con questo meccanismo, dato che il codice contiene la traduzione della parola che abbiamo cercato in tutte le lingue in cui c’è un articolo su quell’argomento. E, ogni volta che spediamo un messaggio Whatsapp in cui ci sono delle parole e delle emoji, il software è alle prese coi byte, che nelle lettere vanno lette da soli mentre nelle faccine vanno interpretati a gruppi.

Utf-8 è solo una delle possibili codifiche che possono essere utilizzate. Esiste anche la Utf-16, utile per le pagine web in cui compaiono soprattutto testi in cinese perché i caratteri cinesi, pur con lo stesso valore Unicode, vengono codificati in 2 byte anziché in 3, con un risparmio del 33% in termini di memoria. Anche così è possibile usare le lettere latine, solo che occupano una memoria di due byte ciascuna, anziché uno. Il 100% in più.

Qualche anno fa, Blocco Note di Windows aveva come opzione di default il salvataggio in formato Ascii. Questo significava che incollando nel programma una parola in lettere straniere oppure una qualche emoji, salvando e riaprendo, si scopriva che tutte le lettere degli alfabeti diversi da quello latino e le emoji erano state convertite in sequenze di lettere accentate senza senso.

Oggi in automatico i documenti vengono salvati in Utf-8. Tuttavia, quando si clicca su Salva con nome, compare un apposito menù a tendina in cui si può scegliere tra altre codifiche, tra cui varie versioni di Utf-16 oppure Ansi.

Se incollo un po’ di lettere greche e arabe e provo a salvare in codifica Ansi, compare un messaggio che dice che alcune lettere potrebbero andare perse. Se si sceglie di continuare, il risultato varia a seconda delle lettere. La beta greca viene conservata uguale, delta e epsilon vengono convertite in d ed e, mentre la gamma e le due lettere arabe a caso che ho inserito vengono sostituite da punti interrogativi.

La stessa sequenza, inserita in una pagina html viene visualizzata correttamente, sul mio computer, anche senza bisogno di specificare la codifica.

Comunque OpenOffice quando esporta un documento in formato html dichiara automaticamente:

charset=windows-1252.

Su W3Schools c’è una spiegazione, in inglese della distinzione che c’è tra un character set e un encoding.

Unicode è un character set, mentre Utf-8 è un encoding.

Cioè: Unicode è una lista di caratteri associati a numeri ben precisi, diversa da altre liste che magari comprendono solo le lettere latine; Utf-8 è un sistema per suddividere questi valori in un certo numero di byte, tenuto conto che certe combinazioni non sono possibili perché verrebbero interpretate come istruzioni, oppure che per un motivo o per l’altro si ha l’esigenza di usare meno più o meno byte per certe lettere.

A confondere le idee c’è il fatto che per dichiarare l’encoding in una pagina web bisogna scrivere “charset”. 

E che nella stessa pagina, a sinistra, UTF-8 è elencato tra gli Html Charsets insieme a ASCII, WIN-1252 e ISO-8859.

Se nel 2000 quasi il 60% delle pagine web era in Ascii, più del 20% in W Europe, meno del 10% in JIS e le restanti in altri sistemi (Utf-8 ancora non esisteva), dal 2008 in poi quest’encoding è diventato il più usato, raggiungendo nel 2012 il 60% delle pagine web. Tutti le altre codifiche sono in declino e nessuna raggiungeva il 20%, nel 2012.

La tabella è vecchia di 13 anni, ma è questa che viene mostrata da W3Schools nella sua pagina informativa sui Character Set.