【问题标题】:Binary Message Comparison二进制消息比较
【发布时间】:2011-01-31 01:21:53
【问题描述】:

我们刚刚在对消息转换的响应流进行单元测试时遇到了一个有趣的问题。 此流程的结果是(XML 到 NON XML)二进制输出,它被放入队列。 我们面临的问题是: 此二进制输出消息的长度与非 xml 数据的长度不匹配,我们将其保存为 MFL 格式测试工具的预期结果。我们的推断是 OSB 在内部对此消息应用了一些编码,从外观上看,它是代理/业务服务中存在的 UTF-8。于是我们把expected的编码改成了UTF-8,测试用例成功了。但仔细调查后发现 UTF-8 本身并不能正确表示所有数据。哪里有数据丢失,它用'? ' 象征。 因此,即使 JUNIT 测试用例通过,我们的比较也不正确。

而且中间还有MQ,可能有自己的编码,目前我们无法排除。

我们可以想到两种解决方案: 1. 我们可以通过将期望值和获得值都转换为 Byte[] 来实现比较,以避免任何编码问题。但是我们无法在输出中获得确切的消息长度。 2、我们可以将期望结果和得到的结果都编码成UTF-8以外的通用编码格式,但不确定是哪种,然后进行比较。

有什么想法吗?

【问题讨论】:

    标签: java encoding ibm-mq oracle-service-bus osb


    【解决方案1】:

    当您查看 UTF-8 编码的二进制数据并看到问号 (?) 时,您可能没有遇到数据丢失的情况。如果您的计算机上安装了不完整的字体集,并且没有字符可以显示文件中指定的特定 unicode 字符,则几率要好得多。您的二进制到 UTF-8 转换例程使用缺少字形的字符的可能性较小。

    如果二进制文件不匹配,您应该已经解决了那里的问题。奇怪的是,其中一个二进制文件编码了字符串序列的结尾、文件序列的结尾、传输序列的结尾或某些位集,这会使程序误以为实际存在更多数据时它已经完成)。

    要么是这样,要么你错误地将二进制文件转换为字符串序列。二进制比较应该在字节级别进行,在 Java 中你不能假设字节 == 字符。

    【讨论】:

    • 感谢 Edwin 的回复,是的,我们希望先修复我们的二进制文件,但仍无法确定长度不匹配。可能和妈妈有关。如果 '?'不一定是数据丢失,所以它是否确保“?”总是代表相同的底层二进制数据?
    • 原来是二进制文件有问题。
    猜你喜欢
    • 1970-01-01
    • 2016-03-17
    • 2011-11-22
    • 2016-08-16
    • 2013-11-28
    • 1970-01-01
    • 2016-06-29
    • 2011-06-14
    • 2011-08-15
    相关资源
    最近更新 更多