2009-04-29 7 views
6

Ho una procedura memorizzata XML in MS SQL 2005 che utilizzo SqlCommand.ExecuteXmlReader per ottenere un XmlReader, quindi analizzare i dati e formare un documento XML. Il problema è che i dati in SQL contengono alcuni caratteri binari che sono illegali all'interno di un documento XML UTF-8, quindi viene generata un'eccezione.Filtro XML Caratteri illegali in .NET

Qualcun altro ha affrontato questo problema? Ho considerato di filtrare i dati sull'input nel DB, ma poi dovrei mettere il filtro ovunque e ogni carattere dovrebbe essere controllato.

Altri suggerimenti?

MODIFICA: I dati vengono in genere memorizzati in colonne varchar di varia lunghezza. I dati vengono effettivamente inseriti dagli utenti nei moduli Web (app ASP .NET). Così a volte copia-incolla da MS Word o qualcosa del genere e inserisce questi strani caratteri binari in.

risposta

0

Ho già astratto la creazione di oggetti SqlParameter in qualsiasi punto dell'applicazione, quindi scriverò l'input in quel punto. Il mio metodo di astrazione crea e restituisce un oggetto SqlParameter da utilizzare in una chiamata di procedura memorizzata. Se si tratta di un varchar richiesto dal chiamante, eseguirò un ciclo di ogni carattere della stringa che vogliono creare in un oggetto SqlParameter e filtrerà quei caratteri XML binari illegali. Ciò eliminerà i cattivi dati dall'entrare nel database in primo luogo.

0

Come sono entrati nel database i dati non validi? Stai usando una colonna XML?

È possibile inserire il filtro (si chiama "validazione", in realtà) nelle stored procedure utilizzate per immettere dati nel database, oppure è possibile aggiungere trigger per controllare i dati indipendentemente da dove provengono.

In generale, non consentire l'inserimento di dati non validi nel database!

+0

I dati sono input dell'utente memorizzati in colonne varchar nel database. –

0

È una questione di codifica? O l'xml è appena malformato? Se malformato, non posso aiutare. Ma per la codifica ... è spiacevole che ExecuteXmlReader non ti permetta di specificare la codifica, ma puoi trattare i dati come un BLOB e processarli separatamente con la tua codifica e XmlReader?

Se i dati sono di grandi dimensioni, si sarebbe probabilmente desidera utilizzare ExecuteReader con CommandBehavior.SequentialAccess e scriverlo in un file temporaneo (Path.GetTempFileName()) - allora processo che file come Stream con XmlReader.

0

In che modo la stored procedure genera l'XML?Se si utilizza una qualsiasi delle opzioni FOR XML in SQL Server, i caratteri binari in campi di testo saranno adeguatamente sfuggito:

CREATE TABLE test (
    id int identity(1,1) not null primary key, 
    data nvarchar(50)) 
INSERT INTO test (data) values (char(0)) 
SELECT * FROM test FOR XML RAW 

produce:

<row ID="1" data="&#x0;" /> 
+0

Sto usando "For Xml Explicit" –

+0

Ciò non dovrebbe avere importanza; FOR XML EXPLICIT esegue correttamente l'escape anche dei caratteri XML binari. –

1

Ho visto la "scramble" DotNet SqlClient i dati dalle colonne nvarchar nel database, la nostra teoria che era la sua qualcosa a che fare con "punti di codice surrogati", vedi:

http://www.siao2.com/2005/07/27/444101.aspx

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=rzaaxsurrogate.htm

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0004816.htm

SqlClient sembrava di "interpretare" alcuni dei byte meaing che il nostro Xml non era più ben formato, la conversione in nvarchar (max) sembrava fermare questo (anche se questo ha avuto un impatto sulle prestazioni):

SELECT CONVERT(NVARCHAR(MAX), MyValue) FROM ... 

si noti che è necessario utilizzare nvarchar (max), nvarchar (N) non funziona.

Abbiamo anche riscontrato che il provider OleDB funziona correttamente (sebbene sia più lento di SqlClient).

Problemi correlati