java - 从WebSphere MQ消息检索时的字节长度差异

Question

在Java中，我正在轮询WebSphere MQ消息队列，期望消息为`STRING格式的消息，该消息完全由XML组成。该XML的一部分将包含文件附件的字节（任何格式：pdf，图像等），然后将其转换为blob以便存储在Oracle Db中，并在以后进行检索。

我遇到的问题是，发送过来的示例文件的已知大小最终以不同的大小出现在我的Db中。我没有在字节中添加任何内容（据我所知），并且在收到消息后大小似乎会更大。我无法确定我是否以某种方式在检索时添加信息，从bytes-> String进行转换，或者这是否发生在发件人填充邮件的前端。

我在检索消息时的代码：

              inboundmsg = new MQMessage();
              inboundmsg = getMQMsg(FrontIncomingQueue, gmo);
              strLen = inboundmsg.getMessageLength();
              strData = new byte[strLen];
              ibm_id = inboundmsg.messageId;
              inboundmsg.readFully(strData);
              inboundmsgContents = new String(strData);

我看到一个已知大小为21K的文件转到28K。一位同事建议字符集/编码可能是问题所在。从字符串转换回（用于其他无关的用途）时，我没有在上面的 String的构造函数调用中或在对 getBytes的任何调用中指定字符集。我的默认字符集是ISO-8859-1。与发起消息传输的供应商交谈时，我问她正在使用什么字符集。她的回复：

“我在C＃中使用File.WriteAllBytes方法-我将文件的路径传递给它，并将其写入到byte []中。我在MSDN上找不到有关该函数使用什么编码的任何文档。该方法创建了一个字节数组，而我今天早上在网上阅读的内容都没有编码，只是一个没有编码的8位无符号二进制数据序列。”

另一位同事建议，也许是MQ字符集是罪魁祸首，但是我对文档的阅读表明，MQ字符集仅影响 readString， readLine和 writeString的行为。

如果我完全规避MQ，并使用文件输入流和本地文件填充字节数组，则文件大小将一直保留到Db存储，因此，这肯定是在消息传输时或消息传输期间发生的。

Answer 1

问题在措词上很明显。您描述了一个包含任意二进制数据的有效负载，并且还尝试将其作为字符串处理。这两件事是互斥的。

由于供应商未提供有效的XML，这似乎变得很复杂。例如，考虑附件：

   <PdfBytes>iVBORw0KGgoAAAANS … AAAAASUVORK5CYII=</PdfBytes>

如果附件合法包含任何XML特殊字符（例如 <或 >），则结果为无效XML。如果它包含空字节，则某些解析器会假定它们已到达文本的结尾并在此处停止解析。这就是为什么您通常会看到XML中的任何附件要么转换为Base64进行传输，要么转换为十六进制。

供应商描述了写入原始二进制数据的过程，这表明您收到的内容包含非字符串字符，因此不应作为字符串数据发送。如果她描述了某种转换，使附件XML兼容，那么字符串将是适当的。

有趣的是，Base64编码产生的有效负载是原始负载的1.33倍。巧合的是 21k * 1.3 = 28k？有人会认为接收到的实际上是Base64格式的二进制有效负载。实际上，可以将其解析为字符串，并说明文件大小的差异。但这根本不是供应商所描述的。她说她正在写“没有编码的8位无符号二进制数据”，而不是Base64。

因此，我们希望它会失败，但不一定会导致更大的有效负载。考虑到接收到 String格式消息的WebSphere MQ将尝试对其进行转换。如果消息的CCSID与 GET上请求的消息不同，则MQ将尝试进行转换。如果入站CCSID为UTF-16或任何双字节字符集，则某些字符将从一字节扩展为两个字节-假定转换未遇到导致其失败的无效二进制字符。

如果两个CCSID相同，则在MQ类中不会尝试进行任何转换，但是仍然存在一个问题，就是必须解析XML负载，根据定义，该负载是无效的，因此可能会导致意外结果。如果碰巧二进制有效负载不包含任何XML特殊字符并且解析器没有阻塞任何嵌入的空字节，则解析器将使用相当长的长度来原谅不兼容的有效负载。如果它到达 </PdfBytes>标记而没有阻塞，则可以假定有效负载是有效的，并转换 <PdfBytes>...</PdfBytes>标记本身之间的所有内容。大概是Base64。

当然，所有这些都是推测。但是，在有效负载不是字符串数据明确无误的情况下，任何尝试对其进行解析的尝试都是因为字符串数据将彻底失败，或者产生意想不到的甚至潜在的奇怪结果。您实际上很不幸，它并没有彻底失败，因为现在可以预料，当问题显然是由供应商负责时，问题就在您的端上。

假设有效负载的内容保持不变，供应商应该发送 bytes消息，而您应该以 bytes的形式接收它们。至少可以解决MQ正在将预期格式与实际接收的格式进行协调的问题，但是它仍然是无效的XML。如果行得通，供应商将消息中的二进制数据发送为类型 String，并且您将其作为 bytes处理，那么请数数您的祝福并以这种方式使用它，但不要指望它是可靠的。最终，您将获得带有嵌入式XML特殊字符的有效负载，然后您将度过非常糟糕的一天。

理想情况下，供应商应该比在XML有效负载中发送二进制数据而不先将其转换为字符串更了解，并且由他们来修复它，以使其符合XML规范并可靠。

请参阅此MSDN页面： XML, SOAP, and Binary Data