Re: Sulla scrittura di simbolo matematici nei forum

From: posi <positrone1_at_libero.it>
Date: Sun, 23 Feb 2020 13:00:16 +0100

Il 22/02/20 14:44, Soviet_Mario ha scritto:

> potrei dire anche delle castronerie, ma mi sembra che non si colga del
> tutto il problema, accessorio, della corrispondenza tra fonts (che
> condizionano la resa grafica) e codifica nel senso digitale del termine.

Si può ben dire che con unicode questo problema è stato risolto.

Una volta giravano font non convenzionali che mappavano caratteri
esotici *al posto* dei normali caratteri ascii. Questo creava un gran caos.

Oggi invece, se per esempio trovi il codice unicode 221E, sai con
certezza che questo *deve* corrispondere al simbolo di infinito, e lo sa
anche il tuo sistema operativo. Se il font che stai utilizzando non ha
questo simbolo, il tuo sistema operativo lo cercherà in qualche altro
font. Alla peggio non scriverà niente, ma è ben difficile che ciò accada
nel computer di chi si occupa in qualche modo di matematica.


> Unicode è una codifica basata su simboli (se non erro a 16 bit, ma forse
> era solo la vecchia implementazione) in cui certi "range" sono stati
> assegnati alle lingue.
> DOPO di ciò, i font mappano vari set di bitmaps (quelli non vettoriali)
> a certi range di codici, e solitamente un font non mappa l'intero set di
> simboli unicode o diventerebbe molto pesante da caricare per intero
> quando ne usi circa 1/300 esimo alla volta.
>

Certo, ma quando compri un computer in genere è già dotato di uno o due
font abbastanza corposi con dentro gran parte dei caratteri unicode. Non
serve averne chissà quanti.

>> Il problema dell'unicode è solo che una è rogna enorme per i
>> programmatori.
>
> potresti dettagliare meglio questo aspetto ?
> Te lo chiedo perché anche a me crea rogne ma per ragioni non native,
> diciamo : molte funzioni stringa presuppongono solo ASCII e quindi se
> scopro (come ? boh !) che la codifica è unicode, allora devo chiamare
> versioni speciali.

Funzioni stringa che presuppongono solo ASCII e troncano impietosamente
i caratteri a 8 bit non dovrebbero essere più in giro almeno da una
trentina d'anni.

Il problema è che quando vogliamo esaminare il contenuto di una stringa
siamo abituati ad accedere ai singoli caratteri assumendo che ogni
carattere sia un byte, o comunque che per lo meno abbia una lunghezza
fissa, e usare scritture tipo var[2]='c' oppure if(foo[2]=='c') o robe
del genere. Con utf-8 o comunque con caratteri di lunghezza variabile,
questo non è più possibile.

In pratica, se vuoi trovare l'ennesimo carattere devi scorrere l'intera
stringa e contare tutti i byte *tranne* quelli che cominciano i bit "10"
fino ad arrivare ad n.



> Non è nemmeno univoca : molte
> stringhe ASCIIZ stampabili sono di fatto compatibili con molte codifiche
> successive (non so come venga internamente gestito, se in automatico, il
> high order byte uguale a zero in un testo unicode : forse lo zero viene
> rimosso e stop : certi visori esadecimali mostrano i byte stampabili
> intervallati da zeri con unicode, mentre mostrano gli stessi stampabili
> compatti in ASCIIZ).
>

Una stringa rigorosamente ASCIIZ è perfettamente compatibile con UTF-8,
il problema è che in tal caso non puoi usare nemmeno le vocali accentate.
Received on Sun Feb 23 2020 - 13:00:16 CET

This archive was generated by hypermail 2.3.0 : Fri Nov 08 2024 - 05:09:58 CET