web-dev-qa-db-fra.com

Transmission de paramètres de requête sous forme de chaînes codées UTF-8

Je crée une page de connexion simple et je souhaite transmettre les paramètres de connexion et de mot de passe sous forme de chaînes codées UTF-8. Comme vous pouvez le voir dans le code ci-dessous, la première ligne correspond à l'emplacement où je règle l'encodage sur UTF-8, mais il semble que cela soit inutile car cela ne fonctionne pas. Lorsque j'utilise les paramètres de connexion et de mot de passe avec des accents, la page de résultat reçoit des caractères étranges.

Comment définir le codage de caractères correctement d’une manière qui fonctionne dans tous les navigateurs?

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>My Page</title>
    </head>

    <body>
        <h1>Welcome to My Page</h1>

        <form name="login" action="login.jsp" method="POST">
            Login:<br/>
            <input type="text" name="login" value="" /><br/>
            Password:<br/>
            <input type="password" name="password" value="" /><br/>
            <br/>
            <input type="submit" value="Login" /><br/>
        </form>

    </body>
</html>
jspservletsutf-8character-encoding
26
ceklock

pageEncoding définit uniquement le codage du caractère de la réponse et l'attribut charset de l'en-tête HTTP Content-Type. Fondamentalement, il dit au serveur de décoder les caractères produits par JSP en UTF-8 avant de les envoyer au client et l'en-tête indique au client de les encoder à l'aide de UTF-8 et de les utiliser également à renvoyer au serveur. La valeur par défaut de contentType est déjà text/html. Par conséquent, ci-dessous est suffisant:

<%@page pageEncoding="UTF-8"%>

La balise méta HTML est ignorée lorsque la page est exposée via HTTP. Il n'a été utilisé que lorsque la page est enregistrée par le client en tant que fichier HTML sur le système de disques local et que then est ouvert par un file:// URI dans le navigateur.

Dans votre cas particulier, le codage du corps de la requête HTTP n'a apparemment pas été défini sur UTF-8. Le codage du corps de la demande doit être défini par ServletRequest#setCharacterEncoding() dans le servlet ou par un filtre avant, le premier appel de request.getXxx() étant effectué dans un servlet ou un filtre impliqué dans la demande.

request.setCharacterEncoding("UTF-8");
String login = request.getParameter("login");
String password = request.getParameter("password");
// ...

Voir également:

48
BalusC

L'appel de ServletRequest # setCharacterEncoding () échouera encore dans certains cas.

Si votre conteneur respecte scrupuleusement les spécifications de servlet (comme le fait Tomcat), il interprétera par défaut les paramètres de publication comme ISO-8859-1. Cela risquerait de brouiller les caractères UTF-8 (tels que le japonais dans le cas que j'ai décrit précédemment) avant qu'ils n'atteignent votre code, en particulier si vous disposez d'un filtre de servlet qui inspecte les paramètres de la requête avec getParameter() ou getParameters(). Ces deux méthodes forcent le décodage des paramètres, et le décodage n’est effectué qu’une fois. 

Voici un lien pour savoir comment contourner cela dans Tomcat si vous avez des filtres qui examinent les paramètres de requête. Les gens voudront vérifier la documentation pour leur conteneur particulier.

http://wiki.Apache.org/Tomcat/FAQ/CharacterEncoding#Q1

Le bit clé de cela est:

Ajouter

useBodyEncodingForURI="true" URIEncoding="UTF-8"

à l'élément Context dans le fichier server.xml de Tomcat et ajoutez

  <filter>
    <filter-name>Character Encoding Filter</filter-name>
    <filter-class>org.Apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
    <init-param>
      <param-name>encoding</param-name>
      <param-value>UTF-8</param-value>
    </init-param>
  </filter>
  <filter-mapping>
    <filter-name>Character Encoding Filter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

comme auparavant, tout filtre qui appelle getParameter () ou getParameters () dans web.xml. J'ai constaté que, bien que le lien ci-dessus donne l'impression que les deux attributs de l'élément context étaient des alternatives, celui-ci, useBodyEncodingForURI, est absolument nécessaire ou Tomcat ne définit pas l'encodage de la chaîne de requête. De Request.Java dans Tomcat 7.0.42:

boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
if (enc != null) {
    parameters.setEncoding(enc);
    if (useBodyEncodingForURI) {
        parameters.setQueryStringEncoding(enc);
    }
} else {
    parameters.setEncoding
        (org.Apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
    if (useBodyEncodingForURI) {
        parameters.setQueryStringEncoding
            (org.Apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
    }
}
5
Gus

Le problème dépend du serveur d’application utilisé. Même les pages sont correctement définies, par exemple. Dans UTF8, la tentative visant à obtenir le paramètre sous la forme correcte (selon la langue attendue) ne donne pas de bons résultats, c’est-à-dire que request.getParameter (...) renvoie des caractères non attendus, car la page de code par défaut pour les paramètres est généralement 8859-1. Cela signifie que la page de code pour les paramètres est indépendante de la page de code de la page JSP et que la page de code par défaut pour les paramètres influence le résultat. La meilleure description que j'ai trouvée est la suivante: [1]: http://docs.cksource.com/CKFinder_2.x/Developers_Guide/Java/Configuration/URI_Encoding . Sur certains serveurs d'applications "request.setCharacterEncoding (...)" n'a aucun effet. Vous devez définir le codage des paramètres dans le descripteur. Les plus compliqués sont JBoss, Apache Tomcat, au centre est Glassfish. Mieux vaut WebLogic, le meilleur est Jetty (UTF-8 est le paramètre par défaut). Dans mon cas, je dois créer le descripteur glassfish-web.xml et y placer une balise encodage de paramètres. Dans mon cas (GlassFish):

<glassfish-web-app error-url="">
  <!-- request.setCharacterEncoding("UTF-8") not functioning -->
  <parameter-encoding default-charset="UTF-8" />
</glassfish-web-app>
2
hariprasad

Je suis tombé sur ce problème récemment et je n'ai pas trouvé de réponse ici. J'utilise Weblogic et la plupart des solutions sont pour Tomcat. 

Pour que l'encodage fonctionne avec Weblogic, vous devez le mettre dans votre weblogic.xml

<charset-params> 
    <input-charset> 
        <resource-path>/*</resource-path> 
        <Java-charset-name>UTF-8</Java-charset-name> 
    </input-charset> 
</charset-params>

Source: Documents weblogic.xml

NOTE: J'ai aussi ces options dans mes _Java_OPTIONS, mais je ne sais pas si elles sont nécessaires.

-Dweblogic.webservice.i18n.charset=utf-8 
-Dfile.encoding=UTF-8
1
Phar0x

Exemple de codage de caractères: 

<%@ page language="Java" pageEncoding="utf8" contentType="text/html;charset=UTF-8" %>
0
Mohankumar Dhayalan