我们刚刚遇到了一个有趣的问题，我们在对消息转换的响应流进行单元测试时会遇到这个问题。 此流程的结果是（XML到NON XML）二进制输出，它被放在队列中。 我们面临的问题是： 此二进制输出消息的长度与非xml数据的长度不匹配，我们将其保存为MFL格式测试器工具的预期结果。我们的推论是，OSB在内部对此消息应用了一些编码，根据它看起来是代理/业务服务中存在的UTF-8。因此我们将预期的编码更改为UTF-8，测试用例成功。但仔细研究后发现 UTF-8凭借其自身的优点并不能正确表示所有数据。哪里有数据丢失，用'？ '符号。 因此，即使JUNIT测试用例通过，我们的比较也是不正确的。
此外还有MQ可能有自己的编码，我们现在无法排除。
我们可以想到两个解决方案： 1.我们可以通过将预期和获得的转换为Byte []来实现比较，以避免任何编码问题。但是我们无法在输出中获得确切的消息长度。 2.我们可以将预期和获得的结果编码为UTF-8以外的通用编码格式，但我们不确定哪个，然后进行比较。
任何想法帮派？
答案 0 :(得分：0)
当您查看UTF-8编码的二进制数据并看到问号（？）时，您可能不会遇到数据丢失。如果您的计算机上安装了不完整的字体集，并且没有字符可以显示文件中指定的特定unicode字符，则可能性要大得多。您的二进制到UTF-8转换例程的可能性较小，使用的字符缺少字形。
如果二进制文件不匹配，您应该已经解决了问题。可能的情况是，其中一个二进制文件编码字符串序列的结尾，文件序列的结尾，传输序列的结尾，或者某些程序集使程序混淆，认为当实际存在更多数据时，它会完成。
或者您错误地将二进制文件转换为字符串序列。二进制比较应该在字节级别进行，而在Java中你不能假设字节==字符。