Ohne Ihre tatsächlichen Daten oder Quellen wird es für uns schwierig sein, zu diagnostizieren, was schief läuft. Ich kann jedoch ein paar Vorschläge machen:
- Unicode NUL (0x00) ist in allen XML-Versionen illegal und validierende Parser müssen Eingaben zurückweisen, die es enthalten.
- Trotz des oben Gesagten; nicht validiertes XML aus der realen Welt kann jede erdenkliche Art von fehlerhaft geformten Bytes enthalten.
- XML 1.1 erlaubt Steuerzeichen mit Nullbreite und nicht druckbare Steuerzeichen (außer NUL), sodass Sie sich eine XML 1.1-Datei nicht in einem Texteditor ansehen und feststellen können, welche Zeichen sie enthält.
Angesichts dessen, was Sie geschrieben haben, vermute ich, dass alles, was die Datenbankdaten in XML konvertiert, defekt ist. es verbreitet Nicht-XML-Zeichen.
Erstellen Sie einige Datenbankeinträge mit Nicht-XML-Zeichen (NULs, DELs, Steuerzeichen usw.) und führen Sie Ihren XML-Konverter darauf aus. Geben Sie das XML in eine Datei aus und betrachten Sie es in einem Hex-Editor. Wenn dies Nicht-XML-Zeichen enthält, ist Ihr Konverter defekt. Beheben Sie das Problem oder erstellen Sie, falls dies nicht möglich ist, einen Präprozessor, der die Ausgabe mit solchen Zeichen ablehnt.
Wenn die Ausgabe des Konverters gut aussieht, liegt das Problem bei Ihrem XML-Verbraucher; es fügt irgendwo Nicht-XML-Zeichen ein. Sie müssen Ihren Verbrauchsprozess in separate Schritte unterteilen, die Ergebnisse bei jedem Schritt untersuchen und eingrenzen, was die schlechten Charaktere einführt.
Dateikodierung prüfen (für UTF-16)
Update:Ich bin gerade selbst auf ein Beispiel gestoßen! Was geschah, war, dass der Produzent das XML als UTF16 kodierte und der Konsument UTF8 erwartete. Da UTF16 0x00 als High-Byte für alle ASCII-Zeichen verwendet und UTF8 dies nicht tut, sah der Verbraucher jedes zweite Byte als NUL. In meinem Fall könnte ich die Codierung ändern, schlug aber vor, dass alle XML-Nutzlasten mit einem BOM beginnen.
