Discussion :

[TickerOpcvm]

Bonjour à tous,

Mon application reçoit des données XML signées (XMLDSig) et comportant des caractères accentués, de plusieurs sources différentes et son comportement lors de la vérification de la signature varie selon ces sources (bien entendu, s'il n'y a aucun caractère accentué, tout va bien ). Je m'explique :

Premier cas : les données XML sont fournies par une application externe C++ , m'assurant (mais je n'ai pas vu le code) que la chaine de caractères est encodée UTF-8, cette dernière étant construite à la volée. Si je veux que la vérification de signature fonctionne (calcul du digest, etc.), la chaine de caractères en entrée du Verifier doit être obtenue à partir de l'originale via :

Code :

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

xml_utf8 = new String(xml.getBytes(), "UTF-8");

Second cas : les données XML sont fournies par un client JAVA lisant un fichier XML depuis le disque (OS : Windows XP) grâce à (merci commons-io) :

Code :

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

textMsg = FileUtils.readFileToString(unFichier, "UTF-8");

Si je veux que la verification soit OK, alors je dois construire ma chaine comme suit :

Code :

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

1
2
3
xml_utf8 = new String(xml.getBytes("UTF-8"), "UTF-8");
ou
xml_iso-8859-15 = new String(xml.getBytes(), "ISO-8859-15");

Mon fichier XML en entrée semble être encodé UTF-8 :
- Notepad++ l'indique dans son menu 'Format' ;
- UltraEdit indique en hexa que mes caractères accentués sont ceux attendus en UTF-8 hex, soit C3A9 pour é par exemple. De plus, il m'indique que le Byte Order Mark (BOM) au commencement du fichier est celui attendu : EF BB BF (cf. http://www.w3.org/TR/2004/REC-xml-20...ng-no-ext-info)

Il y a surement une étape que je fais mal et qui introduit un peu d'ISO mais je ne vois pas comment la découvrir
Quelqu'un peut-il m'aider ?

D'avance merci
Ticker

[djsnipe]

Tiens, pourquoi n'utilises-tu pas un parsing XML à base de DOM ou SAX ? Il suffit de préciser d'entrée de jeu l'encoding du fichier s'il n'est pas détecté automatiquement ou bien si tu veux le forcer. Evite de manipuler un XML sous la forme d'une String.
Ensuite, ben il n'y a plus rien à faire. Si le fichier est mal encodé, tu auras une exception relative à l'encoding lors du parsing.

[adiGuba]

Salut,

Ceci est une aberration :

Code :

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

xml_utf8 = new String(xml.getBytes(), "UTF-8");

En Java une String est TOUJOURS encodé en UTF-16 en interne, et les conversions ne doivent avoir lieu que lors des entrée/sorties (dans un fichier par exemple)

Et comme getBytes() utilises l'encodage par défaut, il est probable que tu transformes une String en un encodage différents d'UTF-8 pour l'interpréter ensuite en UTF-8


Bref : il faut spécifier l'encodage uniquement lors de la lecture/écriture...

a++

[TickerOpcvm]

Tiens, pourquoi n'utilises-tu pas un parsing XML à base de DOM ou SAX ?

Tout simplement pour des questions de vitesse et d'encombrement mémoire : je reçois une chaine de caractères que je vais transformer en objets JAVA via Castor après avoir déchiffré (XMLEnc) et vérifié (XMLDSig). L'étape DOM me semble de trop, mais si c'est le seul moyen de contrôler l'encodage...

En Java une String est TOUJOURS encodé en UTF-16 en interne, et les conversions ne doivent avoir lieu que lors des entrée/sorties (dans un fichier par exemple).

Et comme getBytes() utilises l'encodage par défaut, il est probable que tu transformes une String en un encodage différents d'UTF-8 pour l'interpréter ensuite en UTF-8

J'entends bien, mais il s'agit d'une chaine de caractères UTF-8 envoyée via WebServices depuis une application C++. L'aberration dont tu parles est le seul moyen pour que cette chaine qui n'a pas été modifiée par une source extérieure, donne le même Digest que celui calculé par l'appli C++
Par contre, effectivement, avec un client JAVA lisant un fichier sur le disque, pas besoin de quoi que ce soit pour une vérification OK, je peux verifier directement la chaine fournie...

J'aimerais bien savoir comment faire fonctionner les deux en même temps

Ticker

[dingoth]

Comment accèdes-tu aux données transmises par le C++ ?

[dingoth]

Comment accèdes-tu aux données transmises par le C++ ?

Désolé d'insister, mais je crois que le coeur du problème réside là. Pourrais-tu répondre ?

[TickerOpcvm]

Désolé dingoth !

En fait, l'appli C++ m'envoie une chaine de caractères théoriquement UTF-8 via WebServices sur mon appli JAVA. Il semblerait que le framework utilisé pour la génération des classes soit gSOAP...

[djsnipe]

Tout simplement pour des questions de vitesse et d'encombrement mémoire : je reçois une chaine de caractères que je vais transformer en objets JAVA via Castor après avoir déchiffré (XMLEnc) et vérifié (XMLDSig). L'étape DOM me semble de trop, mais si c'est le seul moyen de contrôler l'encodage...

Ouf, tu utilises Castor, donc SAX qui je me souviens bien. Mais ce qui me semble étonnant c'est de passer par l'étape String. Le WebService renvoi un XML, pas directement une String, soit attaché au flux de transport, soit dans un fichier attaché. C'est directement ce flux qu'il faut utiliser et éviter si possible de tout convertir en String puis en objets Java, ce qui est de mon point de vue inutile. Mais je ne connais pas XMLEnc et XMLDSig ni leur intégration à un processus unique de parsing XML -> Java.

[TickerOpcvm]

Ouf, tu utilises Castor, donc SAX qui je me souviens bien. Mais ce qui me semble étonnant c'est de passer par l'étape String. Le WebService renvoi un XML, pas directement une String, soit attaché au flux de transport, soit dans un fichier attaché. C'est directement ce flux qu'il faut utiliser et éviter si possible de tout convertir en String puis en objets Java, ce qui est de mon point de vue inutile. Mais je ne connais pas XMLEnc et XMLDSig ni leur intégration à un processus unique de parsing XML -> Java.

En fait, j'ai de fortes contraintes de performances et j'ai fait au plus simple/rapide : manipuler des String pour les étapes de signature/chiffrement me fait gagner du temps. Surtout que j'ai reecrit ces dernieres pour gagner en vitesse. Par conséquent, le service exposé prend String en paramètre et non pas Document. Ce probleme de caractères accentués va peut-etre me contraindre a modifier cela, mais je dois faire des benchs avant tout.

D'autre part, ce qui m'intéresse, ce sont les données transportées et pas la structure du XML en lui-même. Je dois pouvoir accepter une multitude de schémas différents transportant les mêmes données pour les diriger vers le même traitement. En cela, Castor et son mapping facilitent les choses Je suis donc content avec mes String (sans jeu de mot)...