Come posso creare in sicurezza un XPathNavigator contro uno Stream in C #?

Question

Dato uno Stream come input, come posso creare in sicurezza un XPathNavigator su un'origine dati XML?

L'origine dati XML:

• Potrebbe contenere caratteri esadecimali non validi che devono essere rimossi.
• Può contenere caratteri che non corrispondono alla codifica dichiarata del documento.

Ad esempio, alcune origini dati XML nel cloud avranno una codifica dichiarata di utf-8 , ma la codifica effettiva è windows-1252 o ISO 8859-1 , che può causare il lancio di un'eccezione di carattere non valido durante la creazione di un XmlReader contro lo Stream.

Dalla documentazione della proprietà StreamReader.CurrentEncoding : " La codifica dei caratteri corrente utilizzata dal lettore corrente. Il valore può essere diverso dopo la prima chiamata a qualsiasi metodo di lettura di StreamReader, poiché la codifica di rilevamento automatico non viene eseguita fino alla prima chiamata a un metodo di lettura. & Quot; Questo sembra indicare che CurrentEncoding può essere verificato dopo la prima lettura, ma siamo bloccati a memorizzare questa codifica quando abbiamo bisogno di scrivere i dati XML su uno Stream?

Spero di trovare le migliori pratiche per la creazione sicura di un'istanza XPathNavigator / IXPathNavigable rispetto a un'origine dati XML che gestirà con grazia la codifica di un carattere non valido (preferibilmente in C #).

Answer 1

Ho avuto un problema simile quando alcuni frammenti XML sono stati importati in un sistema CRM usando la codifica errata (non c'era codifica memorizzata insieme ai frammenti XML).

In un ciclo ho creato un flusso wrapper usando la codifica corrente da un elenco. La codifica è stata costruita utilizzando le opzioni DecoderExceptionFallback e EncoderExceptionFallback (come indicato da @Doug). Se durante l'elaborazione è stata emessa una DecoderFallbackException, lo stream originale viene ripristinato e viene utilizzata la codifica più probabile successiva.

La nostra lista di codifica era qualcosa come UTF-8, Windows-1252, GB-2312 e US-ASCII. Se sei uscito dalla fine dell'elenco, lo stream è stato davvero male ed è stato rifiutato / ignorato / ecc.

EDIT:

Ho preparato un rapido esempio e file di test di base (fonte qui ). Il codice non ha alcuna euristica da scegliere tra le code page che corrispondono entrambe allo stesso set di byte, quindi un file Windows-1252 può essere rilevato come GB2312 e viceversa, a seconda del contenuto del file e dell'ordinamento delle preferenze di codifica.

Answer 2

È possibile utilizzare la classe DecoderFallback (e alcune classi correlate) per affrontare i personaggi cattivi, saltandoli o facendo qualcos'altro (riavviando con una nuova codifica?).

Answer 3

Quando si utilizza un XmlTextReader o qualcosa di simile, il lettore stesso capirà la codifica dichiarata nel file xml.