Sin su fuente o datos reales, será difícil para nosotros diagnosticar qué es lo que está fallando. Sin embargo, puedo hacer algunas sugerencias:
- Unicode NUL (0x00) es ilegal en todas las versiones de XML y los analizadores de validación deben rechazar la entrada que lo contiene.
- A pesar de lo anterior; El XML no validado del mundo real puede contener cualquier tipo de basura con bytes mal formados imaginables.
- XML 1.1 permite caracteres de control de ancho cero y no imprimibles (excepto NUL), por lo que no puede mirar un archivo XML 1.1 en un editor de texto y saber qué caracteres contiene.
Dado lo que escribió, sospecho que lo que sea que convierta los datos de la base de datos a XML está roto; está propagando caracteres que no son XML.
Cree algunas entradas de la base de datos con caracteres que no sean XML (NUL, DEL, caracteres de control, etc.) y ejecute su convertidor XML en él. Envíe el XML a un archivo y mírelo en un editor hexadecimal. Si esto contiene caracteres que no son XML, su convertidor está roto. Corríjalo o, si no puede, cree un preprocesador que rechace la salida con dichos caracteres.
Si la salida del convertidor se ve bien, el problema está en su consumidor XML; está insertando caracteres que no son XML en alguna parte. Tendrá que dividir su proceso de consumo en pasos separados, examinar el resultado en cada paso y reducir lo que está introduciendo los caracteres malos.
Comprobar la codificación de archivos (para UTF-16)
Actualización:¡Acabo de encontrarme con un ejemplo de esto! Lo que sucedía es que el productor codificaba el XML como UTF16 y el consumidor esperaba UTF8. Dado que UTF16 usa 0x00 como byte alto para todos los caracteres ASCII y UTF8 no, el consumidor veía cada segundo byte como NUL. En mi caso, podría cambiar la codificación, pero sugerí que todas las cargas útiles XML comenzaran con una lista de materiales.
