# Problematiche ricorrenti nello sviluppo di webapp 2/3: encoding

_Pubblicato il 18/09/2012_

![problematiche ricorrenti sviluppo web app encoding](https://www.gardainformatica.it/blog/sviluppo-software/problematiche-ricorrenti-sviluppo-web-app-encoding.jpg)

Dopo la gestione dell'[escaping](https://www.gardainformatica.it/blog/sviluppo-software/problematiche-ricorrenti-sviluppo-web-app-escaping.md "Problematiche ricorrenti nello sviluppo di webapp 1/3: escaping") vediamo la gestione dell'encoding.

Questo problema ha origini storiche e dipende dal fatto che, agli albori della computazione, quando le risorse erano limitate, si preferì individuare un sott'insieme di tutti i caratteri noti per poter dialogare con un computer, questo sott'insieme coincideva sostanzialmente con i caratteri dell'[alfabeto latino](http://it.wikipedia.org/wiki/Alfabeto_latino) i numeri e qualche altro carattere di utilità.

Questo insieme di caratteri o charset, noto come [ASCII](http://it.wikipedia.org/wiki/ASCII) è stato il charset di riferimento fino all'avvento di internet e all'aumento delle risorse a disposizione.

Oggi infatti ad una webapp multilingua viene richiesta la corretta gestione di un charset molto più esteso dell'ASCII, di un charset che contenga più o meno tutti gli alfabeti della terra: latino, arabo, ebraico, cinese, giapponese, ecc.

Questo charset noto come [UTF-8](http://it.wikipedia.org/wiki/UTF-8) è un superset dell'ASCII, questo significa che è retrocompatibile con l'ASCII, ma che è in grado di rappresentare anche i caratteri degli altri alfabeti.

Per fare ciò sostanzialmente si prevede l'espansione dinamica dell'occupazione di ogni singolo carattere: nel caso dell'ASCII i caratteri occupano 1 byte, nel caso di altri alfabeti possono arrivare ad occupare 4 byte ciascuno.

Come detto precedentemente mentre qualsiasi linguaggio, per ragioni storiche, gestisce nativamente il charset ASCII, ciò non è sempre vero per l'UTF-8.

Nel PHP, per esempio, c'è una libreria apposita per la gestione di stringhe multibyte come nel caso dell'UTF-8 e si chiama appunto [Multibyte String](http://it.php.net/manual/en/book.mbstring.php).

Questa libreria ripropone tutte le funzioni classiche per la gestione delle stringhe *strlen*, *strtolower*, *strtoupper*, *substr* ecc. in versione multibyte *mb\_strlen*, *mb\_strtolower*, *mb\_strtoupper*, *mb\_substr* ecc.

Ciò non è però sufficiente, infatti la corretta gestione dell'encoding interessa vari livelli della nostra webapp: dagli header HTTP, all'HTML, al PHP.

Per quanto riguarda gli **header HTTP** ci dobbiamo ricordare di indicare l'encoding attraverso la funzione [header](http://it.php.net/manual/en/function.header.php) del PHP e del parametro *Content-Type* come nell'esempio seguente:

```
header('Content-Type: text/html; charset=utf-8');
```

Nella sezione *head* dell'HTML dobbiamo specificare l'encoding della pagina con il *meta* seguente:

```
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
```

Nel PHP, oltre ad utilizzare la già citata libreria al posto di quella standard per le stringhe, dobbiamo specificare che l' *internal encoding* della nostra applicazione è UTF-8 utilizzando la funzione [mb\_internal\_encoding](http://it.php.net/manual/en/function.mb-internal-encoding.php)

```
mb_internal_encoding("UTF-8");
```

E infine anche gli stessi sorgenti PHP devono essere codificati in UTF-8 senza BOM.

Per sapere se una funzione PHP tratta correttamente il multibyte ci si può riferire al seguente articolo [Handling UTF-8 with PHP](http://www.phpwact.org/php/i18n/utf-8)

**Autore:** [Giovanni Chiodi](https://www.gardainformatica.it/blog/giovanni-chiodi.md) - Senior software developer con più di 16 anni di esperienza nello sviluppo di soluzioni web based, enterprise, su misura. Dal 2011 socio fondatore di Garda Informatica Snc condivide questa avventura col fratello Lorenzo.