Problemi di carattere?

L’utente compila una form della vostra applicazione e i dati acquisiti non vengono visualizzati correttamente?

Il problema del titolo non è ovviamente un problema di carattere del nostro utente ma un problema di trasporto, salvataggio e visualizzazione dei caratteri inseriti! Ho usato volontariamente tre termini per descrivere il problema perchè sono tre le fasi in cui è importante gestire correttamente l’informazione.

1. Visualizzazione
   Un browser moderno è in grado di visualizzare correttamente il testo se la pagina HTML gli fornisce i sufficienti suggerimenti per utilizzare appropriati caratteri e la giusta codifica. Sebbene ci siano delle impostazioni selezionabili da browser, è più logico pensare che l’utente tipico visualizzi correttamente la pagina senza dover modificare certe impostazioni.
   Una pagina HTML corretta deve contenere quindi il seguente meta tag:

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

   Anche se le pagine sono generate utilizzando JSP è necessario indicare l’encoding utlizzato.In questo caso è possibile farlo utlizzando lo stesso meta tag oppure usando la directive @page<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

2. Trasporto
   Con trasporto intendo quella fase in cui il browser invia i dati (ad esempio la submission di una form) al server. Avendo aggiunto i meta tag o la direttiva @page, ora il browser conosce qual codifica utilizzare per inviare i dati.Allo stesso modo è necessario imporre al web server che processa i dati di usare la stessa codifica. Di default,ad esempio, Tomcat usa la codifica ISO-8859-1 e quindi nel nostro caso (UTF-8) potrebbero nascere dei problemi. Come risolvere?
   In Tomcat è possibile configurare il character-encoding tra le impostazioni del connector nel file server.xml con il parametro URIEncoding=”UTF-8″ , ma questa soluzione è fortemente dipendente dal web server (cosa succede se non usate Tomcat? ) ed inoltre l’ URIEncoding viene utilizzato solo nel caso in cui il metodo sia GET a non POST
   La soluzione migliore è quella di utilizzare il metodo setCharacterEncoding dell’oggetto di classe HttpServletRequest.
   Su questa strada ci viene incontro un filtro presente all’interno del framework Spring: CharacterEncodingFilter
   facilmente configurabile all’interno del web.xml in questo modo:<filter>
<filter-name>CharacterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
3. Salvataggio
   L’ultimo passo è quello di configurare il database in modo che possa salvare tutti i caratteri supportati dal browser e dal livello di business. In caso contrario, se si tenta di salvare del testo che contiene caratteri non presenti all’interno dell’insieme definito dal character encoding impostato, i dati vengono irrimediabilmente persi come mostrato in figura :
   

   Nel nostro caso abbiamo suggerito UTF-8 al browser e forzato UTF-8 nella gestione della request, quindi impostando ancora una volta UTF-8 nel database abbiamo la certezza che i dati non verranno persi nel tragitto browser-business-database sia in andata che al ritorno:

   

Alla prossima!