バイナリメッセージの比較

Question

メッセージ変換の応答フローの単体テスト中に直面している興味深い問題に出会いました。このフローの結果は、キューに置かれた（XMLから非XML）バイナリ出力です。私たちが直面している問題は、このバイナリ出力メッセージの長さは、XML以外のデータの長さと一致しないことです。これは、MFL形式のテスターツールの結果として保存します。私たちの推論は、OSBがこのメッセージに内部的にエンコードを適用していることです。このメッセージは、その外観ではProxy/Business Serviceに存在するUTF-8です。そのため、予想されるUTF-8にエンコードを変更し、テストケースが成功しました。しかし、綿密な調査では、UTF-8がそれ自体の美徳によってすべてのデータを正しく表すものではないことがわかりました。データの損失がどこにありますか？ 'シンボル。したがって、Junitテストケースが合格しても、比較は正しくありません。

また、その間には独自のエンコードがあるかもしれないMQがあり、現時点では除外することはできません。

これに対する2つの解決策を考えることができます。1。予想されたものと取得した両方のバイトに変換して、エンコードの問題を回避することで比較を実装できます。しかし、出力で正確なメッセージの長さを取得することはできません。 2.予想された結果と取得された結果の両方をUTF-8以外の共通のエンコード形式にエンコードできますが、どちらがわかりません。その後、比較を行います。

ギャングはありますか？

Answer 1

UTF-8エンコードされたバイナリデータを見て、疑問符（？）を見ると、データの損失が発生していない可能性があります。オッズは、コンピューターに不完全なフォントセットがインストールされており、ファイルに指定されている特定のUnicode文字を表示する文字がありません。あなたのバイナリからUTF-8変換ルーチンがグリフを欠くキャラクターを使用する可能性はほとんどありません。

バイナリが一致しなかった場合、そこで問題を修正する必要があります。オッズは、バイナリの1つが文字列シーケンスの端、ファイルシーケンスの端、伝送シーケンスの終了、またはプログラムを混乱させて、実際により多くのデータが存在するときに行われると思われるビットのセットをエンコードすることです。

それか、あなたは誤ってバイナリを文字列シーケンスにキャストしています。バイナリ比較はバイトレベルで行う必要があり、Javaではバイト== charを想定することはできません。