La beta di Adium 1.4.2 aggiorna libpurple (il sottosistema usato da Adium per gestire i vari protocolli di messaggistica) che nella sua ultima versione gestisce il "Multiple Points of Presence" (MPOP) per MSN, ossia la possibilità di collegarvi contemporaneamente da più postazioni, così come annunciato nella stessa beta.

Questa scelta che può sembrare la migliore si dimostra in realtà nefasta allorquando si cerca di installare degli applicativi terzi che non supportano il filesystem case-sensitive. E nello specifico, per quanto mi risulta, c’è solo una famiglia di prodotti che ha questo problema: la suite di programmi Adobe (solo Lightroom sfugge a questa regola). Insomma, niente Photoshop, niente InDesign, niente Illustrator. Niente di niente. Ho atteso quasi un anno l’uscita della suite CS4 sperando che Adobe si decidesse a risolvere questo problema ben noto e che pare affliggere solo l’istaller della sui suite (ma cavolo, un programma che fa assunzioni sul tipo di filesystem a me sembra scritto un po’ male….). A questo punto disperato non mi restava che formattare tutto e ricominciare. E per uno che ha sempre portato alla morte i suoi calcolatori senza MAI formattarli era un dramma. In realtà le ipotesi erano due:

1. Formattare (sigh).
2. Provare a dumpare con DiskUtility l’immagine del disco su un disco esterno e provare nella reistallazione in targhet mode a reistallare da quella immagine, ma con un filesystem diverso (come riportato in questo thread poco chiaro)

Disperato, cerca che ti ricerca ho scoperto questo tool chiamato iPartition della Coriolis, il quale per 37€ vi permette di convertire il filesystem in modalità case-insensitive o viceversa. Mitico! Come funziona: è necessario da prima creare un CD autopartente con l’utility “Coriolis CDMaker” (perché è necessario agire sul filesystem smontato), per poi far ripartire il Mac con questo CD e procedere alla conversione dal menu “Partition->Make case-insensitive” di iPartition. In meno di 5 minuti il gioco è fatto. Non c’è che dire: ottimo acquisto (non abbiate speranze di trovarlo nell’etere digitale )

Per attivare Time Machine è necessario disporre di un disco fisso esterno (USB o FireWire) e di tanta pazienza per il primo backup, quando deve essere effettuato il primo backup di tutto il disco: i successivi aggiungeranno solo le modifiche al filesystem (file e directory modificati e/o aggiunti). Tuttavia, nell'era in cui il costo di un NAS per uso domestico (per chi non lo sapesse, un Network Attached Storage è un dispositivo di rete il cui compito è quello di far condividere spazio disco tra più utenti/computer) è ormai di poche decine di euro, utilizzare un disco esterno semplice può essere molto riduttivo, soprattutto se si dispone di più computer e una rete domestica ben configurata. E non a caso la stessa Apple c'ha pensato, producendo un dispositivo denominato Time Capsule progettato proprio per questo compito. Purtroppo, (forse per motivi commerciali?!?!?!) non sono al momento direttamente supportati comuni NAS di rete, a meno di non effettuare delle operazioni "manuali".

In rete esistono diversi tutorial per risolvere il problema. Tuttavia, è molto difficile trovare delle istruzioni chiare ed in grado di funzionare. In questo mini tutorial proverò a sintetizzare i passi principali per poter configurare Time Machine con un comune NAS di rete, che supporti almeno il protocollo SMB (il protocollo di condivisione dei file adoperato da Windows).

Cominciamo dalla lista della spesa:

