Oggi giorno nessun programmatore può ignorare Unicode: con la diffusione di Internet e la pubblicazione dei contenuti via web è diventato impossibile non conoscere questo sistema di caratteri e, grazie al fatto che sono sempre di più i linguaggi di programmazione che lo trattano in maniera nativa, è diventato molto semplice poterlo adoperare nelle proprie applicazioni. Sicuro??!?!

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:

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:

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

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.

Fonte: www.carminenoviello.com

After you’re done reading, check out my follow-up to this post here.

Yea, yea, I know I said I was going to write more on pandas, but recently I’ve had a couple friends ask me if I could teach them how to scrape data. While they said they were able to find a ton of resources online, all assumed some level of knowledge already. Here’s my attempt at assuming a very minimal knowledge of programming.

Getting Setup

We’re going to be using Python 2.7, BeautifulSoup, and lxml. If you don’t already have Python 2.7, you’ll want to download the proper version for your OS here.

To check if you have Python 2.7 on OSX, open up Terminal and type python –version. You should see something like this:

Next, you’ll need to install BeautifulSoup. If you’re on OSX, you’ll already have setuptools installed. Let’s use it to install pip and use that for package management instead.

In Terminal, run sudo easy_install pip. You’ll be prompted for your password – type it in and let it run. Once that’s done, again in Terminal, sudo pip install BeautifulSoup4. Finally, you’ll need to install lxml.

A few scraping rules

Now that we have the packages we need, we can start scraping. But first, a couple of rules.

1. You should check a site’s terms and conditions before you scrape them. It’s their data and they likely have some rules to govern it.
2. Be nice – A computer will send web requests much quicker than a user can. Make sure you space out your requests a bit so that you don’t hammer the site’s server.
3. Scrapers break – Sites change their layout all the time. If that happens, be prepared to rewrite your code.
4. Web pages are inconsistent – There’s sometimes some manual clean up that has to happen even after you’ve gotten your data.

Finding your data

For this example, we’re going to use the Chicago Reader’s Best of 2011 list. Why? Because I think it’s a great example of terrible data presentation on the web. Go ahead and browse it for a bit.

All you want to see is a list of the category, winner, and maybe the runners-up, right? But you have to continuously click link upon link, slowly navigating your way through the list.

Hopefully in your clicking you noticed the important thing though – all the pages are structured the same.

Planning your code

In looking at the Food and Drink section of the Best of 2011 list, we see that all the categories are a link. Each of those links has the winner, maybe some information about the winner (like an address), and the runners-up. It’s probably a good idea to break these things into separate functions in our code.

To start, we need to take a look at the HTML that displays these categories. If you’re in Chrome or Firefox, highlight “Readers’ Poll Winners”, right-click, and select Inspect Element.

This opens up the browser’s Developer Tools (in Firefox, you might now have to click the HTML button on the right side of the developer pane to fully show it). Now we’ll be able to see the page layout. The browser has brought us directly to the piece of HTML that’s used to display the “Readers’ Poll Winners” <dt> element.

This seems to be the area of code where there’s going to be some consistency in how the category links are displayed. See that <dl> just above our “Readers’ Poll Winners” line? If you mouse over that line in your browser’s dev tools, you’ll notice that it highlights the entire section of category links we want. And every category link is within a <dd> element. Perfect! Let’s get all of them.

Our first function – getting the category links

Now that we know we know the <dl> section holds all the links we want, let’s write some code to find that section, and then grab all of the links within the <dd> elements of that section.

from bs4 import BeautifulSoup
from urllib2 import urlopen

BASE_URL = "http://www.chicagoreader.com"

def get_category_links(section_url):
    html = urlopen(section_url).read()
    soup = BeautifulSoup(html, "lxml")
    boccat = soup.find("dl", "boccat")
    category_links = [BASE_URL + dd.a["href"] for dd in boccat.findAll("dd")]
    return category_links

Hopefully this code is relatively easy to follow, but if not, here’s what we’re doing:

