[Soci SLIP] unicode

[Lucio Crusca]

In data lunedì 9 luglio 2012 20:14:26, llcfree ha scritto:
> > 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 :)

Sì, dal p.d.vista della libreria C è giusto, in C potremmo dire che il 
concetto di "carattere" non esiste, in realtà esiste solo il concetto di byte. 
Il problema però esiste quando il programmatore inizia ad aver bisogno di 
contare davvero i caratteri, non i bytes:

int i;
char *stringa = "àèìòù";
for (i = 0; i < strlen(stringa) ; i++)
{
  // qui devo fare qualcosa su ogni "carattere" 
  // (non byte) della stringa,
  // ma stringa[i] non sarà mai il carattere corretto.
}

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

Sì beh in realtà dipende dal linguaggio che usano. Esempio in Java ci pensa il 
framework a fare le dovute traduzioni, senza bisogno di usare librerie 
apposite (ovvero la libreria standard inclusa gestisce già internamente queste 
problematiche).

  "è".length() == 1

mentre invece sorprendentemente in Python

  len("è") == 2

ed in PHP

  strlen("è") == 2

dico sorprendentemente perché Python e PHP, essendo interpretati, sono 
linguaggi di alto livello che mi aspettavo fornissero un'astrazione dei 
caratteri ed una separazione netta fra quello che è un byte e quello che è un 
carattere, ma non è un segreto che a me Python e PHP non piacciono 
particolarmente. Infatti in bash:

export STRINGA="è"
echo ${#STRINGA}
1

come mi aspettavo. 

> 
> Comunque, io invece non credo proprio che l'abbiano risolto. E' il
> codice che va riscritto, una libreria non basta (per il vecchio). 

Intendevo dire che secondo me l'hanno già riscritto/corretto, a meno che non 
parliamo di software non libero o che usano in poche persone (in percentuale).

> 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.

Appunto, percentualmente parlando, TeX lo usano in pochi e quelli che lo usano 
probabilmente sanno come arrangiarsi ed aggirare il problema. Inotre TeX è un 
caso molto particolare, dove il raggiungimento dell'obiettivo che hai citato 
passa per una strada molto in salita già di suo, senza contare 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 :) 

Ok, ma che c'entra con Unicode? Un discorso è poter rappresentare i caratteri 
(Unicode è la soluzione), un discorso completamente diverso è voler 
rappresentare la A maiuscola graficamente allo stesso modo su sistemi diversi 
(un font standard, se esistesse, sarebbe la soluzione, ma per ora la soluzione 
è portarsi dietro il font usato in origine assieme al testo da impaginare e a 
me pare che funzioni).