[Soci SLIP] unicode

[llcfree]

On Mon, 2012-07-09 at 16:06 +0200, Lucio Crusca wrote:
> In data lunedì 9 luglio 2012 09:48:32, llcfree ha scritto:
> > (Ri)pensando alla questione della standardizzazione dei caratteri
> 
> Immagino ti stia stufando di scrivere le accentate usando l'apostrofo... :)

Macche' :) Per l'email (e con la tastiera americana) resta il modo piu'
pratico. Se poi mi capita di avere una tastiera italiana, per caso,
allora la uso, ovviamente. Ma devo essere in un posto non mio. Io con la
tastiera italiana non riesco a lavorare.

> > (senza
> > la quale non e' pensabile una standardizzazione dei formati, ovviamente,
> > visto che ogni formato e' un insieme di caratteri)
> 
> I caratteri sono entità astratte e definire un formato standard è 
> tranquillamente possibile (e lo si fa continuamente) in modo indipendente 
> dalla *rappresentazione* *concreta* (ovvero in sequenze di bytes) dei 
> caratteri stessi all'interno di un file. Basta includere nella specifica del 
> formato (nella RFC intendo) quale encoding di caratteri deve essere usato in 
> tutto il formato, oppure prevedere che il formato usi un set di caratteri 
> universalmente riconosciuto (ASCII) solo nell'intestazione, e prevedere, 
> nell'intestazione, un campo per specificare in quale altro encoding è stato 
> creato il resto del documento (tipo quel che capita in HTML, o XML, o email, 
> etc...).

Tutto vero, quello che intendevo, pero', e' un'altra cosa, anch'essa
vera. Un testo, qualunque testo, anche quello che va nelle intestazioni
e specifica i formati, e' fatto di caratteri, e da quelli dipende.
L'universalita' comincia dai caratteri. In particolare, pensavo a come
funziona gettext, che e' molto vecchio ma anche l'unico modo "semplice"
di adattarsi al nuovissimo unicode (per chi non lo sa, gettext separa le
stringhe dal codice, in modo che basti aggiungere la corrispondente
traduzione, senza bisogno di toccare il codice, cioe' il programma).  E
pensavo alle applicazioni, che per essere unicode compatible dovranno
fare un bel po' di revisioni, se non sono basate su gettext o qualcosa
di simile. E anche se lo sono.

Senza contare il punto essenziale:

http://en.wikipedia.org/wiki/UTF-8

UTF-8 can encode any Unicode character, avoiding the need to figure out
and set a "code page" or otherwise indicate what character set is in
use 

UTF-8 puo' codificare OGNI carattere unicode, ELIMINANDO LA NECESSITA'
di indovinare e di stabilire un "code page" o indicare QUALE SET DI
CARATTERI SIA IN USO. 

Cioe' eliminando la necessita' di fare quel che ora sta generando una
vera e propria torre di Babele.

> Concordo comunque che il problema della rappresentazione dei caratteri 
> richieda attenzione, ma non per il discorso dei formati.

Come dicevo sopra, UTF-8 elimina tutte le complicazioni, anche nei
formati, che derivano dai caratteri (ingrediente essenziale) usati.
Non volevo mica dire che non ci fossero complicatissimi modi di
risolvere in qualche modo il problema, pur con tutti i malfunzionamenti
del caso, dovuti ad errori o altro, anche senza unicode. Ma il problema
esiste solo per ragioni storiche, perche' sono stati i paesi
angliosassoni a sviluppare ed imporre il codice per i caratteri (non con
la violenza, con la vera forza, quella di chi fa). Ora che altri si
affacciano, il sistema non regge piu' e la soluzione non e' il rattoppo,
e' la rivoluzione con unicode, che il problema semplicemente lo elimina,
lo fa sparire. Basta anche con little e meno little endian, bytes
rovesciati, basta con tutte queste porcherie che fanno dannare per
niente. Il problema? quale problema? Puff! Sparito. Quando unicode sara'
universale, ovviamente, non ora :)

> BTW, hai ancora ricevuto email con caratteri strani come succedeva a volte 
> qualche mese fa?

Non piu'. Io non ho cambiato nulla. Le ricevevo solo con messaggi
originati da Davide C. e Alex P. (forse una volta sola da Lucio, se non
ricordo male) e solo ogni tanto, quando le segnalavo. L'ipotesi piu'
plausibile resta che usassero qualcosa di particolare in casi specifici,
o una rete lungo la quale si incocciava qualcosa non in grado di
interpretare e tradurre correttamente. E' un esempio del fatto che le
soluzioni attuali, basandosi in parte sul tirare ad indovinare, non
possono funzionare sempre. D'altra parte, per un'appllicazione, essere
riscritta in modo da essere unicode compatible, soprattutto se' e'
scritta male, e' un lavoraccio. Io ho pochi dubbi che ci siano
pastrocchi in giro, e tanti.

> > mi e' venuto in mente
> > che i programmatori sono soliti usare %c (c come carattere) e questo non
> > puo' piu' funzionare con unicode (in cui la rappresentazione dei
> > caratteri richiede uno o PIU' bytes). Come si fa? Si usa %s (s come
> > string)?
> 
> Sì, che io sappia. Anche questo però pone dei problemi, in quanto, usando 
> UTF-8:
>  
>   strlen("è") == 2
> 
> perché strlen ritorna il numero di caratteri (intesi erroneamente come bytes) 
> di cui è composta la stringa. 

Be', perche' il numero di bytes *E'* 2. A me semvra giusto che strlen
conti i bytes :)