1. Un Mac equipaggiato con MacOS X 10.5.2 o superiore (è uscito di recente il 10.5.5, correte ad aggiornarlo )
2. Un NAS di rete con il supporto al protocollo SMB
3. Un router, possibilmente WiFI
4. TAAAAAAAAAAAAAAAAAAAANTA pazienza per il primo backup (all'incirca da un minimo di 5-6 ore ad un massimo di 20!!!)

Il punto 2 merita un approfondimento. Esistono diverse soluzioni oggi disponibili: si parte dai prodotti squisitamente domestici e si finisce ai prodotti specialistici basati su server di storage ridondati che costano svariati migliaia di euro. La soluzione che illustrerò io qui funziona a prescindere dal NAS purché supporti almeno il protocollo SMB. In realtà, i NAS domestici sono "simili" in tutto e per tutto a quelli di fascia alta: in genere sono equipaggiati con un Linux embedded con tutto il software necessario alla gestione del disco e dei servizi di rete.
Per le utenze domestiche esistono due famiglie di prodotti che oggi vanno per la maggiore: i prodotti della Lacie e quelli della Western Digital. I primi sono certificati per funzionare come NAS SMB, e il software a corredo fornisce tutto il necessario per configurare gli SHARE SMB (ossia le unità logiche di rete). I secondi, invece, ufficialmente sono raggiungibili solo tramite il software a corredo, denominato MioNet e disponibile SOLO per Windows (ufficialmente il Mac non è supportato). In realtà, la distribuzione di Linux a corredo fornisce Samba ed è pertanto possibile agganciare l'unità via SMB. In questo tutorial assumerò NAS proprio il WD MyBook World Edition, in mio possesso, anche se la procedura corretta funziona con qualunque disco di rete, compresi quelli di fascia alta.

Pronti, via.

Passo 1: il primo passo consiste nella configurazione del NAS. La prima cosa da effettuare è collegare il dispositivo alla rete per mezzo di un router, possibilmente WiFI. Nel caso del WD MyBook WD, il dispositivo è configurato per richiedere l'indirizzo di rete via DHCP, quindi bisogna assicurarsi che il router sia configurato per dare gli indirizzi dinamicamente (se non avete fatto nulla, allora qualunque router di fabbrica esce con il DHCP abilitato). Il passo successivo è scoprire l'indirizzo IP assegnato. Nel caso del WD, dopo circa 2-3 minuti che avete collegato il dispositivo alla rete e terminata la sua fase di inizializzazione (tutte le lucine blu accese), sarà automaticamente disponibile nel Finder, nella sezione "CONDIVISI" con il nome di "mybookworld", come mostrato in figura.

Cliccando sulla voce "mybookworld" scopriamo che è disponibile un unico share denominato PUBLIC: questo è uno share di pubblico accesso, per cui non è necessaria alcuna autenticazione. Per questo motivo ne sconsiglio l'uso: per proteggere i backup è meglio crearne uno nuovo dotato di username e password.
Per fare questo è necessario accedere all'interfaccia web del dispositivo e creare un nuovo CIF (questa è la dicitura che troverete nel WD My Book World). Per prima cosa dobbiamo scoprire l'indirizzo IP del dispositivo. Apriamo un terminale (Applicazioni->Utility->Terminale) e digitiamo il comando:

smbutil lookup mybookworld

Il comando ci restituirà l'indirizzo IP. A questo punto inseriamo l'indirizzo IP nel browser, e accediamo all'interfaccia di gestione. Se è la prima volta, le credenziali necessarie per accedere sono admin/12345. Nella schermata che apparirà, scegliere la voce "File Sharing", come riportato in figura sotto:

Scegliere la voce "User Management" per aggiungere un nuovo utente, e successivamente "Add a Shared Folder" per creare un nuovo CIF, che per convenzione chiameremo "TIME". A questo share daremo massimi privilegi all'utente creato, e negheremo tutti i privilegi agli altri utenti.
A questo punto dobbiamo montare il dispositivo. Andiamo nel Finder e scegliamo dal menu la voce "Vai->Connessione al server" e digitiamo nella finestra che ci apparirà la stringa smb://<indirizzo-ip-del-nas>, dove con <indirizzo-ip-del-nas> intendiamo l'indirizzo che abbiamo scoperto poco fa, come mostrato nella figura sotto:

A questo punto è possibile verificare nel Finder la presenza del nuovo volume, ed entrarci all'interno dopo aver inserito username e password. Ok, primo passo finito.

Passo 2: il secondo passo consiste nel creare uno speciale file, chiamato "immagine disco sparse bundle" che servirà per contenere i backup di Time (tecnicamente, abbiamo bisogno di creare un file immagine HFS+ che per forza di cosa sarà contenuto su filesystem SMB – nel caso del WD MyBook WD Linux/ext3). Un file immagine non è niente altro che un file che si comporta come un disco fisso normale, e nel Mac è possibile crearli al volo grazie l'Utility Disco.
La convezione è questo file si chiami come il mac address della scheda di rete principale del vostro Mac (iMac, MacBook, ecc) senza i ":", più l'estensione  ".sparsebundle" (MAC-ADDRESS.sparsebundle). Ma andiamo per gradi. Torniamo al terminale e digitiamo il comando:

ifconfig

Il dato a cui siamo interessati è quello evidenziato in colore rosso nella figura sopra, ossia il MAC-ADDRESS della scheda di rete principale (en0), senza i ":". Nel nostro caso, ci interessa la stringa 001b63af64ec. Messa questa stringa da parte, lanciamo Utility Disco (Applicazioni->Utility->Utility Disco) e scegliamo la voce "Nuova Immagine". Il nome di questa immagine dovrà essere l'indirizzo di cui prima più l'estensione ".sparsebundle". La dimensione dovrà essere adeguata (almeno la dimensione del disco fisso del vostro Mac), e le impostazioni devono corrispondere a quelle riportate nella figura sotto (importante è scegliere "Nessuna mappa delle partizioni" e "Immagine disco sparse bundle")

Salviamo l'immagine. Al termine delle operazioni, copiamo il file creato (001b63af64ec.sparsebundle) all'interno dello SHARE creato sul disco di rete (TIME nel nostro esempio).

Passo 3: abbiamo quasi concluso. Il passo finale consiste nel dire a Time Machine di adoperare anche unità condivise di rete. Sempre da terminale digitare il comando:

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

A questo punto basta posizionarsi nelle Preferenze di Sistema -> Time Machine e selezionare come disco lo SHARE che abbiamo creato (TIME nel nostro esempio) e avviare la procedura di backup.

Il tutorial è finito

Ora alcune considerazioni e raccomandazioni. Innanzitutto, se disponete di un Mac di ultima generazione che supporta il protocollo 802.11n per la Wi-Fi, e di un router con la stessa funzionalità, allora è consigliabile l'acquisto del NAS LACIE perché dotati di una porta gigabit ethernet che può sensibilmente incrementare la velocità di backup ed accesso al disco per scorrere i vari backup (il WD purtroppo non dispone di questa funzionalità. Peccato). Un altro trucco consiste nel ridurre la frequenza di backup di TimeMachine (per default ogni ora) con l'utilizzo di un comodo tool come TimeMachineEditor. Un'altra raccomandazione è quello di evitare di creare un'immagine troppo piccola, per evitare di perdere i backup. Il doppio della dimensione del disco del vostro Mac è più che sufficiente, ma è anche vero che un backup più "oculato" può ridurre la necessità di spazio: utilizzando le opzioni di TimeMachine è possibile escludere dal backup file o cartelle che contengono dati magari sottoposti ad altri backup, come video ed immagini.

Siamo giunti vermente alla fine di questo mini-tutorial. Per qualunque difficoltà non esitate a contattarmi, ed esorto coloro che hanno problemi nel far funzionare il tutorial al leggere con attenzione i commenti riportati sotto.

FAQ

• Non riesco ad individuare il Mac-Address della scheda di rete tramite il comando ifconfig
  È possibile procedere con questa altra alternativa. Posizionarsi in Preferenze di Sistema -> Network. Poi, selezionare la voce Ethernet e cliccare su "avanzate". Dopo di che scegliere il tab "Ethernet". Il primo campo è proprio quello che ci serve: selezionare il valore ed eliminare i ":". Quello è il nome da dare al file sparsebundle, che ricordo non deve avere la mappa delle partizioni e deve essere di dimensione adeguata (sicuramente maggiore dell'attuale occupazione di spazio sul disco).
• Nonostante ho seguito correttamente il tutorial, continuo ad avere il messaggio "Impossibile creare l’immagine disco di backup"
  Leggendo nei commenti dell'articolo, qualcuno ha riportato l'impossbilità di effettuare il backup nonostante le procedure individuate. Michele Torbidoni sembra aver individuato come buona una soluzione già apparsa altrove in rete, ma che nel mio caso non aveva correttamente funzionato. La soluzione consisite nel creare il file sparsebundle con il nome "NOMEMAC_MACADDRESS.sparsebundle". Ad esempio, se il vostro mac si chiama "Casa", chiamare il file "Casa_0303029292.sparsebundle" (ovviamente il mac address deve essere quello del vostro Mac). Marco suggerisce più sotto che il nome del Mac non deve avere caratteri speciali e superare gli 8 caratteri. Insomma, provate anche queste soluzioni.
• Con Snow Leopard (10.6.1) la procedura non sembra più funzionare
  Pare che le cose siano cambiate (io ancora devo provare Snow Leopard). Questo articolo mostra come rendere la procedura rifunzionante.

Che dire: sono 48 ore che lo sto usando attivamente e al momento non mi sembra per nulla necessario installarci su Windows o altri sistemi. Al modello di interazione del Mac OS ci si abitua molto presto, e devo dire che è molto intuitivo. Ho già installato Xcode 3.0, fornito gratuitamente nel DVD di installazione del sistema, e presto proverò a vedere come realizzare programmi. Soprattutto perché, tra le tipologie di progetti disponibili in Xcode ho visto che c’è ne è una molto interessante: Python-Cocoa . Stay tuned.

Da parte mia ho cominciato a collaborare con Stacktrace.it con una miniserie di due articoli in cui provo a riportare quelle che sono state le mie esperienze su aspetti di management nelle piccole e medie aziende informatiche. Il primo articolo è stato pubblicato oggi, e si intitola "Il management del software nelle microaziende", e vuole dare una serie di indicazioni su quelle che io definisco le "azioni a costo zero ma dai benefici inestimabili" che una microazienda informatica dovrebbe adottare nel processo di produzione.
Commenti come sempre apprezzati, ma ovviamente questa volta sul sito di Stacktrace.it.

1. Non è Java e in quanto tale non è molto diffuso
2. Non è un linguaggio di ‘basso livello’ in cui ci si deve preoccupare di gestire l’allocazione di variabili, puntatori, ecc
3. È sicuramente un linguaggio di ispirazione più moderna
4. Non si è necessariamente vincolati alla Microsoft

Quest’ultimo punto è quello che mi ha spinto ad avventurarmi nell’impresa: nonostante C# sia un linguaggio di casa Microsoft, è stato standardizzato (fino alla versione 2.0, ma è in corso di standardizzazione la 3.0) dalla ECMA, e grazie al progetto Mono è possibile sviluppare e distribuire applicazioni C# (attenzione, ho detto C# e non .NET) su qualunque piattaforma (Linux, Win, Mac, UNIX). In realtà conoscevo già il progetto Mono, e in passato aveva provato a darci uno sguardo. Fino a 2 anni fa poteva considerarsi poco più di un progetto sperimentale a vita (una sorta di Wine), ma di recente grazie al contributo di Novell si può considerare una piattaforma Open completa ed affidabile, che sta in tempi brevi supportando anche le versioni 3.0 e 3.5 di .NET.
Quindi, secondo me, l’abbinata C# + Mono può essere considerata una valida alternativa per lo sviluppo di applicazioni multipiattaforma.

Ma veniamo al C#. Beh, devo dire che ritornare dopo anni a pensare ‘statico’ è stato uno shock, molto ma molto più forte del processo inverso, ossia abituarsi alla tipizzazione dinamica venendo da quella statica. La tipizzazione dinamica porta a pensare in termini di funzionalità e di interfacce di oggetto (cosa ancor più vera in Python che ha potenti funzionalità di introspezione), a concentrarsi sulla struttura del programma e non sulla coerenza di tipi e variabili e a generare codice molto ‘prolisso’ e dispersivo. Insomma, il duck typing spinge il programmatore a scrollarsi dalle frustrazioni tipiche che si hanno quando si programma con linguaggi più tradizionali. E a dirla tutta, ho la sensazione che la tipizzazione statica sia la preistoria dell’informatica (e dell’ingegneria del software stessa), e che forse Microsoft poteva osare un po’ di più nel proporre un linguaggio nuovo. Ma ammetto che in genere questo tema divide non poco i programmatori.
Mettendo per un attimo da parte la tipizzazione, cosa c’è in C# che può accumunarlo al Python, o magari renderlo ancora più distante? Secondo Federico, addirittura a tratti C# è un Python con le parentesi graffe. Sarà così?
Queste sono una serie di conclusioni a cui sono giunto dopo i primi 10 capitoli di questo libro della O’Reilly:

1. quasi 100 keyword: troppe. Punto.
2. le parentesi graffe se le potevano risparmiare: non se ne può più! Sono 35 anni che ci ritroviamo queste maledette {} d’avanti, e veramente è troppo. Innanzitutto, il codice sorgente diventa estremamente lungo e farraginoso, quando con il ‘:’ di Python si riesce a rendere tutto molto più compatto e pulito

   public void myFunc(int param) {
     if (param > 1) {
          Console.WriteLine(i);
     }
}

   quando, invece, in Python basta scrivere:
   

   def myFunc(param):
    if param > 1:
        print param

   Poi, a me sta venendo il tunnel carpale per digitare la combinazione Altgr+Shift+[
    

3. datemi la print: si è vero, anche Python 3.0 avrà la sua brava funzione print() al posto di una keyword, ma print() è infinitamente più breve di Console.WriteLine()
   
4. ok agli shared references: anche C# implementa il modello degli shared references come Python. In parole povere, una variabile C# è una terna del tipo (nome, tipo, riferimento), e i tipi primitivi generano oggetti immutabili. Quindi l'operazione di assegnamento implica far condividere a due nomi lo stesso riferimento ad un oggetto. L'unica differenza con Python è che il passaggio di parametri può avvenire anche nella modalità 'ref', dove ad essere passata come parametro non è il solo riferimento ma tutta la varabile (poi, voglio capire perché tutte le guide e i manuali che ho letto hanno un'abilità tale a complicare l'argomento che difficilmente si riesce a comprendere che il concetto che c'è sotto è molto semplice).
5. non bastavano protected, private e public: C# supporta i tipici modificatori di accesso del filone C++ (in realtà manca friend), ma ne introduce di nuovi come internal (accessibile dalle classi dello stesso assembly - una sort di friend con scope a visibilità di modulo), ma anche override per indicare che una sottoclasse sta effettuando l'overriding di un metodo. Se non si è capito, faccio parte di quelli che sono convinti che impiegare 10 giorni per decidere se una metodo o un attributo devono essere private, internal o public è solo una perdita di tempo e un offesa all'intelligenza dei programmatori.
6. polimorfismo ed ereditarietà controllata: C#, sulla falsa riga di C++, permette di controllare il polimorfismo con l'uso del modificatore virtual, ma anche con override per indicare espressamente che un metodo effettua l'overriding di un altro. Anche l'ereditarietà può essere controllata e anche impedita per mezzo della keyword sealed (l'equivalente del final Java). Tutti i tipi primitivi la usano, e quindi non si può derivare, ad esempio, dal tipo String, cosa che al contrario in Python è possibile da un bel po' di tempo (versione 2.2), ma è anche vero che le stringhe C# supportano in maniera nativa Unicode, cosa che in Python non avverrà prima della versione 3 con l'unificazione di oggetti str e unicode. 1-1 e palla al centro.
7. interessante l'implementazione del costrutto di interfaccia: C# implementa il costrutto di interfaccia. Ora, non c'è molto da meravigliarsi dato che siamo in presenza di un linguaggio moderno a tipizzazione statica, però lo fa in maniera molto interessante. Infatti, è possibile estendere interfacce (creare interfacce che ereditano da altre interfacce), è possibile definire polimorfismo a livello di interfaccia, è possibile definire vincoli sui tipi dei 'generics' in base ad un'interfaccia prestabilita (con la keyword where), esporre selettivamente i metodi di un interfaccia.
8. generics, servono: mancavano nelle prime versioni di C#, ci sono dal 2.0. In un linguaggio a tipizzazione statica, se se ne abbraccia il credo, servono. Interessante la possibilità di poter definire vincoli sull'interfaccia del tipo generico T.
9. direttamente da Python, i generatori: pardon, gli enumeratori. Esattamente lo stesso concetto presente in Python (stessa keyword yield), ma basati su un'interfaccia specifica IEnumerable<T>. Inutile dire che sono utilissimi.
10. dizionari con keyword arbitrarie: il tipo Dictionary<K,V> (che non è primitivo come in Python) consente di specificare tipi arbitrari per le chiavi, e non solo oggetti immutabili come in Python, a patto che tale oggetto non cambi nel flusso di esecuzione.
11. possibilità di specificare funzioni di conversioni tra tipi: questa è una funzionalità che reputo sublime. A differenza di quanto si legge in giro, C# è un linguaggio fortemente tipato e quindi non c'è il concetto di cast presente nel C (che è debolmente tipato). Quello che viene chiamato erroneamente cast, è la possibilità del C# di specificare le funzioni di conversione dei tipi, sia implicite sia esplicite. Ad esempio:
     

    public static implicit operator MyType(int i) {
    //Qui il codice di conversione da intero
}
public static explicit operator int(MyType t) {
    //Qui il codice di conversione verso intero
}
...
public static void Main(string[] args) {
    MyType t = 10; //Usa la conversione implicita
    int a = (int)t; //Usa la conversione esplicita
}

Queste sono le prime osservazioni che riesco a fare su C#. Man mano che andrò avanti nello studio del linguaggio e del framework Mono posterò nuovi articoli. Nel frattempo, come sempre, sono apprezzati commenti ed osservazioni.

A leggere in giro nella rete sembrerebbe esattamente il contrario. Praticamente tutti i giorni si legge di programmatori disperati che non sanno come trattare stringhe di testo contenenti caratteri Unicode, e spesso le soluzioni trovate sono alquanto naïf e sbagliate. Insomma, lo Unicode è per mia esperienza la bestia nera degli informatici del nuovo millennio, nonostante il web sia pieno di ottimi tutorial molto completi per approfondire la materia.
E forse è proprio questo il nocciolo della questione: le guide, i tutorial, gli howto elaborati per i vari linguaggi di programmazione spesso sono troppo completi ed esaustivi. Per carità, lungi da voler criticare il lavoro svolto da altre persone, ma per mia esperienza personale in questo tema più si tiene basso il livello e meglio si comprende qual è esattamente il problema. Per poi successivamente magari approfondire tutti i dettagli per gli amanti della storia dell'informatica.

In questo mini tutorial mi propongo di trascodificare su carta l'esperimento effettuato alla PyCon Due, e cioè presentare Unicode in soli 5 minuti. Si, avete capito bene. Vi chiedo di impiegare soltanto 5 minuti del vostro tempo, in cui vi impongo di rilassarvi e di dimenticare tutto quello che avete letto in giro fino ad ora.
Per illustrarvi gli esempi adopererò i linguaggi di programmazione Python e Java, ma sappiate che tutto quello che dirò potrà essere direttamente riportato in qualunque altro linguaggio di programmazione come C#, Visual Basic.NET, ecc – se vi aspettavate di leggere anche 'PHP' sappiate che ancora oggi, con PHP5, non c'è un supporto nativo alle stringhe Unicode.

Relax. Respiro profondo. Via.

Minuto 1 – Lo standard ASCII 7-bit non è in grado di rappresentare tutti i caratteri di tutti gli alfabeti esistenti

L' ASCII è uno standard di codifica dei caratteri che associa i numeri da 0 a 127 ad un carattere ben preciso (non bisogna dimenticare che i computer sanno trattare esclusivamente numeri). Nello specifico, soltanto i numeri da 32 a 126 corrispondono a caratteri stampabili, tutti gli altri sono i cosiddetti caratteri di controllo. I caratteri contemplati dallo standard ASCII sono soltanto i caratteri dell'alfabeto latino (dalla A alla Z, maiuscoli e minuscoli). So già a cosa state pensando: "ma sulla mia tastiera ci sono anche le vocali accentate". Ebbene questo è un punto di confusione: lo standard ASCII originario a 7 bit fu successivamente esteso a 8 bit per contemplare caratteri di alfabeti specifici (si parla per l'appunto di ASCII esteso). Questi 128 caratteri in più furono adoperati per codificare lettere specifiche dei singoli alfabeti, come le vocali accentate. Il compito di rimappare i codici numerici a lettere di un alfabeto era demandato ai cosiddetti codepage, che nel caso dell'alfabeto italiano (e non solo) per i PC equipaggiati con MS-DOS era il codepage 850. Tuttavia, se 128 caratteri aggiuntivi sono sufficienti a rappresentare tutti i caratteri degli alfabeti dei paesi 'occidentali' (comprese le vocali accentate, lettere con dieresi, ecc), non lo sono affatto per quei paesi i cui alfabeti superano abbondantemente tale numero di caratteri (si pensi agli ideogrammi cinesi). Insomma,

Minuto 2 – UNICODE è uno standard che associa ad un carattere un solo codice numerico

Per aggirare questa intrinseca limitazione dell'ASCII, le principali aziende del settore informatico unirono i loro sforzi per formare un consorzio con l'obiettivo di standardizzare tutti i caratteri esistenti in tutti gli alfabeti possibili: lo Unicode Consortium.
Lo Unicode è uno standard che assegna univocamente un numero ad ogni carattere di scrittura testi, indipendentemente dalla lingua, dalla particolare piattaforma software, dalla sua specifica rappresentazione in bit. Con Unicode ogni carattere ha il suo numero e non esistono caratteri con lo stesso numero. Ad esempio, il numero in base dieci 224 corrisponde alla lettera 'à'; mentre il numero in base dieci 1590 alla lettera araba 'sad' (ض). In realtà i codici Unicode sono rappresentati in esadecimale, con 4 o 6 cifre, e nello specifico nella forma 'U+XXXX'. Ad esempio, la lettera accentata 'à' ha rappresentazione 'U+00E0', mentre la lettera araba 'sad' (ض) ha rappresentazione 'U+0636'.

Usare Unicode è semplicissimo e bastano pochissimi passi.

1. Dirigetevi sul sito web di Unicode e nello specifico nella sezione 'code charts';
2. Scegliere una tavola di una famiglia di caratteri, ad esempio la tavola latin1 della famiglia degli alfabeti europei;
3. Vi apparirà un documento PDF contenente la tavola dei caratteri latin1, (di cui sotto è riportato un estratto), ed incrociando i valori delle colonne con quelli delle righe è possibile ottenere il codice Unicode del carattere desiderato.

Come possiamo sfruttare le tavole Unicode nei nostri programmi? Beh, nulla di più semplice: si riporta banalmente il codice Unicode del carattere desiderato nelle stringhe di testo in formato Unicode, usando la sequenza di escape '\uXXXX', dove XXXX è il codice esadecimale Unicode.
Ad esempio, in Python basta scrivere:

>>> data = u'\u00E0'
>>> print data
à

In Java, è praticamente la stessa cosa:

public class Prova {
      public static void main(String[] args) {
          String data = "\u00e0";
          System.out.println(data);
      }
}

Fine. Non c'è nessun altra informazione da aggiungere. Unicode è semplicemente questo, ed è importante sottolineare che lo Unicode non dice NULLA su come questi caratteri debbano essere rappresentati in macchina (infatti, spesso si parla di caratteri 'idealizzati'). Questo significa che da solo Unicode non basta a poter trattare i testi con questa codifica. Insomma,

Minuto 3 – Un codec è una funzione che data una sequenza di caratteri Unicode restituisce una stringa di byte

Come già detto nel minuto precedente, una stringa di caratteri Unicode è una sorta di stringa 'idealizzata', che necessita di un ulteriore trasformazione per poter essere salvata, scambiata tra sistemi, interpretata da un browser. Tale processo di trasformazione in stringa di byte (o anche stringa binaria) è demandato ad un codec. Questo è il passaggio più delicato ed è anche quello dove si hanno tutte le difficoltà con Unicode. ASCII era una codifica che si occupava di standardizzare sia i caratteri sia la loro rappresentazione in bit. Unicode al contrario, si limita a standardizzare i caratteri lasciando ai codec la seconda funzione.

Un codec non è altro che  una funzione di trasformazione: dato un carattere Unicode restituisce la corrispondente sequenza di byte. Esistono diversi codec compatibili con Unicode e la maggior parte di loro non è in grado di codificare tutti i caratteri standardizzati dallo Unicode. Ad esempio, ISO-8859-1 è il codec di trasformazione dei caratteri dell'alfabeto latino che, ad esempio, associa alla lettera 'à' (U+00E0) la stringa di byte "\xe0" (questa procedura di trasformazione è anche detta encoding). ISO-8859-1 è un codec a lunghezza fissa, ossia associa sempre e solo un byte per i caratteri che può codificare (ad un codec specifico per l'alfabeto latino non potrete mai far codificare un ideogramma cinese).
UTF-8 (acronimo di Unicode Trasformation Format) è un altro codec, a lunghezza variabile, dove un carattere può essere rappresentato con un minimo di un byte fino ad un massimo di quattro byte. UTF-8 è in grado di rappresentare qualunque carattere dello standard Unicode e, ad esempio, associa la stringa di byte (due in questo caso) '\xc3\xa0' alla lettera 'à' (U+00E0).

Come fare per ottenere una stringa di byte a partire da una stringa idealizzata Unicode? Nulla di più facile. In Python possiamo fare questo per mezzo del metodo 'encode()' di un oggetto unicode:

>>> a = u'\u00e0'
>>> a.encode('iso8859-1')
\xe0
>>> a.encode('utf8')
\xc3\xa0

In Java:

public class Prova {
    public static void main(String[] args) throws java.io.UnsupportedEncodingException {
        String data = "\u00e0";
        byte[] byte_string = data.getBytes("UTF8");
        System.out.println(byte_string);
    }
}


L'operazione inversa a quella di encoding è il decoding di una stringa di byte per ottenere una stringa Unicode. Supponiamo di avere un file di testo, codificato con un dato encoding, ad esempio UTF-8. Per ottenere una stringa Unicode in Python avremo:

>>> ustr = open("filename").read().decode('UTF8')
>>> type(ustr)
<type 'unicode'>

In Java avremo:

import java.io.*;

public class Prova {
    public static void main(String[] args) throws java.io.UnsupportedEncodingException {
         try {
             BufferedReader rdr = new BufferedReader(
                  new InputStreamReader(new FileInputStream("filename"),
                  "UTF-8"));
             String line = rdr.readLine();
             System.out.println(line);
         } catch (IOException exc) {
         System.err.println("I/O error");
     }
    }
}

La figura sotto schematizza il processo di encoding/decoding.

Riassumendo,

Minuto 4 – Per interagire con una stringa di byte è necessario conoscere l'encoding con cui è stata codificata

L'ultimo concetto importante da tenere bene a mente è che in generale è indecidibile dire una stringa di byte con quale encoding è stata generata. Ad esempio, consideriamo la sequenza di due byte '\xc3\xa0'. Da umani non ci risulta difficile riconoscere che siamo alla presenza della lettera 'à' codificata in UTF-8. Tuttavia, nulla vieta di essere in presenza di due caratteri codificati con un codec a 1 byte. Ad esempio, in Python in maniera perfettamente lecita possiamo scrivere:

>>> print u'\u00E0'.encode('utf'8').decode('ISO-8859-1'), "-"
à -


Con questo frammento di codice stiamo dicendo: prendi il carattere Unicode U+00E0 (à), codificalo con l'encoding UTF-8 e la stringa di byte ottenuta decodificala con ISO-8859-1. Quello che otteniamo non è più il carattere originario di partenza, perché il primo byte '\xc3' viene interpretato come il carattere 'Ã' mentre il secondo '\xa0' come spazio, perché così contemplati dallo standard.
Questo esempio ci fa capire che quando si manipolano dati, qualunque sia la provenienza, è importante sapere con che codec sono stati codificati. Il caso più tipico si verifica quando si cerca di manipolare stringhe di byte con gli encoding di default, che nel caso di Python è 'ascii' su tutte le piattaforme (come configurato nel file site.py), mentre in Java è un parametro dipendente dal particolare sistema: su Windows è 'cp1252', come indicato dalla funzione System.getProperty("file.encoding"), ed è possibile alterarlo alla riga di comando della JVM con il parametro -Dfile.encoding=<codec>.
Ad esempio, sempre dall'esempio di prima, adoperando l'encoding di default di Python abbiamo:

>>> data=open("curr.txt").read().decode()
Traceback (most recent call last):
  File "C:\Documents and Settings\cnoviello\Desktop\pro.py", line 1, in <module>
    data=open("curr.txt").read().decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position 0: ordinal not in range(128)


ottenendo un messaggio di errore molto noto a tutte le persone che hanno avuto a che fare con problemi di gestione dello Unicode. Altra alternativa è rappresentata dalla funzionalità di 'replace' della funzione 'decode()': è possibile specificare al decodificatore di sostituire tutte le sequenze di byte che non hanno corrispondenza nel codec con il carattere di sostituzione Unicode U+FFFD (il famigerato � che tipicamente visualizzano i browser quando non sanno decodificare correttamente una sequenza di byte).

>>> print u'\u00e0'.encode('utf8').decode('ascii', 'replace')
��


E' importante, quindi, che l'applicazione abbia una gestione consistente dell'encoding della fonte dati: si fissa un codec e si continuerà ad adoperarlo sempre. A meno di non sapere con esattezza che cosa si sta facendo. Ad esempio, è molto semplice convertire stringhe di byte codificate in un dato encoding sorgente in uno nuovo. Il seguente codice Java fa proprio questo:

public static byte[] convert(byte[] data, String startEncoding, String targetEncoding) {
      //Si decodifica la stringa di byte grazie al costruttore della
      //classe String, ottenendo una stringa Unicode
      String str = new String(data, srcEncoding);

      //Si ricodifica la stringa dato un encoding prefissato
      byte[] result = str.getBytes(targetEncoding);

      return result;
}

Un discorso analogo può essere fatto nel caso dei documenti HTML. Ricordarsi sempre di specificare l'encoding dei propri documenti tramite la direttiva:

<meta http-equiv=content-type content="text/html; charset=UTF-8">

Riassumendo,

Minuto 5 – Utilizzare sempre il codec UTF-8

Dagli esempi visti in precedenza emerge che la scelta del codec da utilizzare per i propri dati non è banale, ed è intrinsecamente connessa con la tipologia di caratteri che si andrà a gestire. Se ci si limita ai soli caratteri dell'alfabeto latino, la classica codifica ISO-8859-1, nota anche come latin1, o la cp1252 di Windows (quella di default per le localizzazioni di Windows per i paesi 'occidentali') è più che sufficiente. Tuttavia, questi encoding non sono in grado di codificare caratteri non latini (si provi per esercizio a codificare in ISO8859-1 il carattere Unicode U+03A9 che corrisponde alla lettera greca 'Ω'), e soprattutto nel caso di applicazioni web potrebbero essere la scelta meno adatta. Per questo motivo, oggi UTF-8 è l'encoding diventato standard nel mondo Web, ed è consigliabile sviluppare le proprie applicazioni per gestire stringhe di byte codificate con questo codec.

Riassumendo,

Come visto, occorrono pochi minuti per apprendere le basi di Unicode. I concetti di base sono quelli. Bisognerebbe poi accennare al fatto che Unicode nasce per essere retrocompatibile con ASCII 7bit (i primi caratteri sono proprio quelli dell'ASCII), così come molti codec hanno come sottoinsieme i codepage più diffusi dell'ASCII esteso. Ma questi sono dettagli che oggi si possono ignorare senza problemi.

Successivamente alla pubblicazione di questo articolo, è nata una discussione sul forum programmazione di Ubuntu-it in cui mi hanno fatto notare che la rappresentazione interna di stringe in Java è UTF-16, come riportato qui. Tuttavia, ciò non toglie che è importante sapere sempre qual è la codifica dei propri dati in ingresso, e non affidarsi ai default encoding della particolare piattaforma.

Per concludere, qualche riferimento per approfondire. Il riferimento più citato della rete è senza ombra di dubbio:
http://www.joelonsoftware.com/articles/Unicode.html
Ai pythonisti consiglio vivamente la lettura di questo tutorial che io reputo il migliore:
http://boodebr.org/main/python/all-about-python-and-unicode
Se avete ereditato dei dati di cui non sapete nulla circa l'encoding adoperato, vi consiglio di dare uno sguardo al modulo chardet:
http://chardet.feedparser.org/
Infine, Wikipedia è un ottimo punto di partenza per le varie specifiche:
http://en.wikipedia.org/wiki/Unicode
http://en.wikipedia.org/wiki/UTF-8
http://en.wikipedia.org/wiki/ISO_8859-1
http://unicode.org/

Vi sarò grato se lascerete eventuali commenti e considerazioni. O magari mi direte se questo breve tutorial è stato utile o no.

Come dite?!?!? Non ho detto tutto??!? Ah già Non ho detto cosa significa l'ideogramma 简, che si legge 'jiǎn'. Ebbene significa 'semplice' (come Unicode, no?!?!), ma anche 'semplificare'; il suo codice Unicode è U+7B80 e la rappresentazione in UTF-8 è '\xe7\xae\x80', quindi 3 byte.

Infine, l’obiettivo n°2 è portare la mia amata attrezzatura fotografica e portare a casa un ‘pezzo’ della magnifica Firenze.

Ci vediamo presto.