Ne pas encoder et convertir de codage de la chaîne

Je dois analyser une Chaîne de caractères d'un objet Date en Java.
La chaîne-je obtenir suivant le modèle MMM d yyyy HH:mm:ss z avec des paramètres régionaux définis à French.

Le problème est quand la date est en février, août ou en décembre, suite à l'encodage des accents français. Par exemple, je reçois déc. 15 2011 16:55:38 CET pour le 15 décembre 2011.

Je ne peux pas changer la façon dont la chaîne est créé de sorte que j'ai à traiter avec le mauvais encodage de mon côté. Il semble que lors de la génération de la chaîne est mal codé (UTF-8 contenu encodé en ISO 8859-1) puis escapde.

Pour l'instant j'utilise :

stringFromXML = stringFromXML.replaceAll("é", "é");
stringFromXML = stringFromXML.replaceAll("û", "û");

Cela fonctionne parce que le seul accent en français mois sont é et û mais est-il une manière plus propre de ne pas encoder et convertir des caractères?

OriginalL'auteur YCI | 2012-02-06

  1. 10

    Vous avez besoin de deux étapes:

    1. Résoudre les références à des caractères numériques, par exemple, à l'aide de StringEscapeUtils comme suggéré par Andy:

      String unescaped = StringEscapeUtils.unescapeHtml(in);

    2. Correction de l'encodage par le traitement des caractères en UTF-8 unités de code:

      String out = new String(unescaped.getBytes("ISO-8859-1"), "UTF-8");
    Cette solution fonctionne sur mon ordinateur mais sur le serveur j'obtiens une exception Caused by: java.text.ParseException: Unparseable date: "ao�t 04 2011 16:55:38 CEST". Le correctif pour le codage de retour ao�t au lieu de août. Une idée d'où cela provient-il?
    Êtes-vous sûr que c'est le même?
    La chaîne est lue à partir d'un fichier XML. Quand j'ouvre ce fichier XML dans un éditeur de texte, l'encodage est identifié comme UTF-8 without BOM. J'ai lu la valeur du champ suivant : <wplc:field id="EffectiveDate">ao&#195;&#187;t 04 2011 16:55:38 CEST</wplc:field>. Sur mon ordinateur (Windows XP, java 1.6.0_11) la modification de la valeur de ao&#195;&#187;t à août à août. Sur le serveur (RedHat 5.4, java 1.6.0_21) la modification de la valeur de ao&#195;&#187;t à août à ao�t.
    Vous êtes sûr que c'est pas un résultat de la poursuite du traitement? Essayez d'imprimer les résultats de cette conversion en hexadécimal, pour écarter possible problèmes de sortie.
    Vous avez raison, j'ai des problèmes d'encodage de mon fichier journal! S'avère que le programme fonctionne uniquement lorsque le unescapeHTML est exécutée sans ré-encodage de la chaîne de new String(unescaped.getBytes("ISO-8859-1"), "UTF-8");. C'est un peu étrange, mais ça fonctionne... Merci pour votre aide!

    OriginalL'auteur axtavt

  2. 2

    Vous pouvez utiliser Apache Commons StringEscapeUtils pour ce faire, si vous n'avez pas l'esprit que la dépendance.

    De la JavaDoc pour StringEscapeUtils.unescapeHtml:

    Unescapes une chaîne de caractères contenant l'entité s'échappe d'une chaîne de caractères contenant
    l'effectif des caractères Unicode correspondant au échappe. Prend en charge
    HTML 4.0 entités.

    Par exemple, la chaîne "&lt;Fran&ccedil;ais&gt;" devient "<Français>"

    Il convient également de travailler avec des entités numériques que vous avez dans votre entrée.

    OriginalL'auteur Andy

  3. 2

    Juste au cas où quelqu'un d'autre est à la recherche pour la même solution que moi. J'ai essayé de décoder les caractères que j'ai reçu de okhttp (android) les requêtes comme:
    &#195; à Ã

    Donc, comme suggéré par @axtavt, j'ai utilisé StringEscapeUtils, mais pour ce faire j'ai donc ajouté cette dépendance à mon gradle:

    compile 'org.apache.commons:commons-lang3:3.4'

    Et le caractère fixe des questions par

    return StringEscapeUtils.unescapeHtml3(word);

    OriginalL'auteur Latrova