Bez Twoich rzeczywistych danych lub źródła trudno będzie nam zdiagnozować, co jest nie tak. Mogę jednak przedstawić kilka sugestii:
- Unicode NUL (0x00) jest niedozwolony we wszystkich wersjach XML i sprawdzanie parserów musi odrzucić dane wejściowe, które go zawierają.
- Pomimo powyższego; rzeczywisty, niezwalidowany XML może zawierać wszelkiego rodzaju śmieci, źle uformowane bajty, jakie można sobie wyobrazić.
- XML 1.1 zezwala na znaki kontrolne o zerowej szerokości i niedrukowalne (z wyjątkiem NUL), więc nie możesz spojrzeć na plik XML 1.1 w edytorze tekstu i powiedzieć, jakie znaki zawiera.
Biorąc pod uwagę to, co napisałeś, podejrzewam, że wszystko, co konwertuje dane bazy danych na XML, jest zepsute; propaguje znaki inne niż XML.
Utwórz kilka wpisów w bazie danych zawierających znaki inne niż XML (NUL, DEL, znaki sterujące itp.) i uruchom na nich konwerter XML. Wyprowadź XML do pliku i przejrzyj go w edytorze szesnastkowym. Jeśli zawiera znaki inne niż XML, konwerter jest uszkodzony. Napraw to lub, jeśli nie możesz, utwórz preprocesor, który odrzuca dane wyjściowe z takimi znakami.
Jeśli dane wyjściowe konwertera wyglądają dobrze, problem dotyczy konsumenta XML; wstawia gdzieś znaki inne niż XML. Będziesz musiał podzielić proces konsumpcji na oddzielne kroki, zbadać wyniki na każdym kroku i zawęzić, co wprowadza złe znaki.
Sprawdź kodowanie pliku (dla UTF-16)
Aktualizacja:sam natknąłem się na taki przykład! To, co się działo, to fakt, że producent kodował XML jako UTF16, a konsument oczekiwał UTF8. Ponieważ UTF16 używa 0x00 jako starszego bajtu dla wszystkich znaków ASCII, a UTF8 nie, konsument widział co drugi bajt jako NUL. W moim przypadku mogłem zmienić kodowanie, ale zasugerowałem, że wszystkie ładunki XML zaczynają się od BOM.
