Разница в длине байта при извлечении из сообщения WebSphere MQ

Проблема очевидна в формулировке вопроса. Вы описываете полезную нагрузку, содержащую произвольные двоичные данные, а также пытаетесь обработать ее как строку. Эти две вещи взаимоисключающие.

Это кажется сложным из-за того, что поставщик не предоставляет действительный XML. Например, рассмотрим вложение:

   <PdfBytes>iVBORw0KGgoAAAANS … AAAAASUVORK5CYII=</PdfBytes>

Если вложение на законных основаниях содержит какой-либо специальный символ XML, например < или >, результатом будет недопустимый XML. Если он содержит нулевые байты, некоторые синтаксические анализаторы предполагают, что они достигли конца текста, и прекращают синтаксический анализ там. Вот почему вы обычно видите, что любое вложение в XML либо преобразовано в Base64 для передачи, либо преобразовано в шестнадцатеричный формат.

Поставщик описывает запись необработанных двоичных данных, что предполагает, что то, что вы получаете, содержит нестроковые символы и, следовательно, не должно не отправляться как строковые данные. Если бы она описала какое-то преобразование, которое сделало бы вложение совместимым с XML, тогда строка была бы уместна.

Интересно, что при кодировании Base64 полезная нагрузка в 1,33 раза больше, чем исходная. Совпадение, что 21k * 1.3 = 28k? Можно подумать, что то, что получено, на самом деле является двоичной полезной нагрузкой в ​​формате Base64. Это на самом деле было бы разборчивым как строка и объясняет разницу в размерах файлов. Но это совсем не то, что описал продавец. она сказала, что пишет «8-битные двоичные данные без знака без кодировки», а не Base64.

Поэтому мы ожидаем, что он выйдет из строя, но не обязательно приведет к увеличению полезной нагрузки. Учтите, что WebSphere MQ, получив сообщение в формате String, попытается его преобразовать. Если 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 и двоичные данные