2010-06-23 4 views
1

Mon application écrit beaucoup de données XML, et au hasard la dernière ligne du morceau de code suivant:Random TransformerException, comment le résoudre?

// Prepare the DOM document for writing 
Source source = new DOMSource(node); 

// Prepare the output stream 
Result result = new StreamResult(stream); 

// Write the DOM document to the file 
Transformer xformer = TransformerFactory.newInstance().newTransformer(); 
xformer.transform(source, result); 

..throws ..

javax.xml.transform.TransformerException: java.io.IOException: Detected invalid substitute UTF-16: da89 4f ? 

(en plus, je ne sais pas pourquoi, mais cette exception est la seule soulevée par le vm dans ma langue, le portugais, comme "Detectado substituto UTF-16 inválido", je l'ai traduit en "substitut UTF-16 invalide détecté")

Un autre étrange chose est que j'utilise UTF-8, pas UTF-16, dans mes textes, je Je l'ai vérifié. Et, je crois que si l'UTF était le problème, il ne causerait pas d'exception au hasard, car je reçois la même quantité de texte à transformer en XML.

Cette exception est difficile à reproduire car elle ne se produit pas toujours et se produit lors de la transformation de nombreuses données en XML.

Une idée de ce qui se passe ici?

+0

Cela ne se produit-il pas même si vous transformez le même document plusieurs fois? –

+0

utf-16 est utilisé en interne par java, un caractère est également un entier 16bit non signé. Quelque part dans votre source, il doit y avoir un personnage qui n'a pas de substitut pour cela. Java 1.4 utilise également la version 3.0 de la norme Unicode, 1.3 utilise la version 2.1. Ces versions ne supportent généralement pas les caractères supplémentaires. Depuis 1.5 il devrait être supporté puis la version 4 est utilisée. Et générez-vous la source dans votre application ou provient-elle de fichiers externes? – Redlab

+0

J'avais un problème similaire (bien que différent erreur) chaque fois que j'ai commencé mon application. à partir de la console (script shell), mais aucun problème quand je l'ai lancé à partir d'Eclipse. Commencez-vous l'application. de la même manière à chaque fois? –

Répondre

0

La solution de contournement que je pourrais penser est que le programme ré-exécuter l'action en cas d'échec. Comme il est difficile à reproduire, il ne devrait jamais se produire deux fois de suite.

+0

Avez-vous connecté toutes les fois où il échoue? Si ce n'est pas le cas, vous devez configurer un enregistreur pour se connecter en cas d'échec et indiquer à quoi ressemblent les données XML. Vous pouvez ensuite comparer cela à ceux qui travaillent. – xil3

+0

@ xil3 bon point. Pour moi, comme j'utilisais la même entrée, on dirait qu'il n'y a pas de différence, mais la vôtre peut être une bonne idée ... il doit y avoir une différence quelque part .. De toute façon, je ne travaille plus sur ce projet .. reste avec cette solution de contournement comme solution. –

0

Construisez votre source à partir d'un flux d'entrée, pas d'un lecteur, et laissez l'analyseur XML déterminer le jeu de caractères.

+0

Je ne suis pas sûr si je comprends, j'ai mis à jour mon code source dans la question. Comme vous pouvez le voir, je construis la source en utilisant DMOSource (Node). Si vous voulez dire le fichier source du texte, il est en cours de construction en utilisant un flux d'entrée. –