0

メッセージ変換の応答フローの単体テスト中に直面する興味深い問題に遭遇しました。このフローの結果は、(XML から非 XML への) バイナリー出力であり、キューに入れられます。私たちが直面している問題は、このバイナリ出力メッセージの長さが非 xml データの長さと一致しないことです。これは、MFL フォーマット テスター ツールからの予想される結果として保存されます。私たちの推測では、OSB がこのメッセージに何らかのエンコーディングを内部的に適用していますが、これは一見、プロキシ/ビジネス サービスに存在する UTF-8 です。そのため、expected のエンコーディングを UTF-8 に変更し、テスト ケースは成功しました。しかし、綿密な調査の結果、UTF-8 はそれ自体の長所により、すべてのデータを正しく表現していないことがわかりました。データ損失が発生した場所はどこでも「?」で表されます。'記号。

また、その間に MQ があり、独自のエンコーディングを持つ可能性がありますが、現時点では除外できません。

これには 2 つの解決策が考えられます。 1. エンコーディングの問題を回避するために、期待値と取得値の両方を Byte[] に変換することで比較を実装できます。しかし、出力で正確なメッセージ長を取得することはできません。2. 期待される結果と取得された結果の両方を UTF-8 以外の一般的なエンコード形式にエンコードできますが、どちらが正しいかわからないため、比較を行います。

アイデアギャング？

4

1 に答える 1

0

UTF-8でエンコードされたバイナリデータを見て疑問符（？）が表示された場合、データの損失は発生していない可能性があります。コンピュータに不完全なフォントセットがインストールされていて、ファイルで指定された特定のUnicode文字を表示する文字がない場合の確率ははるかに高くなります。バイナリからUTF-8への変換ルーチンが、グリフのない文字を使用している可能性はわずかです。

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

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

于 2010-12-08T15:29:27.767 に答える