Бинарное сравнение сообщений

Question

Мы только что столкнулись с интересной проблемой, с которой мы сталкиваемся во время единичного тестирования потока отклика преобразования сообщения. Результатом этого потока является бинарный выход (XML -к не XML), который помещается в очередь. Проблема, с которой мы сталкиваемся, заключается в том, что длина этого двоичного выходного сообщения не соответствует длине не XML данных, которые мы сохраняем в качестве ожидаемого результата от инструмента Tester Format MFL. Наш вывод заключается в том, что OSB внутренне применяет некоторые кодирование к этому сообщению, которое, судя по всему, присутствует UTF-8 в прокси/бизнес-службе. Таким образом, мы изменили кодирование ожидаемого UTF-8, и тестовый пример был успешным. Но при тщательном расследовании было обнаружено, что UTF-8 по своей собственной добродетели не представляет все данные правильно. Где когда -либо есть потеря данных, он представлен с? ' символ. Следовательно, наше сравнение неверно, даже если проходит тестовый пример JUNIT.

А также есть MQ, между которым может быть свое собственное кодирование, которое мы не можем исключить в данный момент.

Мы можем подумать о двух решениях об этом: 1. Мы можем реализовать сравнение, преобразив как ожидаемое, так и полученное в байт [], чтобы избежать любых проблем кодирования. Но мы не можем получить точную длину сообщения на выводе. 2. Мы можем кодировать как ожидаемого, так и полученного результата в общий формат кодирования, отличный от UTF-8, но мы не уверены, какой, а затем проведем сравнение.

Какие -нибудь идеи банды?

Answer 1

Скорее всего, вы не испытываете потерю данных, когда смотрите на кодируемые бинарные данные UTF-8 и видите знак вопроса (?). Скорее всего, на вашем компьютере установлен неполный набор шрифтов, и нет символа для отображения конкретного символа Unicode, указанного в файле. Существует меньшая вероятность того, что ваша процедура преобразования Binary в UTF-8 использует персонажа, которому не хватает глифа.

Если двоичные файлы не совпадали, вы должны были исправить проблему там. Скорее всего, одно из двоичных файлов кодирует конец строковой последовательности, конец последовательности файлов, конец последовательности передачи или некоторый набор битов, который смущает программу, думая, что это сделано, когда на самом деле присутствует больше данных).

Либо это, либо вы неправильно вписываете бинарную в струнную последовательность. Бинарные сравнения должны быть проведены на уровне байтов, а на Java вы не можете предположить байты == chars.