1. Loading the urlopen function from the urllib2 library into our local namespace.
2. Loading the BeautifulSoup class from the bs4 (BeautifulSoup4) library into our local namespace.
3. Setting a variable named BASE_URL to “http://www.chicagoreader.com”. We do this because the links used through the site are relative – meaning they do not include the base domain. In order to store our links properly, we need to concatenate the base domain with each relative link.
4. Define a function named get_category_links.
   1. The function requires a parameter of section_url. In this example, we’re going to use the Food and Drink section of the BOC list, however we could use a different section URL – for instance, the City Life section’s URL. We’re able to create just one generic function because each section page is structured the same.
   2. Open the section_url and read it in the html object.
   3. Create an object called soup based on the BeautifulSoup class. The soup object is an instance of the BeautifulSoup class. It is initialized with the html object and parsed with lxml.
   4. In our BeautifulSoup instance (which we called soup), find the <dl> element with a class of “boccat” and store that section in a variable called boccat.
   5. This is a list comprehension. For every <dd> element found within our boccat variable, we’re getting the href of its <a> element (our category links) and concatenating on our BASE_URL to make it a complete link. All of these links are being stored in a list called category_links. You could also write this line with a for loop, but I prefer a list comprehension here because of its simplicity.
   6. Finally, our function returns the category_links list that we created on the previous line.

Our second function – getting the category, winner, and runners-up

Now that we have our list of category links, we’d better start going through them to get our winners and runners-up. Let’s figure out which elements contain the parts we care about.

If we look at the Best Chef category, we can see that our category is in <h1>. Shortly after that, we find our winner and runners-up stored in <h2> and <h2>, respectively.

Let’s write some code to get all of them.

def get_category_winner(category_url):
    html = urlopen(category_url).read()
    soup = BeautifulSoup(html, "lxml")
    category = soup.find("h1", "headline").string
    winner = [h2.string for h2 in soup.findAll("h2", "boc1")]
    runners_up = [h2.string for h2 in soup.findAll("h2", "boc2")]
    return {"category": category,
            "category_url": category_url,
            "winner": winner,
            "runners_up": runners_up}

It’s very similar to our last function, but let’s walk through it anyway.

1. Define a function called get_category_winner. It requires a category_url.
2. Lines two and three are actually exactly the same as before – we’ll come back to this in the next section.
3. Find the string within the <h1> element and store it in a variable named category.
4. Another list comprehension – store the string within every <h2> element in a list called winner. But shouldn’t there be only one winner? You’d think that, but some have multiple (e.g. Best Bang for your Buck).
5. Same as the previous line, but this time we’re getting the runners-up.
6. Finally, return a dictionary with our data.

DRY – Don’t Repeat Yourself

As mentioned in the previous section, lines two and three of our second function mirror lines in our first function.

Imagine a scenario where we want to change the parser we’re passing into our BeautifulSoup instance (in this case, lxml). With the way we’ve currently written our code, we’d have to make that change in two places. Now imagine you’ve written many more functions to scrape this data – maybe one to get addresses and another to get paragraphs of text about the winner – you’ve likely repeated those same two lines of code in these functions and you now have to remember to make changes in four different places. That’s not ideal.

A good principle in writing code is DRY – Don’t Repeat Yourself. When you notice that you’ve written the same lines of code a couple times throughout your script, it’s probably a good idea to step back and think if there’s a better way to structure that piece.

In our case, we’re going to write another function to simply process a URL and return a BeautifulSoup instance. We can then call this function in our other functions instead of duplicating our logic.

def make_soup(url):
    html = urlopen(url).read()
    return BeautifulSoup(html, "lxml")

We’ll have to change our other functions a bit now, but it’s pretty minor – we just need to replace our duplicated lines with the following:

soup = make_soup(url) # where url is the url we're passing into the original function

Putting it all together

Now that we have our main functions written, we can write a script to output the data however we’d like. Want to write to a CSV file? Check out Python’s DictWriter class. Storing the data in a database? Check out the sqlite3 or other various database libraries. While both tasks are somewhat outside of my intentions for this post, if there’s interest, let me know in the comments and I’d be happy to write more.

Hopefully you found this post useful. I’ve put a final example script in this gist.

Fonte: gregreda.com