[java - xml] Parser sous window puis unix
Résolu
kij_82
Messages postés
4089
Date d'inscription
Statut
Contributeur
Dernière intervention
-
kij_82 Messages postés 4089 Date d'inscription Statut Contributeur Dernière intervention -
kij_82 Messages postés 4089 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour à tous,
J'ai actuellement le problème suivant lorsque j'exécute mon programme java sous Aix.
Mon prog est sensé parser un fichier XML pour standardiser ses informations. Lorsque mon prog tourne sous Window (mon poste de dev), rien d'anormal, les valeurs des tags sont bien retrouvées et standardisée.
Seulement lorsque ce même programme est installé sous AIX, certaines valeurs de tag ne sont pas "retrouvée" alors qu'elle sont présente dans le fichier XML en entrée... je ne comprends pas comment un prog peut ainsi zapper des valeurs d'un OS à un autre sachant que la machine virtuelle java est de la même version !
Pour un peu plus de compréhension, voici un bon de mon fichier XML en entrée :
Et suite à la standardisation des mes champs, voici le XML que j'obtiens en sortie sous Unix :
La valeur d'un des tag est manquante, alors que sous window, le xml de sortie reste bien le même qu'en entrée.
Mon parser fonctionne comme tout parser digne de ce nom, en appellant les méthodes startElement, characters et endElement selon le type de balise qu'il rencontre.
Après avoir mis quelques traces dans mon programme pour comparer l'exécution entre window et unix, je m'apercoit que pour l'attribut "toto", le parser n'appelle pas la méthode "character" sous unix, alors que sous window oui. C'est pourquoi finalement la valeur n'est pas reprise dans le xml de sortie.
Si certains d'entre vous on compris mes explications, ma question est donc de comprendre pourquoi sous unix, le parser ne détecte pas qu'il se trouve dans un tag "attrib" et n'appelle pas la méthode character associée... alors que sous window tout se déroule normalement ?
Certains d'entre vous ont peut etre déjà eu une différence de parsing sous window / unix ?
Voici vite fais quelques bout de code de mon parser :
Le fichier xml en entrée est en binaire, d'ou le fait que mon parser utiliser un byteScanner (maison).
Merci à ceux qui se pencheront sur mon problème.
J'ai actuellement le problème suivant lorsque j'exécute mon programme java sous Aix.
Mon prog est sensé parser un fichier XML pour standardiser ses informations. Lorsque mon prog tourne sous Window (mon poste de dev), rien d'anormal, les valeurs des tags sont bien retrouvées et standardisée.
Seulement lorsque ce même programme est installé sous AIX, certaines valeurs de tag ne sont pas "retrouvée" alors qu'elle sont présente dans le fichier XML en entrée... je ne comprends pas comment un prog peut ainsi zapper des valeurs d'un OS à un autre sachant que la machine virtuelle java est de la même version !
Pour un peu plus de compréhension, voici un bon de mon fichier XML en entrée :
<attribs> <attrib name="toto">119</attrib> <attrib name="tata">108</attrib> <attrib name="tutu">10</attrib> <attrib name="titi">1</attrib> <attrib name="tete">121</attrib> </attribs>
Et suite à la standardisation des mes champs, voici le XML que j'obtiens en sortie sous Unix :
<attribs> <attrib name="toto"></attrib> <attrib name="tata">108</attrib> <attrib name="tutu">10</attrib> <attrib name="titi">1</attrib> <attrib name="tete">121</attrib> </attribs>
La valeur d'un des tag est manquante, alors que sous window, le xml de sortie reste bien le même qu'en entrée.
Mon parser fonctionne comme tout parser digne de ce nom, en appellant les méthodes startElement, characters et endElement selon le type de balise qu'il rencontre.
Après avoir mis quelques traces dans mon programme pour comparer l'exécution entre window et unix, je m'apercoit que pour l'attribut "toto", le parser n'appelle pas la méthode "character" sous unix, alors que sous window oui. C'est pourquoi finalement la valeur n'est pas reprise dans le xml de sortie.
Si certains d'entre vous on compris mes explications, ma question est donc de comprendre pourquoi sous unix, le parser ne détecte pas qu'il se trouve dans un tag "attrib" et n'appelle pas la méthode character associée... alors que sous window tout se déroule normalement ?
Certains d'entre vous ont peut etre déjà eu une différence de parsing sous window / unix ?
Voici vite fais quelques bout de code de mon parser :
scanner = new NplByteScanner(new FileInputStream(theFile), getConfig()); handler.startDocument(); // --- Roll up on all tag element while (true) { scanner.nextElement(true); if (scanner.sgmlElement.qName == null) break; if (scanner.isEOF()) { handler.endDocument(); break; } if (scanner.pcdata.length > 0 && !(new String(scanner.pcdata)).trim().equalsIgnoreCase("") ) handler.characters(scanner.pcdata, 0, scanner.pcdata.length); if (scanner.sgmlElement.state == NplElement.TAG_STARTING) handler.startElement(scanner.sgmlElement.qName, scanner.sgmlElement.attributes); if (scanner.sgmlElement.state == NplElement.TAG_ENDING) handler.endElement(scanner.sgmlElement.qName); }//end-while
Le fichier xml en entrée est en binaire, d'ou le fait que mon parser utiliser un byteScanner (maison).
Merci à ceux qui se pencheront sur mon problème.
A voir également:
- [java - xml] Parser sous window puis unix
- Waptrick java football - Télécharger - Jeux vidéo
- Jeux java itel - Télécharger - Jeux vidéo
- Xml download - Télécharger - Édition & Programmation
- Eclipse java - Télécharger - Langages
- Java apk - Télécharger - Langages
3 réponses
Re,
J'ai investigué un peu plus sur le problème, et il se trouve que les valeurs qui disparaissent sont les suivantes : 2, 22, 222, 7 et 77 (les valeurs de l'exemple donné plus haut ne sont pas celles qui bug réellement)
Les valeurs Hexa pour ces chiffres en UTF-8 sont les suivantes :
2 = 00 32
22 = 00 32 00 32
222 = 00 32 00 32 00 32
7 = 00 37
77 = 00 37 00 37
J'en conclu qu'il y a donc un problème lorsque les valeurs de mes champs ont pour valeur que des 2 ou que des 7... mais la grande question reste POURQUOI ? ^^
EDIT : J'ai essayer de faire passer la valeur '33' dans un de ces champs pour voir si c'est bon, et c'est le cas... j'en conclu donc que j'ai fais un programme raciste envers les chiffres 2 et 7 sous unix :aie:
Quelqun peut-il m'aider à y voir plus clair ? Merci.
J'ai investigué un peu plus sur le problème, et il se trouve que les valeurs qui disparaissent sont les suivantes : 2, 22, 222, 7 et 77 (les valeurs de l'exemple donné plus haut ne sont pas celles qui bug réellement)
Les valeurs Hexa pour ces chiffres en UTF-8 sont les suivantes :
2 = 00 32
22 = 00 32 00 32
222 = 00 32 00 32 00 32
7 = 00 37
77 = 00 37 00 37
J'en conclu qu'il y a donc un problème lorsque les valeurs de mes champs ont pour valeur que des 2 ou que des 7... mais la grande question reste POURQUOI ? ^^
EDIT : J'ai essayer de faire passer la valeur '33' dans un de ces champs pour voir si c'est bon, et c'est le cas... j'en conclu donc que j'ai fais un programme raciste envers les chiffres 2 et 7 sous unix :aie:
Quelqun peut-il m'aider à y voir plus clair ? Merci.