XmlDocument.Load Remplacement ">"

Question

Lors de l'exécution du code suivant :

 static void Main(string[] args)
    {
        var xmlDoc = new XmlDocument();

        var fileReader = new BinaryReader(File.Open(@"C:\Users\username\Desktop\doc.xlf",FileMode.Open,FileAccess.Read,FileShare.Read));
        var sourceStream = new MemoryStream(fileReader.ReadBytes((int)fileReader.BaseStream.Length));
        xmlDoc.Load(sourceStream);
    }

Sur un fichier avec un nœud qui ressemble à ceci :

        <b>Ce texte est affiché en gras.</b><br>
        <i>Ce texte est affiché en italique.</i>

Le nœud est converti en ceci lorsqu'il est lu :

        <b>Ce texte est affiché en gras.</b><br>
        <i>Ce texte est affiché en italique.</i>

En d'autres termes, tous les > sont remplacés par >

Normalement, cela ne poserait pas de problème (et j'ai même l'impression que ce serait techniquement légal, même si c'est une mauvaise pratique), mais dans ce cas, il est absolument impératif que le nœud ne change pas lorsqu'il est lu. Des idées soit (1) comment lire le xml pour permettre > soit (2) comment contourner ce problème ? Merci !

Answer 1

Bien que le chevron droit soit autorisé en XML, il n'y a pas d'option sur XmlDocument pour éviter de le changer en entité correspondante.

Vous pourriez plutôt utiliser une section CDATA :

    Ce texte est affiché en gras.</b><br>
<i>Ce texte est affiché en italique.</i>]]>

Answer 2

Il n'y a pas de différence en XML entre > et > dans les valeurs des nœuds de texte. Ainsi, l'analyseur XML/DOM est libre de représenter la valeur sous l'une ou l'autre forme tel qu'il le juge bon.

Notez qu'il existe d'autres normalisations en XML (espaces blancs et sauts de ligne) qui garantissent presque que le XML enregistré ne sera pas identique octet par octet au XML source.

Si vous avez vraiment besoin de conserver > intact, essayez d'utiliser CDATA, même si cela garantit que le texte ne sera pas modifié - certains analyseurs vous permettent de conserver > au lieu de le convertir en > lors de l'enregistrement.

La vraie solution est d'accepter le fait que certains caractères seront encodés (y compris les caractères non-ASCII s'ils sont enregistrés avec un encodage qui ne les prend pas en charge directement) lors de l'enregistrement pour produire un XML valide.