utf-8 décodage en java

Je suis en train de passer des paramètres à partir d'un PHP de niveau intermédiaire à un java backend qui comprend J2EE. Je suis en train d'écrire le code du contrôleur en Groovy. Là, je suis en train de décoder un certain nombre de paramètres susceptibles de contenir des caractères internationaux.

Je suis vraiment surpris par les résultats de mon débogage ce problème jusqu'à maintenant, donc je voulais le partager avec vous dans l'espoir que quelqu'un sera en mesure de donner la bonne interprétation de mes résultats.

Pour le bien de mon petit test, le paramètre que je suis de passage est "déjeuner". Juste pour être sûr, le Système de..println("déjeuner") correctement me donne:

déjeuner

dans la console

Maintenant sont les suivantes char/dec et les valeurs hexadécimales de chaque caractère de la chaîne d'origine:

next char: d 100 64
next char: ? -61 c3
next char: ? -87 a9
next char: j 106 6a
next char: e 101 65
next char: u 117 75
next char: n 110 6e
next char: e 101 65
next char: r 114 72

noter que le c3a9 séquence UTF-8 est le souhaitait-de caractère: http://www.fileformat.info/info/unicode/char/00e9/index.htm

Maintenant, si j'essaie de lire cette chaîne comme une chaîne UTF-8, comme dans stmt.getBytes("UTF-8"), j'ai soudainement finir par avoir un de 11 octets de la séquence, comme suit:

64 c3 83 c2 a9 6a 65 75 6e 65 72

alors que stmt.getBytes("iso-8859-1") me donne 9 octets:

64 c3 a9 6a 65 75 6e 65 72

note le c3a9 séquence ici!

maintenant, si j'essaie de convertir le format UTF-8 séquence UTF-8, comme dans

new String(stmt.getBytes("UTF-8"), "UTF-8");

J'obtiens:

next char: d 100 64
next char: ? -61 c3
next char: ? -87 a9
next char: j 106 6a
next char: e 101 65
next char: u 117 75
next char: n 110 6e
next char: e 101 65
next char: r 114 72

note le c3a9 séquence

tout

new String(stmt.getBytes("iso-8859-1"), "UTF-8")

résultats dans:

next char: d 100 64
next char: ? -23 e9
next char: j 106 6a
next char: e 101 65
next char: u 117 75
next char: n 110 6e
next char: e 101 65
next char: r 114 72

note de la e9 qui en utf-8 (et ascii) est, encore une fois, le 'é' personnage que j'ai envie de.

Malheureusement, dans les deux cas, suis-je en terminant avec une bonne chaîne de caractères qui s'affichent comme la chaîne littérale "déjeuner". Curieusement, les séquences d'octets à la fois semblent corrects.

