Comment créer en toute sécurité un XPathNavigator contre un flux en C #?

Question

À partir d'un flux, comment créer en toute sécurité un XPathNavigator sur une source de données XML?

La source de données XML:

• Peut éventuellement contenir des caractères hexadécimaux invalides qui doivent être supprimés.
• Peut contenir des caractères ne correspondant pas à l'encodage déclaré du document.

Par exemple, certaines sources de données XML dans le nuage auront un codage déclaré de utf-8 , mais le codage réel est windows-1252 ou ISO 8859-1 , ce qui peut provoquer la levée d'une exception de caractère non valide lors de la création d'un XmlReader sur le flux.

Dans la documentation de la propriété StreamReader.CurrentEncoding : "Le codage de caractères actuel utilisé par le lecteur actuel. La valeur peut être différente après le premier appel d'une méthode de lecture de StreamReader, car la détection automatique du codage n'est effectuée qu'au premier appel d'une méthode de lecture. " Cela semble indiquer que CurrentEncoding peut être vérifié après la première lecture, mais sommes-nous bloqués pour stocker cet encodage lorsque nous devons écrire les données XML dans un flux?

J'espère trouver la meilleure pratique pour créer en toute sécurité une instance de XPathNavigator / IXPathNavigable sur une source de données XML qui gérera avec élégance le codage d'un problème de caractère non valide (de préférence en C #).

Answer 1

J'ai eu un problème similaire lorsque certains fragments XML ont été importés dans un système CRM à l'aide d'un codage incorrect (aucun codage n'était stocké avec les fragments XML).

Dans une boucle, j'ai créé un flux d'encapsulation en utilisant l'encodage actuel d'une liste. Le codage a été construit en utilisant les options DecoderExceptionFallback et EncoderExceptionFallback (comme mentionné par @Doug). Si une exception DecoderFallbackException a été levée lors du traitement, le flux d'origine est réinitialisé et le codage le plus probable suivant est utilisé.

Notre liste de codage était quelque chose comme UTF-8, Windows-1252, GB-2312 et US-ASCII. Si vous êtes tombé en fin de liste, le flux était vraiment mauvais et a été rejeté / ignoré / etc.

EDIT:

J'ai préparé un échantillon rapide et des fichiers de test de base (source ici ). Le code ne contient aucune heuristique permettant de choisir entre des pages de code correspondant au même jeu d'octets. Par conséquent, un fichier Windows-1252 peut être détecté au format GB2312, et inversement, en fonction du contenu du fichier et de l'ordre de préférence de codage. / p>

Answer 2

Il est possible d'utiliser la classe DecoderFallback . (et quelques classes associées) pour traiter les caractères incorrects, soit en les sautant, soit en effectuant autre chose (redémarrer avec un nouvel encodage?).

Answer 3

Lors de l'utilisation d'un XmlTextReader ou de quelque chose de similaire, le lecteur lui-même déterminera le codage déclaré dans le fichier xml.