{"id":16,"date":"2012-08-14T12:23:00","date_gmt":"2012-08-14T11:23:00","guid":{"rendered":"http:\/\/xmau.com\/wp\/voices\/2012\/08\/14\/calcolatori_e_codifiche\/"},"modified":"2014-10-23T11:04:30","modified_gmt":"2014-10-23T10:04:30","slug":"calcolatori_e_codifiche","status":"publish","type":"post","link":"https:\/\/xmau.com\/voices\/2012\/08\/calcolatori_e_codifiche\/","title":{"rendered":"Calcolatori e codifiche"},"content":{"rendered":"

Quando ho parlato di calcolatori e alfabeti<\/a> ho barato. Pi\u00f9 precisamente, ho omesso di parlare dei vari insiemi di caratteri che assomigliavano vagamente all’ASCII, nel senso che lettere e numeri stavano al loro posto ma altri caratteri no. Chi \u00e8 vecchio come me forse ricorda ancora l’Apple ][, con i suoi caratteri in negativo (ma solo maiuscoli! O erano quelli lampeggianti? Chi se lo ricorda pi\u00f9…) Chi ha giusto qualche anno in meno invece dovrebbe riuscire a ricordarsi il font semigrafico dei primi PC IBM: la cosiddetta “code page 437<\/a>“, che per mezzo di magheggi vari permetteva anche di usare le posizioni riservate ai caratteri di controllo per fare le cornicette. E comunque Windows aveva la sua propria codifica a otto bit, Windows-1252<\/a> (no, non ne avevano provate altre 1251! Semplicemente, i vari Windows 125x corrispondono logicamente agli ISO-8859-y, e permettono di scrivere in alfabeti diversi da quelli latini standard). Anche Apple andava avanti per conto proprio, e fino a OS X aveva il suo charset, Mac OS Roman<\/a>. Ma anche ora che siamo pi\u00f9 o meno tutti d’accordo a usare Unicode in una versione o nell’altra non \u00e8 che le cose funzionino cos\u00ec bene…
\n\"[una \"[Il
\n Iniziamo per esempio a prendere la vecchia codifica UCS-2: in pratica, la prima versione di Unicode con 65536 caratteri (due byte) che sarebbero stati sufficienti per qualunque alfabeto. La codifica di per s\u00e9 \u00e8 semplicissima: ogni carattere occupa due byte, e a ogni coppia di byte corrisponde un carattere. Magari il font che si sta usando non possiede quel carattere, e a video ci appare un rettangolino vuoto, o il carattere �, oppure un numerino esadecimale; ma questi sono problemi secondari, visto che con ogni probabilit\u00e0 se non abbiamo il font giusto non sapremo comunque leggere il testo, e comunque se lo inviamo a qualcun altro, magari lui o lei sapr\u00e0 leggerlo. Tutto perfetto, vero? Quasi. In che ordine vengono salvati questi due byte in un computer? Non \u00e8 dato saperlo: dipende dall’architettura hardware, insomma da come chi ha progettato la CPU trovava pi\u00f9 comodo fare per fare arrivare i byte alle varie unit\u00e0 logiche. In inglese \u00e8 stato persino coniato un termine apposito, “endianness”, tanto per dire. Il modo “big endian”, che \u00e8 quello che usa Internet negli standard e usava Motorola nei suoi chip, \u00e8 quello pi\u00f9 naturale: i bit sono tutti nell’ordine giusto. Il modo “little endian” usato da Intel invece mette a sinistra il byte meno significativo, e quindi il numero 256 non si scrive come 00000001.00000000 ma come 00000000.00000001. Occorre pertanto trovare un modo per capire se l’ordine dei byte \u00e8 quello che serve oppure no; XML se la cava perch\u00e9 i suoi file iniziano sempre con i caratteri <? e quindi pu\u00f2 guardarli, altri si arrangiano.
\nCome se non bastasse, una codifica come UCS-2 per un testo in una lingua occidentale spreca met\u00e0 dello spazio, che costa poco ma \u00e8 comunque scomodo. Cos\u00ec si \u00e8 pensato a una codifica dei caratteri a lunghezza variabile<\/b>: ci sono caratteri “fortunati” e meno fortunati. Il formato UTF-8<\/a> \u00e8 proprio fatto cos\u00ec. Il trucco \u00e8 molto semplice: si codificano i caratteri in questo modo. (U+nnnn \u00e8 il modo che usa Unicode per definire il numero d’ordine dei caratteri, per la cronaca; ricordatevi per\u00f2 che nnnn non \u00e8 un numero decimale ma esadecimale)<\/p>\n