Le tag HTML dont tu parles passes au second plan par rapport à l'entête HTTP Content-Type, lorsque le browser reçoit la réponse. Si une telle entête est présente (et à ma connaissance tomcat la place) alors ton tag HTML sera ignoré.
En théorie, tu utilises Tomcat pour servir une servlet pure, ou du JSP. Le mieux est de servir ton contenu textuel en provenance de fichiers properties ou d'une base de données, pour pouvoir avoir des sources et JSP moins crades et plus maintenables, et la localisation des messages. Dans ce cas-là, ton contenu sort d'une String java, et la question est de permettre à tomcat de savoir quel codage utiliser pour les afficher. Tomcat se servira du ContentType associé à l'objet HttpServletResponse. Plusieurs solutions :
- tu fais une servlet java pure (pas de JSP et pas d'HTML) dans ce cas-là utiliser response.setContentType( "text/html; charset=UTF-8" ); pour forcer le type (il est même possible que ce ne soit pas nécessaire dans ce cas-là - mais en général c'est utile, on verra plus loin pourquoi)
- tu fais du JSP ; dans ce cas-là utiliser <%@ page contentType="text/html;charset=UTF-8" language="java" %>
- tu mets du texte en dur dans du JSP ou de l'HTML ; dans le premier cas utilise la directive page de la ligne précédente pour préciser le charset dans lequel est encodé ton texte ; dans le deuxième cas, aucune idée :) mais tu peux très bien utiliser un JSP avec seulement cette directive et tout le reste en HTML pur
La problématique principale pour l'internationalisation avec tomcat est la façon dont tu vas recevoir les données entrées par les utilisateurs. Il s'agit des données passées par HTTP GET (URL avec paramètres derrière) ou HTTP POST (formulaire). Le problème est dans le premier cas qu'il n'existe pas de standard pour indiquer le codage des caractères (qui sont eux-même URL-encodés bien sûr), dans le second cas que les navigateurs n'envoient pas dans l'entête Content-Type le codage utilisé. D'après ce que j'avais vu dans le bugzilla de Mozilla (mais je ne retrouve plus la référence), ils avaient corrigé ce "problème" mais ça en créait trop de nouveaux dans les serveurs web existants.
La meilleure solution consiste donc à faire en sorte d'être raisonnablement sûr que le navigateur enverra les informations dans un codage déterminé.
La solution la plus simple à mettre en oeuvre et de tout faire en UTF-8. Ça permet une internationalisation sans soucis et c'est bien supporté par les navigateurs (même la passoire bien connue qui sert de navigateur dominant actuellement).
Dans le cas des informations reçues par HTTP GET, en général il s'agit d'un lien que tu auras créé dynamiquement dans ta servlet ou ton JSP. Assure-toi de le créer en UTF-8, et ajoute useBodyEncodingForURI="true" dans les attributs du Connector de ton server.xml (à partir de tomcat 5).
Dans le cas des informations reçues par HTTP POST, il s'agit de ce que l'utilisateur aura entré dans son navigateur. Comme je le disais plus haut, les navigateurs n'envoient pas le codage utilisé, donc lorsque tomcat va recevoir ces informations, il ne pourra pas savoir comment décoder les caractères - et par défaut il utilise ISO-8859-1 (c'est dans la norme des servlets).
Envoi (point de vue du navigateur)
Pour être sûr que le navigateur enverra les informations en UTF-8, en théorie c'est vers l'attribut accept-charset="UTF-8" de l'élément form qu'il faudrait se tourner, mais l'implémentation actuelle des navigateurs pousse à une autre solution : faire en sorte que la page qui contenait le formulaire soit elle-même codée en UTF-8. Pour ce faire, voir plus haut - response.setContentType( "text/html; charset=UTF-8" ); et <%@ page contentType="text/html;charset=UTF-8" language="java" %> sont la meilleure solution.
Réception (point de vue de ta servlet)
Ensuite, comme je le disais plus haut, il faut s'assurer que tomcat décodera les informations reçues avec le codage UTF-8. Le plus simple est de forcer le codage de HttpServletRequest : request.setCharacterEncoding( "UTF-8" );. Pour ne pas dupliquer cela dans tous les JSP et servlets, le mieux est d'utiliser un Filter, par exemple SetCharacterEncodingFilter.java qui est disponible en standard avec tomcat.
# meuh
Posté par gc . En réponse au message Serveur Tomcat : problème d'accents. Évalué à 6.
En théorie, tu utilises Tomcat pour servir une servlet pure, ou du JSP. Le mieux est de servir ton contenu textuel en provenance de fichiers properties ou d'une base de données, pour pouvoir avoir des sources et JSP moins crades et plus maintenables, et la localisation des messages. Dans ce cas-là, ton contenu sort d'une String java, et la question est de permettre à tomcat de savoir quel codage utiliser pour les afficher. Tomcat se servira du ContentType associé à l'objet HttpServletResponse. Plusieurs solutions :
- tu fais une servlet java pure (pas de JSP et pas d'HTML) dans ce cas-là utiliser response.setContentType( "text/html; charset=UTF-8" ); pour forcer le type (il est même possible que ce ne soit pas nécessaire dans ce cas-là - mais en général c'est utile, on verra plus loin pourquoi)
- tu fais du JSP ; dans ce cas-là utiliser <%@ page contentType="text/html;charset=UTF-8" language="java" %>
- tu mets du texte en dur dans du JSP ou de l'HTML ; dans le premier cas utilise la directive page de la ligne précédente pour préciser le charset dans lequel est encodé ton texte ; dans le deuxième cas, aucune idée :) mais tu peux très bien utiliser un JSP avec seulement cette directive et tout le reste en HTML pur
La problématique principale pour l'internationalisation avec tomcat est la façon dont tu vas recevoir les données entrées par les utilisateurs. Il s'agit des données passées par HTTP GET (URL avec paramètres derrière) ou HTTP POST (formulaire). Le problème est dans le premier cas qu'il n'existe pas de standard pour indiquer le codage des caractères (qui sont eux-même URL-encodés bien sûr), dans le second cas que les navigateurs n'envoient pas dans l'entête Content-Type le codage utilisé. D'après ce que j'avais vu dans le bugzilla de Mozilla (mais je ne retrouve plus la référence), ils avaient corrigé ce "problème" mais ça en créait trop de nouveaux dans les serveurs web existants.
La meilleure solution consiste donc à faire en sorte d'être raisonnablement sûr que le navigateur enverra les informations dans un codage déterminé.
La solution la plus simple à mettre en oeuvre et de tout faire en UTF-8. Ça permet une internationalisation sans soucis et c'est bien supporté par les navigateurs (même la passoire bien connue qui sert de navigateur dominant actuellement).
Dans le cas des informations reçues par HTTP GET, en général il s'agit d'un lien que tu auras créé dynamiquement dans ta servlet ou ton JSP. Assure-toi de le créer en UTF-8, et ajoute useBodyEncodingForURI="true" dans les attributs du Connector de ton server.xml (à partir de tomcat 5).
Dans le cas des informations reçues par HTTP POST, il s'agit de ce que l'utilisateur aura entré dans son navigateur. Comme je le disais plus haut, les navigateurs n'envoient pas le codage utilisé, donc lorsque tomcat va recevoir ces informations, il ne pourra pas savoir comment décoder les caractères - et par défaut il utilise ISO-8859-1 (c'est dans la norme des servlets).
Envoi (point de vue du navigateur)
Pour être sûr que le navigateur enverra les informations en UTF-8, en théorie c'est vers l'attribut accept-charset="UTF-8" de l'élément form qu'il faudrait se tourner, mais l'implémentation actuelle des navigateurs pousse à une autre solution : faire en sorte que la page qui contenait le formulaire soit elle-même codée en UTF-8. Pour ce faire, voir plus haut - response.setContentType( "text/html; charset=UTF-8" ); et <%@ page contentType="text/html;charset=UTF-8" language="java" %> sont la meilleure solution.
Réception (point de vue de ta servlet)
Ensuite, comme je le disais plus haut, il faut s'assurer que tomcat décodera les informations reçues avec le codage UTF-8. Le plus simple est de forcer le codage de HttpServletRequest : request.setCharacterEncoding( "UTF-8" );. Pour ne pas dupliquer cela dans tous les JSP et servlets, le mieux est d'utiliser un Filter, par exemple SetCharacterEncodingFilter.java qui est disponible en standard avec tomcat.
En espérant t'avoir été agréable.