> > Certo bisogna porsi il problema per il nuovo codice che verra'.
> 
> Credo che i programmatori C se lo siano già posto e lo abbiano già risolto da 
> un pezzo, solo che noi non conosciamo la soluzione, ma è solo una mia 
> impressione. 

Perche' solo i programmatori C? E tutti gli altri? Mica loro il problema
non ce l'hanno.

Comunque, io invece non credo proprio che l'abbiano risolto. E' il
codice che va riscritto, una libreria non basta (per il vecchio). Per il
nuovo, e' diverso. Ma chissa' per quanti secoli ancora il "nuovo" sara'
peggio del vecchio, in questo senso. unicode e' complicato, e la
semplificazione in atto mi fa escludere che in tanti lo sapranno usare e
implementare correttamente.

Per fare un esempio, riscrivere TeX in modo che sia unicode compliant e'
un vero casino. Se lo e' per TeX, che almeno sanno di cosa si tratta, ed
e' nato per avere un testo stampabile NELLO STESSO MODO
indipendentemente da tutto quel che c'e' in mezzo tra l'autore e il
lbro, figurati per gli altri. 

> Tiro ad indovinare: secondo me esiste una libreria che permette 
> di gestire le problematiche relative all'encoding dei caratteri.

Per il nuovo forse si'. Bisogna che la si usi, se si'. 

> > A livello due, poi, c'e' il problema dei fonts standards per
> > rappresentare i caratteri unicode.
> 
> Non capisco in che senso questo sarebbe un problema. Mi risulta che esistano 
> già i fonts con i glifi necessari un po' per tutte le lingue del mondo, mi 
> sbaglio?

Sbagli. Non esiste neppure un arial standard :) Per i font proprietari,
non c'e' verso. Da ben prima di unicode. Una delle ragioni per cui non
si puo' pensare di usare in modo interscambiabile office e libre office
e' proprio dovuto ai fonts che, ovviamente, impediscono di formattare
una pagina in modo compatibile, visto che i fonts sono quelli che
determinano le misure dei singoli caratteri in stampa, come dire, delle
piastrelle, e alla fine la dimensione del pavimento non e' la stessa e
quella della pagina in stampa neppure.

Non c'e' bisogno di credere a me, ma tenete a mente che il casino e'
davvero pressoche' infinito e man mano che indagate forse arriverete a
convincervene da soli. L'importante non e' credere, l'importante e'
sapere che il problema e' reale, e riconoscerne le conseguenze, cosi'
poi si possono cercare le soluzioni.

Loredana