実際のデータやソースがなければ、何が問題になっているのかを診断するのは困難です。ただし、いくつか提案することができます：
- Unicode NUL（0x00）はすべてのバージョンのXMLで無効であり、検証パーサーはそれを含む入力を拒否する必要があります。
- 上記にもかかわらず;実際の検証されていないXMLには、考えられるあらゆる種類の不正な形式のバイトが含まれている可能性があります。
- XML 1.1では、幅がゼロで印刷されない制御文字（NULを除く）が許可されているため、テキストエディタでXML 1.1ファイルを調べて、含まれている文字を特定することはできません。
あなたが書いたことを考えると、データベースデータをXMLに変換するものはすべて壊れていると思います。非XML文字を伝播しています。
非XML文字（NUL、DEL、制御文字など）を使用していくつかのデータベースエントリを作成し、その上でXMLコンバーターを実行します。 XMLをファイルに出力し、16進エディターで確認します。これに非XML文字が含まれている場合、コンバーターは壊れています。修正するか、できない場合は、そのような文字を含む出力を拒否するプリプロセッサを作成してください。
コンバーターの出力が良好に見える場合、問題はXMLコンシューマーにあります。 XML以外の文字をどこかに挿入しています。消費プロセスを別々のステップに分割し、各ステップで出力を調べて、悪い文字を導入しているものを絞り込む必要があります。
ファイルエンコーディングの確認（UTF-16の場合）
更新：私はちょうどこれの例に出くわしました！何が起こっていたのかというと、プロデューサーはXMLをUTF16としてエンコードしており、コンシューマーはUTF8を期待していたということです。 UTF16はすべてのASCII文字の上位バイトとして0x00を使用し、UTF8は使用しないため、コンシューマーは1バイトおきにNULと見なしていました。私の場合、エンコーディングを変更することはできますが、すべてのXMLペイロードはBOMで始まることをお勧めします。