Zonder uw werkelijke gegevens of bron, zal het voor ons moeilijk zijn om te diagnosticeren wat er mis gaat. Ik kan echter een paar suggesties doen:
- Unicode NUL (0x00) is illegaal in alle versies van XML en validerende parsers moeten invoer weigeren die deze bevat.
- Ondanks het bovenstaande; real-world niet-gevalideerde XML kan alle denkbare slecht gevormde bytes bevatten.
- XML 1.1 staat nul-breedte en niet-afdrukbare besturingstekens toe (behalve NUL), dus u kunt een XML 1.1-bestand niet in een teksteditor bekijken en zien welke tekens het bevat.
Gezien wat je schreef, vermoed ik dat alles wat de databasegegevens naar XML converteert, kapot is; het verspreidt niet-XML-tekens.
Maak een aantal database-items met niet-XML-tekens (NUL's, DEL's, controletekens, et al.) en voer uw XML-converter erop uit. Voer de XML uit naar een bestand en bekijk het in een hex-editor. Als dit niet-XML-tekens bevat, is uw converter defect. Repareer het of, als je dat niet kunt, maak een preprocessor die uitvoer met dergelijke tekens weigert.
Als de uitvoer van de converter er goed uitziet, zit het probleem in uw XML-consument; het voegt ergens niet-XML-tekens in. U moet uw consumptieproces in afzonderlijke stappen opsplitsen, de output bij elke stap onderzoeken en bepalen wat de slechte tekens introduceert.
Controleer bestandscodering (voor UTF-16)
Update:ik kwam hier zelf net een voorbeeld van tegen! Wat er gebeurde, is dat de producent de XML codeerde als UTF16 en de consument UTF8 verwachtte. Aangezien UTF16 0x00 gebruikt als de hoge byte voor alle ASCII-tekens en UTF8 niet, zag de consument elke tweede byte als een NUL. In mijn geval kon ik de codering wijzigen, maar stelde voor dat alle XML-payloads met een stuklijst beginnen.