Discussion :

[nicO1077]

Bonjour à tous,

Il se trouve que j'ai rencontré un problème assez particulier pour générer un fichier xml.

J'ai un programme qui récupère des données pour remplir des objets que j'ai créé. Je souhaite alors tous les parcourir dans l'ordre que je souhaite pour en générer un xml d'une structure légèrement différente.

J'utilise alors une instance de XmlTextWriter pour générer mon fichier xml (qui fait déjà 310 000 caractères au total).

Seulement j'obtient le problème suivant : Tout les 4096 caractères dans mon fichier généré j'ai une insertion d'un caractère null (vous savez le fameux petit carré). Les conséquences sont catastrophique puisque celui-ci remplace parfois un caractère, parfois pire une balise < ou >. Résultat plantage lors de l'exploitation de l'xml généré.

Cela viendrait apparemment d'un problème de buffer.

J'ai cherché sur le forum, apparemment personne n'a eut ce soucis.. Auriez vous déjà rencontrer ce type de problème ? Je n'ai pas encore trouvé de solutions pour y pallier...

Merci

[tomlev]

Ca m'étonnerait que ce soit un problème du XmlTextWriter... c'est probablement toi qui a fait une erreur en l'utilisant. Fais voir le code concerné

Sinon, vu la description de ton programme, je me demande si la sérialisation XML ne serait pas plus simple qu'un XmlTextWriter pour ce que tu cherches à faire...

[nicO1077]

Ca m'étonnerait que ce soit un problème du XmlTextWriter... c'est probablement toi qui a fait une erreur en l'utilisant. Fais voir le code concerné

Sinon, vu la description de ton programme, je me demande si la sérialisation XML ne serait pas plus simple qu'un XmlTextWriter pour ce que tu cherches à faire...

Merci pour la réponse rapide

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
tw = new XmlTextWriter(nomFichier, Encoding.UTF8);
tw.Formatting = Formatting.Indented;
tw.WriteStartDocument(true);
 
//creation 'listing'
tw.WriteStartElement("listing");
foreach (Catalogue _cat in monListing.LstCatalogue)
{
    //balise catalogue - et définition des attributs id et nom
    tw.WriteStartElement("catalogue");
    tw.WriteAttributeString("id", _cat.Id.ToString());
    tw.WriteAttributeString("nom", _cat.Nom);
 
    //contenu de la balise
    tw.WriteString(_cat.Keywords);
 
    //fin balise 'catalogue'
    tw.WriteEndElement();
}
 
//fin 'listing'
tw.WriteEndElement();
 
//fin du document xml
tw.WriteEndDocument();
 
//On vide le buffer
tw.Flush();
 
//On ferme le fichier 'GenereXml'
tw.Close();

Concernant la sérialisation, ça ne pourrait pas être possible car j'ai 2 logiques totalement différente d'organisation des données entre le site et l'appli avec laquelle je dois communiquer. D'où justement ce xml que j'agence dans une deuxième logique différente aux objets remplis. (mouais... si vous avez compris z'êtes forts vu comment je m'explique )

Dans les pire des cas... je passerais par l'écriture manuelle des balises xml en écriture de fichier... ou je pourrais passer par un stream ?

Moi ce qui m'étonne c'est que cette insertion soit tout les 4096 caractères. Il n'y aura pas une redondance j'en aurais déduit une erreur dans le remplissage des objets or ce n'est pas le cas, c'est donc une pétouille au niveau du traitement de la génération. Je me trompe ?


EDIT : Je viens de tester d'écrire le tout dans un stream en passant toujours par le xmlTextWriter, j'ai toujours cette insertion parasite...


EDIT 02 : La classe xmlTextWriter n'écrit les données que lorsque la méthode close() est appelée selon msdn. Donc même un flush() inséré de manière frénétiquement un peu partout dans le code ne change rien. Sur d'autres ressources du net apparemment les données sont enregistrées 4096 caractères par 4096 caractères ce qui correspond tout simplement au buffer. C'est bien beau tout ça... mais j'ai toujours pas trouvé le moyen de ne pas générer ce caractère null par la méthode xmlTextWriter. :X
PS : *pense sérieusement à ne générer que le doctype par XmlTextWriter, et se taper un vieux AppendFile au fur et à mesure...*

[nicO1077]

Bon,

je double-post pour donner la réponse.

Comme je l'ai expliqué plus haut, la classe xmlTextWriter du framework 2.0 est bugée.

