Uden dine faktiske data eller kilde vil det være svært for os at diagnosticere, hvad der går galt. Jeg kan dog komme med et par forslag:
- Unicode NUL (0x00) er ulovlig i alle versioner af XML, og validerende parsere skal afvise input, der indeholder det.
- På trods af ovenstående; ikke-valideret XML fra den virkelige verden kan indeholde enhver form for affaldsformede bytes, man kan forestille sig.
- XML 1.1 tillader nul-bredde og ikke-udskrivende kontroltegn (undtagen NUL), så du kan ikke se på en XML 1.1-fil i en teksteditor og fortælle, hvilke tegn den indeholder.
I betragtning af det du skrev, har jeg mistanke om, at det, der konverterer databasedataene til XML, er brudt; det udbreder ikke-XML-tegn.
Opret nogle databaseposter med ikke-XML-tegn (NUL'er, DEL'er, kontroltegn, et al.), og kør din XML-konverter på den. Udskriv XML til en fil, og se på den i en hex-editor. Hvis denne indeholder ikke-XML-tegn, er din konverter ødelagt. Ret det eller, hvis du ikke kan det, opret en præprocessor, der afviser output med sådanne tegn.
Hvis konverterens output ser godt ud, ligger problemet i din XML-forbruger; det indsætter ikke-XML-tegn et eller andet sted. Du bliver nødt til at dele din forbrugsproces op i separate trin, undersøge outputtet ved hvert trin og indsnævre, hvad der introducerer de dårlige karakterer.
Tjek filkodning (for UTF-16)
Opdatering:Jeg er lige stødt på et eksempel på dette selv! Det, der skete, er, at producenten kodede XML som UTF16, og forbrugeren forventede UTF8. Da UTF16 bruger 0x00 som den høje byte for alle ASCII-tegn, og UTF8 ikke gør det, så forbrugeren hver anden byte som en NUL. I mit tilfælde kunne jeg ændre kodning, men foreslog, at alle XML-nyttelast starter med en stykliste.