Sans vos données ou sources réelles, il nous sera difficile de diagnostiquer ce qui ne va pas. Cependant, je peux faire quelques suggestions :
- Unicode NUL (0x00) est illégal dans toutes les versions de XML et les analyseurs de validation doivent rejeter l'entrée qui le contient.
- Malgré ce qui précède ; XML non validé du monde réel peut contenir n'importe quel type d'octets mal formés inimaginables.
- XML 1.1 autorise les caractères de contrôle de largeur nulle et non imprimables (sauf NUL). Vous ne pouvez donc pas consulter un fichier XML 1.1 dans un éditeur de texte et déterminer les caractères qu'il contient.
Compte tenu de ce que vous avez écrit, je soupçonne que tout ce qui convertit les données de la base de données en XML est cassé; il propage des caractères non XML.
Créez des entrées de base de données avec des caractères non XML (NUL, DEL, caractères de contrôle, etc.) et exécutez votre convertisseur XML dessus. Sortez le XML dans un fichier et regardez-le dans un éditeur hexadécimal. S'il contient des caractères non XML, votre convertisseur est défectueux. Corrigez-le ou, si vous ne pouvez pas, créez un préprocesseur qui rejette la sortie avec de tels caractères.
Si la sortie du convertisseur semble bonne, le problème vient de votre consommateur XML; il insère des caractères non XML quelque part. Vous devrez diviser votre processus de consommation en étapes distinctes, examiner la sortie à chaque étape et affiner ce qui introduit les mauvais caractères.
Vérifier l'encodage du fichier (pour UTF-16)
Mise à jour :je viens de tomber sur un exemple de cela moi-même ! Ce qui se passait, c'est que le producteur encodait le XML en UTF16 et que le consommateur attendait UTF8. Étant donné que UTF16 utilise 0x00 comme octet de poids fort pour tous les caractères ASCII et que UTF8 ne le fait pas, le consommateur voyait chaque octet sur deux comme un NUL. Dans mon cas, je pourrais changer l'encodage, mais j'ai suggéré que toutes les charges utiles XML commencent par une nomenclature.
