Cerca nel blog

Loading

23 gennaio 2012

Da ASCII a UNICODE

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!

Chiunque può lasciare commenti su questo blog, ammesso che vengano rispettate due regole fondamentali: la buona educazione e il rispetto per gli altri.

Per commentare potete utilizzare diversi modi di autenticazione, da Google a Facebook e Twitter se non volete farvi un account su Disqus che resta sempre la nostra scelta consigliata.

Potete utilizzare tag HTML <b>, <i> e <a> per mettere in grassetto, in corsivo il testo ed inserire link ipertestuali come spiegato in questo tutorial. Per aggiungere un'immagine potete trascinarla dal vostro pc sopra lo spazio commenti.

A questo indirizzo trovate indicazioni su come ricevere notifiche via email sui nuovi commenti pubblicati.

9 commenti:

  1. credevo di aver scritto qualcosa di completamente noioso e invece dal numero di reazioni immediate anche su FB sembra che abbia svegliato un vespaio! 

    a me piace fare le cose nel modo più generale possibile e sono un amante delle exception! Ma dopo tutti i vari tentativi mi sono reso conto che di fatto la codifica universale non mi dava nessun vantaggio fin tanto che scriverò in inglese o in italiano! 

    alla fine credo di aver individuato il problema, ma forse tu mi puoi confermare se è vero o meno. Mi sembra di capire che PHP stori internamente le variabili stringa in iso-8859-1 per default. Ho provato a cambiarlo con iconv e metterlo utf-8, ma niente da fare. è possibile una cosa del genere? 

    RispondiElimina
  2. In un certo senso mi consola e mi fa rivalutare il mio "pareggio". Evidentemente non è un problema solo mio. Non avevo trovato i due documenti che citi e se avrò tempo proverò a leggerli nel dettaglio e magari (dico magari!) applicarli in un app di prova.

    Grazie!

    RispondiElimina
  3. Ci sono novità: il problema potrebbe non essere dalla mia parte, con l'interfacciamento tra i vari sistemi, ma un baco dalla parte di Google. 

    Qualche giorno fa avevo mandato una mail al gruppo di utenti di Fusion Tables per una richiesta d'aiuto e oggi salta fuori questa risposta:
    http://groups.google.com/group/fusion-tables-users-group/browse_thread/thread/67ecea32de6d5157

    E' il mio tempismo perfetto! Se adesso scopro che avevo fatto tutto giusto e il problema era con Google, mi girerebbero parecchio! 

    RispondiElimina
  4. Così da ignorante: i campi char o varchar nel db sono impostati unicode? Alcuni db come ms sql utilizzano tipi specifici 'w', per altri come oracle va impostato l'intero db. Alcuni provider tendono a trustare la codifica dal client, client che viene istanziato da un programma, che lui stesso ha una codifica di salvataggio, non mi sto riferendo alla specifica di header che identifica l'output del programma, ma alla codifica del file dello script.

    RispondiElimina
  5. tranquillo, io in fatto di ignoranza li batto tutti! 

    mysql è settato in modo che il db sia unicode, la tavola sia unicode e tutti i campi carattere sono unicode. In effetti da quello che ho potuto vedere, il database ritorna i dati nella codifica corretta, è da qualche altra parte che il PHP mi si mangia gli accento! 

    darò una ricontrollata... grazie!

    RispondiElimina
  6. interessante che senza dir beo abbiano parlato di bug... magari è dovuto ai nomi dei campi un po' artistici con spazi e altro  :DFammi capire: se riesci ad accedere a quel db in python puro, usando sempre stringhe unicode, cosa ti viene ritornato? Che se arriva già da li roba rotta o "double-encoded", il problema non è tuo di certo.
    Riguardo all'esempio che fai a loro: mi puoi mandare la sequenza di byte esatta che ti da quando mostra "varietÃ"? Vorrei capire se è effettivamente un double encoding o un encoding parziale o errato :-)

    RispondiElimina
  7. scusa il ritardo, ma è da ieri sera a mezzanotte che sono in un lavoro in urgenza per una serie di tre guasti consecutivi a tre apparati scorrelati e ne esco solo ora.

    allora io al database di google non accedo tramite le api, ma solo attraverso la loro interfaccia. di fatto lo script mi prepara un file (come quello che hai visto nel bug) e che poi io carico a mano su FT. E' una situazione temporanea, perché nel breve vorrei implementare anche la scrittura su FT con autenticazione oauth2.

    come ho scritto nel bug report, se il file lo apro con openoffice scegliendo la codifica utf8, non ci sono problemi di codifica,

    se ti va ne riparliamo domani dopo che avrò messo via qualche ora di sonno.

    RispondiElimina
  8. In risposta a questo commento di Roberto Maurizzi:

    oggi disqus è più discolo del solito e aveva marcato entrambi i tuoi commenti come spam! Adesso ti ho whitelisted

    Sono io il pazzo che corre dietro alle particelle... l'autore compare solo piccolino vicino alla data di pubblicazione in fondo al post. 

    Non mi stupirebbe che il baco potrebbe essere con python perché è solo di recente che è comparso il problema.

    FT lo si può usare anche via API ed è quello che ho intenzione di fare nel prox futuro.

    RispondiElimina
  9. Google ha aperto un ticket a riguardo:
    http://code.google.com/p/fusion-tables/issues/detail?id=1042

    Se volete metterci una stella...

    Forse varrebbe la pena di citare il baco di CSVReader ammesso che lo usino per la fare la decodifica. 

    RispondiElimina

Chiunque può lasciare commenti su questo blog, ammesso che vengano rispettate due regole fondamentali: la buona educazione e il rispetto per gli altri.

Per commentare potete utilizzare diversi modi di autenticazione, da Google a Facebook e Twitter se non volete farvi un account su Disqus che resta sempre la nostra scelta consigliata.

Potete utilizzare tag HTML <b>, <i> e <a> per mettere in grassetto, in corsivo il testo ed inserire link ipertestuali come spiegato in questo tutorial. Per aggiungere un'immagine potete trascinarla dal vostro pc sopra lo spazio commenti.

A questo indirizzo trovate indicazioni su come ricevere notifiche via email sui nuovi commenti pubblicati.

Related Posts Plugin for WordPress, Blogger...