OriginalL'auteur user162346 | 2009-10-29

  1. 9

    Lorsque vous traitez avec des Cordes, rappelez-vous toujours: byte != char. Donc, dans votre premier exemple, vous avez le char c3, pas la byte c3 qui est une énorme différence: Le byte serait partie de l'UTF-8 de la séquence, mais le char est déjà Unicode. Ainsi, lorsque vous les convertir en UTF-8, les caractères Unicode c3 doit devenir le byte séquence c3 83.

    La question est donc: Comment vous êtes-vous à la Chaîne? Il doit y avoir un bug dans le code qui ne gère pas correctement codé en UTF-8 byte séquences.

    La raison pour laquelle ISO-8859-1 travaille habituellement, c'est que cet encodage ne modifie pas la char avec un point de code < 256 (c'est à dire quoi que ce soit entre 0 et 255), donc codé en UTF-8 byte séquences ne seront pas modifiés.

    Votre dernier exemple est également faux: La char e9 est é dans ISO-8859-1 et Unicode. En UTF-8, il n'est pas valide car il n'est pas un byte et depuis c'est la byte c3 préfixe est manquant. Cela dit, il représente correctement la chaîne Unicode que vous cherchez.

    Merci pour le très instructif réponse. De sorte qu'il se résume à la demande.getParameter() dans javax.servlet.http.HttpServletRequest de ne pas gérer correctement codé en UTF-8 séquences d'octets, non? J'ai appelé req.setCharacterEncoding("UTF-8"). Quelle solution de contournement possible suis-je laissé? Il n'est toujours pas clair pour moi comment je obtenir les données d'origine pour mes paramètres (ses octets, pas de caractères), donc je peux obtenir un peu non-buggy la Chaîne de mise en œuvre pour travailler sur la bonne UTF chaîne d'elle...
    Ma conjecture est que l'expéditeur code les données en UTF-8, mais ne parvient pas à régler correctement les en-têtes HTTP pour cela.
    Donc, assurez-vous que la partie PHP génère des pages web que de spécifier correctement de leur codage, en particulier dans les formes.
    Après cela, le code Java doit décoder correctement les données, sans corrections manuelles par vous.
    ok ... puis-je obtenir la "bonne réponse", alors? 🙂

    OriginalL'auteur Aaron Digulla

  2. 1

    Si vous commencez avec la Java Chaîne où "d\u00C3\u00A9jeuner".equals(stmt) puis les données sont déjà corrompu à ce stade.

    Java char n'est pas un C char. Un char en Java est en 16bits de large et contient de manière implicite UTF-16 des données codées. Essayez de stocker toutes les autres données codées en Java char/type de Chaîne est d'avoir des ennuis. Des données de caractère dans un autre codage doit être aussi byte de données.

    Si vous êtes à la lecture de la paramètre à l'aide de l'API servlet, alors il est probable que la requête HTTP contient l'incohérence ou l'insuffisance de l'encodage de l'information. Vérifiez le code d'appel et les en-têtes HTTP. Il est probable que le client est l'encodage des données UTF-8, mais la servlet est de décodage comme ISO-8859-1.

    OriginalL'auteur McDowell

  3. 0

    J'ai un problème très similaire, sauf que mon formulaire utilise "GET" demande pas une demande de "POST".

    Donc, mon URL est quelque chose comme: http://localhost:4502/form.jsp?query=d%C3%A9jeuner

    request.getCharacterEncoding() = ISO-8859-1
response.getCharacterEncoding() = UTF-8
request.getParameter("query") = déjeuner

    La HttpServletRequest utiliser UTF-8 pour décoder la demande de param (qui, de toute évidence, elle n'est pas) ou est-ce simplement une erreur de navigateur, car le navigateur ne définit pas de codage de caractères en-tête (qui encore une fois n'a pas beaucoup de sens parce que c'est pas de faire une requête post). Voici l'ensemble des en-têtes et les avis de l' %C3%A9 dans l'URL.

    http://localhost:4502/form.jsp?query=d%C3%A9juerne

GET /form.jsp?query=d%C3%A9juerne HTTP/1.1
Host: localhost:4502
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.17) Gecko/2010010604 Ubuntu/9.04 (jaunty) Firefox/3.0.17
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

    Ce problème, je vais avoir, c'est que j'ai fait copié et collé à la requête dans le formulaire de navigateur et mal codé. À la fois dans chrome et firefox.

    OriginalL'auteur marto

  4. 0

    Après quelques recherches, j'ai trouvé cette réponse

    Comment obtenir de l'UTF-8 Java webapps?.

    Il est tout au sujet de réglage URIEncoding="UTF-8" dans le connecteur tomcat.

    Maintenant à trouver comment faire cela dans le CMS que nous utilisons (CQ5/Jour).

    Salut, bienvenue à Stackoverflow! Merci de ne pas poster de questions que de réponses à d'autres questions! Ils vont se perdre dans le bruit et personne ne voulait répondre à votre question. Il vous suffit de poster une question en cliquant sur Ask Question bouton en haut à droite. Une fois fait cela, s'il vous plaît supprimer ce bruit à partir de cette rubrique.

    OriginalL'auteur marto