Une exigence du produit que nous construisons est que ses points de terminaison d'URL soient sémantiquement significatifs pour les utilisateurs dans leur langue maternelle. Cela signifie que nous avons besoin d'URL codées en UTF-8 pour prendre en charge tous les alphabets sous le soleil. Nous ne souhaitons pas non plus fournir de documentation sur la configuration de l'installation pour chaque serveur d'application et chaque version que nous prenons en charge. Nous aimerions donc pouvoir exécuter ce code en interne. Cela pourrait ne pas être possible, car au moment où la servlet a reçu la requête, elle a été encodée par le serveur App, etc.La configuration de Tomcat 5.5 en UTF-8 code toutes les redirections sendRedirect()?
J'ai réussi à faire fonctionner cette fonction (pour mon premier cas d'utilisation avec ISO-Latin non Caractères ASCII US) en reconstituant les informations de chemin de la demande avec:
String pathInfoEncoded = new String(httpServletRequest.getPathInfo().getBytes(), "UTF-8");
puis d'analyser cela. Toutefois, cela ne fonctionne pas après la redirection d'un POST vers un GET en utilisant sendRedirect(). Le chemin de la requête est déjà échappé (donc ö est encodé en% F6) et ma méthode ci-dessus ne fonctionne pas.
Donc, je suppose que ma question est que je vais à ce sujet tout faux? Et si oui, quel est l'antidote à mon ignorance? :)
Mise à jour: trouvé la solution. Le problème est que l'API Servlet a un comportement étrange en ce qui concerne le codage d'URL avant d'envoyer la redirection. Vous devez coder URL (échapper les caractères UTF-8) AVANT d'appeler sendRedirect(). La méthode encodeRedirectURL() ne le fait pas pour vous.
Cette page discute: http://www.whirlycott.com/phil/2005/05/11/building-j2ee-web-applications-with-utf-8-support/