2010-12-08 3 views
0

메시지 변환의 응답 흐름을 단위 테스트하는 과정에서 우리가 직면 한 흥미로운 문제가 생겼습니다. 이 흐름의 결과는 대기열에 저장되는 (XML to NON XML) 2 진 출력입니다. 우리가 직면 한 문제는 다음과 같습니다. 이 이진 출력 메시지의 길이가 MFL 형식 테스터 도구에서 예상 한 결과로 저장 한 non-xml 데이터의 길이와 일치하지 않습니다. 우리의 추측은 OSB가 내부적으로 프록시/비즈니스 서비스에 UTF-8로 보이는이 메시지에 인코딩을 적용한다는 것입니다. 그래서 우리는 UTF-8로 예상 된 인코딩을 변경했으며 테스트 케이스가 성공적이었습니다. 그러나 가까운 조사에서 그것의 자신의 미덕에 의한 UTF-8이 모든 데이터를 정확하게 나타내지는 않는다는 것이 발견되었습니다. 데이터 손실이있는 곳에서는 '?'로 표시됩니다. '기호. 따라서 JUNIT 테스트 사례가 통과하더라도 비교가 잘못되었습니다.이진 메시지 비교

또한 중간에 고유 한 인코딩을 가질 수있는 MQ가 있으며, 현재로서는이를 배제 할 수 없습니다.

우리는 이것을 두 가지 해결책으로 생각할 수 있습니다 : 1. 예상과 획득을 모두 Byte []로 변환하여 인코딩 문제가 발생하지 않도록 비교를 구현할 수 있습니다. 그러나 출력에서 ​​정확한 메시지 길이를 얻을 수는 없습니다. 2. 예상 결과와 획득 결과를 모두 UTF-8 이외의 일반적인 인코딩 형식으로 인코딩 할 수 있지만 어느 것이 확실하지 않은지 비교를 수행합니다.

아이디어가 있나요?

답변

0

UTF-8로 인코딩 된 이진 데이터를보고 물음표 (?)를 볼 때 데이터가 손실되지 않을 가능성이 있습니다. 확률은 컴퓨터에 불완전한 글꼴 세트가 설치되어 있고 파일에 지정된 특정 유니 코드 문자를 표시 할 문자가없는 것이 훨씬 낫습니다. UTF-8 변환 루틴에서 글리프가없는 문자를 사용하는 경우가 적습니다.

바이너리가 일치하지 않으면 문제를 수정해야합니다. 확률은 바이너리 중 하나가 문자열 시퀀스의 끝, 파일 시퀀스의 끝, 전송 시퀀스의 끝 또는 프로그램이 더 많은 데이터가 실제로 존재할 때 완료되었다고 생각하도록 혼란시키는 비트 세트를 인코딩한다는 것입니다.

바이너리를 문자열 시퀀스로 잘못 캐스팅하고 있습니다. 바이너리 비교는 바이트 레벨에서 이루어져야하며 Java에서는 바이트 == 문자로 간주 할 수 없다.

+0

에드윈 답장을 보내 주셔서 감사합니다. 예, 바이너리를 먼저 수정했지만 길이 불일치를 결정할 수는 없습니다. MOM과 관련이있을 수 있습니다. 만약 '?' 반드시 데이터 손실이 아니므로 '?' 항상 동일한 기본 이진 데이터를 나타냅니다? – hakish

+0

바이너리에 문제가있는 것으로 판명되었습니다. – hakish