Discussion :

[fedfil]

Bonjour,

Je rencontre des difficultés à générer un fichier plat contenant à partir d'une String contenant le fameux caractère "oe".

J'ai essayé plusieurs encodings et aucun ne semble fonctionné.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

body.getBytes("ISO-8859-1")

transforme le caractère en "?"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

body.getBytes("ISO-8859-15")

transforme le caractère en "½"

Une idée ?

Merci de votre aide!

[Logan Mauzaize]

Si tu as un "?" c'est que l'encoding ne gère pas ce caractère.

Si tu as autre chose c'est que tu relis pas avec le même encoding.

[adiGuba]

Salut,


Le "ISO-8859-15" comporte bien ce caractère.
Tu as soit un problème d'affichage soit un problème de lecture de "body"...


a++

[fedfil]

En effet, le caractère 1/2 en 8859-1 a le même encoding que l'oe dans le 88-59-15 (http://en.wikipedia.org/wiki/ISO/IEC_8859-15)

Donc, y a un hic dans le code.
Pour plus d'information, le fichier est généré sous un serveur weblogic 8.1 avec un encoding en ISO-8859-1 (paramètre java: -Dfile.encoding=ISO-8859).

Je reçois la donnée en webservices et je l'utilise pour l'afficher sur une page web (je gère le caractère en le transformant en HTML) et pour générer un fichier CSV via l'algo suivant : String Webservices -> StringBuffer -> Bytes.
Le seul endroit où je ne maitrise pas l'encoding est l'utilisation du StringBuffer.

Une idée ?

[thelvin]

EJe reçois la donnée en webservices et je l'utilise pour l'afficher sur une page web (je gère le caractère en le transformant en HTML) et pour générer un fichier CSV via l'algo suivant : String Webservices -> StringBuffer -> Bytes.
Le seul endroit où je ne maitrise pas l'encoding est l'utilisation du StringBuffer.

Je ne sais pas ce que c'est que String Webservice.
Mais un StringBuffer n'a pas d'encoding et donc il n'y a pas à en gérer à ce niveau-là.
A priori, un truc qui s'appelle "String Webservice" ne devrait pas avoir d'encoding non plus. En Java, normalement pour que quelque chose s'appelle en String, il doit être basé sur String, donc pas d'encodage.

Moi je dis, il faudrait creuser plus :
- Quels sont les octets effectivement reçus du webservice ? Sont-ils capables de représenter le œ, et dans quel encodage ? Utiliser un sniffer réseau genre wireshark si nécessaire. Si c'est en HTTPS et qu'il est trop compliqué d'utiliser un sniffer, il va falloir, d'une manière ou d'une autre, faire que l'appli Java qui reçoit ces octets les enregistre quelque part. Pour consulter ensuite.

- Comment ces octets sont ensuite transformés en String ou StringBuffer ?
Il est obligatoire, pour ça, d'utiliser un encoding. Mais est-ce le bon qui est utilisé ? Comment est-ce décidé ? Est-ce indiqué par le protocole du webservice ? Est-ce configurable ? Est-ce un truc en dur, ou bien un encoding par défaut ?

[fedfil]

Bonjour,

Je n'ai pas été très clair.

Ce que j'appelle un objet String Webservices est un objet String d'un objet skeleton généré par Axis 1.2

Le webservices est correct car les caractères spéciaux sont gérés en HTML.
Je pense que l'erreur se situe au niveau du bidding géré par Axis qui se charge de transformer l'enveloppe en objet skeleton mais je n'arrive pas à modifer l'encoding de l'outil.

Bref, ce n'est pas être pas un problème "Général Java"

[thelvin]

Le webservices est correct car les caractères spéciaux sont gérés en HTML.

Mais encore ?

Si le protocole est correctement utilisé, Axis a très, très peu de chances de se tromper dans la transformation octets -> String.