Senza i tuoi dati o la tua fonte, sarà difficile per noi diagnosticare cosa sta andando storto. Tuttavia, posso dare alcuni suggerimenti:
- Unicode NUL (0x00) è illegale in tutte le versioni di XML e i parser di convalida devono rifiutare l'input che lo contiene.
- Nonostante quanto sopra; l'XML non convalidato del mondo reale può contenere qualsiasi tipo di byte di forma irregolare immaginabile.
- XML 1.1 consente caratteri di controllo a larghezza zero e non stampabili (tranne NUL), quindi non puoi guardare un file XML 1.1 in un editor di testo e dire quali caratteri contiene.
Dato quello che hai scritto, sospetto che qualunque cosa converta i dati del database in XML sia rotto; sta propagando caratteri non XML.
Crea alcune voci di database con caratteri non XML (NUL, DEL, caratteri di controllo, et al.) ed esegui il tuo convertitore XML su di esso. Emetti l'XML in un file e guardalo in un editor esadecimale. Se contiene caratteri non XML, il convertitore è danneggiato. Correggilo o, se non puoi, crea un preprocessore che rifiuti l'output con tali caratteri.
Se l'output del convertitore sembra buono, il problema è nel tuo consumer XML; sta inserendo caratteri non XML da qualche parte. Dovrai suddividere il processo di consumo in passaggi separati, esaminare l'output in ogni passaggio e restringere il campo a ciò che sta introducendo i caratteri negativi.
Controlla la codifica dei file (per UTF-16)
Aggiornamento:mi sono appena imbattuto in un esempio di questo stesso! Quello che stava succedendo è che il produttore stava codificando l'XML come UTF16 e il consumatore si aspettava UTF8. Poiché UTF16 utilizza 0x00 come byte alto per tutti i caratteri ASCII e UTF8 no, il consumatore vedeva ogni secondo byte come NUL. Nel mio caso potrei cambiare la codifica, ma ho suggerito che tutti i payload XML inizino con una distinta base.