Pour une utilisation sur quelques lignes aucun soucis. Mais si on commence à générer des xml très long on aura tout les 4096 caractères une insertion d'un caractère null (vous savez le petit carré) qui remplacera le caractère normal.

Heureusement il existe une solution, je l'ai trouvé sur msdn où il est expliqué sans équivoque que l'utilisation de XmlTextWriter est déconseillée. Il faut lui préférer tout simplement la classe dont elle dérive à savoir XmlWriter (combiné à un XmlWriterSettings).

je viens de tester je n'ai plus ces insertions intempestives.
(merci quand même tomlev pour ta réponse ultra-rapide (7 minutes record battu ))

[tomlev]

Bon,

je double-post pour donner la réponse.

Comme je l'ai expliqué plus haut, la classe xmlTextWriter du framework 2.0 est bugée.

Pour une utilisation sur quelques lignes aucun soucis. Mais si on commence à générer des xml très long on aura tout les 4096 caractères une insertion d'un caractère null (vous savez le petit carré) qui remplacera le caractère normal.

Heureusement il existe une solution, je l'ai trouvé sur msdn où il est expliqué sans équivoque que l'utilisation de XmlTextWriter est déconseillée. Il faut lui préférer tout simplement la classe dont elle dérive à savoir XmlWriter (combiné à un XmlWriterSettings).

je viens de tester je n'ai plus ces insertions intempestives.
(merci quand même tomlev pour ta réponse ultra-rapide (7 minutes record battu ))

Ah ben on a posté en même temps...
C'est chiant ça que la classe XmlTextWriter soit buggée... c'était plus pratique que d'utiliser un XmlWriterSettings !
Tu as un lien vers la page où tu as trouvé l'explication ?

[nicO1077]

j'ai vu ça oui ^^ on a posté en même temps ^^

Alors l'explication sur la préférence à faire est ici sur msdn france http://msdn.microsoft.com/fr-fr/libr...extwriter.aspx

Pour l'explication des 4096 caractères sur le buffer ce n'est pas moi qui ai remarqué ce détails troublant mais le développeur php qui retraitait mon xml généré et à eut l'idée de compter les caractères. Cependant il a rechercher brièvement et m'a parlé du fait qu'on enregistrait un fichier par paquet de 4096 caractères par 4096.

Enfin pour le fait que j'en déduise que XmlTextWriter soit bugées ayant fait de nombreux tests en modifiant chaque étape clés dans les méthodes utilisées (parcours des objets, construction du xml, et écriture du fichier) j'en suis venu à la conclusion qu'il y avait ce bug sur cette classe (J'ai également pris en considération l'avertissement sur msdn, et j'ai pris aussi en compte que Microsoft n'est pas à l'abri des bugs ) Et surtout aussi le fait que le problème s'est résolu sans rien changer juste autre que la substitution du XmlTextWriter par XmlWriter (puisque les méthodes sont les mêmes il n'y a que l'instanciation qui diffère)

Pour ta dernière question, en ouvrant sous bloc note on ne remarque qu'un espace blanc. En ouvrant sous Dreamweaver ou sous le fameux wordpad je retrouve ce caractère carré. (Au passage je me suis aussi développé un léger soft pour analyser l'encoding d'un fichier car j'ai aussi cherché par là)

voilà ^^

Edit : Merci pour l'article sur la sérialisation

[tomlev]

Bizarre, je vois pourtant rien d'anormal dans ton code
Tu es sûr que c'est bien un caractère null ? avec quoi tu as ouvert le fichier ?

PS : *pense sérieusement à ne générer que le doctype par XmlTextWriter, et se taper un vieux AppendFile au fur et à mesure...*

Ben c'est clair que vu la valeur ajoutée du XmlTextWriter dans ce cas, autant le faire manuellement...


sinon, pour en revenir à mon idée de sérialisation XML, c'est vraiment tout bête, il suffit de modifier tes classes Listing et Catalogue comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Catalogue
{
    [XmlAttribute("id")]
    public int Id { get; set; }
 
    [XmlAttribute("name")]
    public string Name { get; set; }
}
 
public classe Listing
{
    [XmlElement("catalogue")]
    public List<Catalogue> LstCatalogue { get; set; }
}

(sans oublier d'ajouter [XmlIgnore] aux propriétés qui ne doivent pas être sérialisées)

Avec ça la sérialisation XML devrait donner le schema voulu...


Si ça te pose problème de définir ce schema de façon statique avec des attributs, tu peux aussi le faire de façon dynamique avec la classe XmlAttributeOverrides, comme expliqué dans mon article :
http://tlevesque.developpez.com/dotn...zation/#LIII-D