Com\’è dura la professione!

14 maggio 2008

Sembra facile dire nj…

Filed under: Programmazione — lbell @ 20:45
Tags: ,

Il corretto trattamento del testo nei programmi pone problemi di design ad applicazioni che a prima vista sembrano semplici, come i word processor. In Europa, senza scomodare le complessità delle scritture asiatiche, sono usati tre diversi alfabeti principali: latino, greco e cirillico. In alcuni Paesi, come nell’area della ex Jugoslavia, quello latino e cirillico coesistono, però non tutte le lettere dell’alfabeto cirillico hanno una corrispondenza in quello latino. Per assicurare l’interscambiabilità dei due alfabeti, le lettere dell’alfabeto cirillico usato in Serbia non presenti in quello latino sono stare tradotte facendo uso di digrammi, cioè di una sequenza di due lettere inseparabili che indicano un unico carattere, Љ viene tradotto con lj, Џ con dž e Њ con nj.

Il problema è che la forma maiuscola dei caratteri cirillici viene resa trasformando in maiuscolo entrambi i glifi latini, mentre quando la lettera si trova all’inizio di una frase, solo il primo glifo dei due va messo in maiuscolo.

In Unicode è stata creata una categoria speciale per questo tipo di lettere, chiamata “titlecase”; ad ogni digrafo sono assegnati tre distinti caratteri, uno per forma, minuscola maiuscola, capitalizzata. In dettaglio lj assume i valori U+01C9, U+01C8, U+01C7, nj U+01CC, U+01CB, U+01CA, dž U+01C6, U+01C5, U+01C4 e tutti si trovano nel blocco del Latin Extended B.

Un buon programma di word processing dovrebbe ovviamente conoscere queste regole che una persona normalmente applica senza nemmeno avere bisogno di pensare.

La gestione del testo nei programmi al di là della semplice memorizzazione, non è affatto un argomento semplice, dal momento che non può prescindere dalla conoscenza approfondita della cultura dei Paesi che impiegano o che hanno dato vita ad un determinato alfabeto.

Unicode Latin Extended B

http://it.wikipedia.org/wiki/Digramma

http://it.wikipedia.org/wiki/Lingua_serba

http://en.wikipedia.org/wiki/Titlecase

Annunci

12 maggio 2008

Lo strano caso del BOM

Filed under: Programmazione — lbell @ 21:07
Tags: , , ,

Leggendo file con programmi scritti in C, un modo per distinguere se il file sia stato codificato in formato Unicode o ASCII senza avere a priori altre informazioni, è di controllare se nelle prime posizioni del file sia presente una sequenza di due byte che danno vita ai numeri esadecimali 0xFEFF o 0xFFFE. Per averne una conferma si provi a salvare un file di testo in formato Unicode con Notepad o Wordpad di Microsoft Windows e caricarlo con editor di testo che non supporta Unicode.

In effetti i due byte sono effettivamente un marker, un carattere Unicode specifico, il cui scopo è dichiarare l’ordine di codifica dei caratteri composti da più byte o, come si dice in inglese, l’endianness, e lo si può legalmente trovare anche nel formato UTF-8. Il suo nome è “Byte Order Mark” o BOM. Si tratta di una sequenza che nel formato Unicode è legale solo se letta in modo da assumere il valore esadecimale 0xFEFF. Il valore 0xFFFE è infatti un carattere illegale. Un programma, trovando questo carattere non rappresentabile graficamente e quindi inseribile senza problemi di alterazione in testo in formato Unicode, può capire se la codifica del file stesso è nel formato big endian o little endian. Lo standard Unicode inserisce il BOM tra i non caratteri (noncharacters); il BOM viene indicato anche come ‘Zero-Width Non-Breaking Space’

A dire il vero nel caso il file sia stato codificato in UTF-32 i byte da esaminare sarebbero quattro, ma il succo del discorso non cambierebbe.

La definizione del BOM:

FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;;;;;N;BYTE ORDER MARK;;;;

Qualche link sull’argomento:

http://en.wikipedia.org/wiki/Byte_Order_Mark

http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters

http://www.unicode.org/Public/UNIDATA/UnicodeData.txt

Crea un sito o un blog gratuitamente presso WordPress.com.