Sem seus dados ou fontes reais, será difícil para nós diagnosticar o que está acontecendo de errado. No entanto, posso fazer algumas sugestões:
- Unicode NUL (0x00) é ilegal em todas as versões de XML e os analisadores de validação devem rejeitar a entrada que o contém.
- Apesar do exposto; XML não validado do mundo real pode conter qualquer tipo de bytes mal formados imagináveis.
- O XML 1.1 permite caracteres de controle de largura zero e não imprimíveis (exceto NUL), então você não pode ver um arquivo XML 1.1 em um editor de texto e dizer quais caracteres ele contém.
Dado o que você escreveu, suspeito que o que quer que converta os dados do banco de dados em XML esteja quebrado; está propagando caracteres não XML.
Crie algumas entradas de banco de dados com caracteres não XML (NULs, DELs, caracteres de controle, etc.) e execute seu conversor XML nele. Envie o XML para um arquivo e examine-o em um editor hexadecimal. Se contiver caracteres não XML, seu conversor está quebrado. Corrija-o ou, se não for possível, crie um pré-processador que rejeite a saída com esses caracteres.
Se a saída do conversor parecer boa, o problema está em seu consumidor XML; está inserindo caracteres não XML em algum lugar. Você terá que dividir seu processo de consumo em etapas separadas, examinar a saída em cada etapa e restringir o que está introduzindo os maus caracteres.
Verifique a codificação do arquivo (para UTF-16)
Atualização:acabei de me deparar com um exemplo disso! O que estava acontecendo é que o produtor estava codificando o XML como UTF16 e o consumidor esperava UTF8. Como o UTF16 usa 0x00 como o byte alto para todos os caracteres ASCII e o UTF8 não, o consumidor estava vendo cada segundo byte como um NUL. No meu caso, eu poderia alterar a codificação, mas sugeri que todas as cargas XML começassem com um BOM.
