2010-12-08 4 views
0

Nous venons de rencontrer un problème intéressant auquel nous sommes confrontés lors des tests unitaires du flux de réponse d'une transformation de message. Le résultat de ce flux est une sortie binaire (XML vers NON XML) qui est placée dans la file d'attente. Le problème auquel nous sommes confrontés est: La longueur de ce message de sortie binaire ne correspond pas à celle des données non-xml, que nous enregistrons comme résultat attendu de l'outil de test de format MFL. Notre inférence est que OSB applique en interne un certain codage à ce message qui par son apparence est UTF-8 présent dans Proxy/Business Service. Nous avons donc changé le codage de l'attendu en UTF-8 et le cas de test a été couronné de succès. Mais à la fin de l'enquête, il a été constaté que UTF-8 par sa propre vertu ne représente pas toutes les données correctement. Où qu'il y ait une perte de données, il est représenté par un '? ' symbole. Par conséquent, notre comparaison est incorrecte même si le test JUNIT réussit.Comparaison de messages binaires

Et il y a aussi MQ entre qui pourrait avoir son propre encodage, que nous ne pouvons pas exclure pour le moment. Nous pouvons penser à deux solutions à cela: 1. Nous pouvons implémenter la comparaison en convertissant à la fois l'attendu et obtenu en un Byte [] pour éviter tout problème d'encodage. Mais nous sommes incapables d'obtenir la longueur exacte du message dans la sortie. 2. Nous pouvons encoder les résultats attendus et obtenus dans un format de codage commun autre que UTF-8, mais nous ne sommes pas sûrs de quoi, et ensuite faire la comparaison.

Un gang d'idées?

Répondre

0

Vous ne risquez probablement pas de perdre des données lorsque vous consultez les données binaires codées en UTF-8 et que vous voyez un point d'interrogation (?). Les chances sont bien meilleures que vous ayez un jeu de polices incomplet installé sur votre ordinateur et qu'il n'y ait aucun caractère pour afficher le caractère Unicode particulier spécifié dans le fichier. Il y a une plus petite chance que votre routine de conversion binaire en UTF-8 utilise un caractère qui n'a pas de glyphe.

Si les fichiers binaires ne correspondaient pas, vous auriez dû résoudre le problème. Les chances sont que l'un des binaires code une séquence de fin de chaîne, une fin de séquence de fichier, une fin de séquence de transmission ou un ensemble de bits qui confond un programme en lui faisant croire que plus de données sont présentes).

Soit cela, soit vous ne lancez pas correctement un binaire dans une séquence de chaînes. Les comparaisons binaires doivent être faites au niveau des octets, et en Java, vous ne pouvez pas supposer bytes == chars.

+0

Merci pour la réponse Edwin, oui nous avons cherché à fixer nos binaires d'abord mais ne sommes pas encore en mesure de déterminer la discordance de longueur. peut être son quelque chose à voir avec MOM. si '?' n'est pas nécessairement une perte de données, donc cela garantit-il que '?' représente toujours les mêmes données binaires sous-jacentes? – hakish

+0

il s'est avéré être un problème avec les binaires. – hakish