In principio era l'ASCII, e l'ASCII era perfetto, tutto poteva essere fatto con l'ASCII e tutti erano felici di usarlo. E fu sera e fu mattina primo giorno.
Qualcuno disse: aggiungiamo i caratteri accentati. E così avvenne. I caratteri accentanti e tutti gli alfabeti delle lingue occidentali vennero aggiunti. L'ASCII esteso non era così perfetto, ma tutti sembravano più contenti. E fu sera e fu mattina secondo giorno.
Qualcuno disse: aggiungiamo il greco e il cirillico e anche tutti gli alfabeti dell'Europa orientale. E così avvenne. La codifica divenne multibyte, ma erano più gli scontenti dei contenti. E fu sera e fu mattina terzo giorno.
Qualcuno disse: aggiungiamo l'arabo, gli ideogrammi, il cinese, il giapponese, il coreano, il tailandese, l'indiano, le rune... Facciamo la codifica universale. E così avvenne. Nacque l'UNICODE, la codifica del tutto, non ci furono più lettere non rappresentabili da un computer, ma il prezzo da pagare non fu certo trascurabile. E fu sera e fu mattina quarto giorno.
Questo incipit biblico è per raccontarvi della sciagura apocalittica o se preferite dell'impresa vetero testamentaria in cui mi sono imbattuto nel week end e che solo una proverbiale pazienza di Giobbe mi ha permesso di non sfasciare il computer e passare i frammenti sotto uno schiacciasassi.
Sapete che stiamo raccogliendo i dati della contaminazione alimentare in Giappone nel dopo Fukushima, sapete anche che da qualche tempo sto facendo il porting dello script in python utilizzato fino ad adesso ed eseguito a mano con uno in PHP eseguito in modo automatico dal webserver dove risiede la webapplication. Ero già giunto nella fase terminale del debug/beta testing, lasciandomi solo qualche problemino ancora da risolvere che ritenevo di secondaria importanza.
L'applicazione, come tutte le applicazioni del mondo, è data dall'interazione di diversi ambiti, alcuni eseguiti a livello di server, altri a livello di browser e poi ci sono i data storage su alcuni databases, la maggior parte MySQL e quello grosso su Fusion Tables, il DB di Google. L'ultimo problema che mi ero lasciato da risolvere era che in un passaggio da un database all'altro andavo a perdere la giusta codifica dei caratteri accentati, in particolare della 'à' contenuta nella parola 'varietà' utilizzata per identificare un particolare tipo di alimento. Lo avevo classificato come un baco di seconda classe, perché convinto che mi fossi dimenticato da qualche parte di specificare la codifica del testo e in fondo non inficiava certo l'esecuzione della applicazione, anche se a nessuno piace vedere caratteri non propriamente decodificati.
Quando avevamo iniziato l'opera di inserimento dati, ci era sembrata una scelta scontata quella di usare UTF-8, ovvero una delle possibile implementazioni di UNICODE, che oltre a rappresentare tutti i caratteri europei può anche essere utilizzata per quelli giapponesi, qualora un giorno decidessimo di imparare gli ideogrammi.
Così mi armo di santa pazienza e comincio a controllare tutti i vari pezzi e le varie interazioni del codice. All'inizio faccio le cose in modo un po' superficiale, ma quando vedo che il risultato non arriva, ricomincio da capo in modo sistematico, come è giusto fare per risolvere i bug più noiosi. E fu sera e fu mattina e sono passati 4 giorni, diciamo 2 interi durante il week end e due nottate, quella precedente e quella successiva. E alla fine ho deciso che mi accontentavo di un pareggio, ovvero di avere lo script funzionante, rinunciando però alla codifica universale in cambio della codifica latina (ISO-8859-1). Infatti, nonostante i miei sforzi, le ricerche su google, i cento ed oltre tentativi, non sono riuscito a far digerire a tutti i componenti la codifica unicode.
Il pareggio suona un po' come una sconfitta, ma ci saranno momenti migliori in cui recuperare!
