2009-04-29 21 views
6

Tengo un procedimiento XML almacenado en MS SQL 2005 que utilizo SqlCommand.ExecuteXmlReader para obtener un XmlReader, luego analizo los datos y formulo un documento XML. El problema es que los datos en SQL contienen algunos caracteres binarios que son ilegales dentro de un documento XML UTF-8, por lo que se lanza una excepción.Filtrar caracteres XML no válidos en .NET

¿Alguien más ha solucionado este problema? Consideré filtrar los datos de entrada en el DB, pero luego tendría que poner el filtro en todas partes, y todos los caracteres deberían ser revisados.

¿Alguna otra sugerencia?

EDIT: Los datos se almacenan típicamente en columnas varchar de diversa duración. Los datos son realmente ingresados ​​por los usuarios en formularios web (aplicación ASP .NET). Así que a veces copian y pegan de MS Word o algo así y ponen estos extraños caracteres binarios.

Respuesta

0

He abstraído la creación de objetos SqlParameter en todas partes en la aplicación, así que borraré la entrada en ese punto. Mi método de abstracción crea y devuelve un objeto SqlParameter para usar en una llamada a procedimiento almacenado. Si se trata de un varchar que la persona que llama quiere, recorreré cada carácter de la cadena que desea convertir en un objeto SqlParameter y filtraré esos caracteres XML binarios ilegales. En primer lugar, eliminará la entrada de datos erróneos en la base de datos.

0

¿Cómo entraron los datos erróneos en la base de datos? ¿Estás usando una columna XML?

Puede poner el filtrado (se llama "validación", en realidad) en los procedimientos almacenados utilizados para ingresar datos en la base de datos, o puede agregar activadores para verificar los datos independientemente de su origen.

¡En general, no permita que ingresen datos incorrectos en la base de datos!

+0

Los datos son datos ingresados ​​por el usuario en columnas varchar en la base de datos. –

0

¿Es esto una cuestión de codificación? ¿O el xml está mal formado? Si está malformado, no puedo ayudar. Pero para la codificación ... es desafortunado que ExecuteXmlReader no le permita especificar la codificación, pero podría tratar los datos como un BLOB, y procesarlos por separado con su propia codificación y XmlReader?

Si los datos es grande, probablemente querrá usar ExecuteReader con CommandBehavior.SequentialAccess y escribirlo en un archivo temporal (Path.GetTempFileName()) - a continuación, proceso que presentar como un Stream con XmlReader.

0

¿De qué manera su procedimiento almacenado produce el XML?Si utiliza cualquiera de las opciones PARA XML en SQL Server, caracteres binarios en los campos de texto estarán debidamente escaparon:

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

Estoy usando "For Xml Explicit" –

+0

Eso no debería importar; FOR XML EXPLICIT también escapa correctamente de los caracteres XML binarios. –

1

que he visto el "scramble" DotNet SqlClient los datos de las columnas nvarchar en la base de datos, nuestra teoría que era su algo que ver con "puntos de código de sustitución", ver:

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 parecía "interpretar" algunos de los bytes meaing que nuestro XML ya no estaba bien formado, que convierte a nvarchar (max) pareció dejar esto (aunque esto tuvo un impacto en el rendimiento):

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

Tenga en cuenta que es necesario utilizar nvarchar (max), nvarchar (N) no funciona.

También encontramos que el proveedor OleDB también funciona correctamente (aunque es más lento que el SqlClient).

Cuestiones relacionadas