Ошибка распаковки поля 35 в сообщении ISO 8583 с использованием jpos

Я столкнулся с проблемами при разделении DE 35, мой упаковщик xml для DE 35 выглядит так.

Данные DE 35 выглядят так [ 374622441715101175D26071361916993999999F ], где 37 — это длина, а остальные данные.

когда я распаковал это поле, я получаю данные до второй последней цифры, похожей на [374622441715005175D23071261916092999999] F переходит к следующему полю. из-за этого остальные поля не получают данные правильно.

так что вы можете помочь мне правильно прочитать DE-35 со всеми данными, включая F .


person Shekhar Jadhav    schedule 02.03.2017    source источник
comment
Если я не ошибаюсь, мне кажется, что 37-й символ - это 9, поэтому f не является частью содержимого 37 длины, не так ли?   -  person Zachary Craig    schedule 02.03.2017
comment
Мы могли бы помочь лучше, если бы вы предоставили полный шестнадцатеричный дамп сообщения (при условии, что там нет конфиденциальной информации, я также предполагаю, что 4622441715005175 не является реальным номером карты, и в этом случае эту карту следует считать скомпрометированной). И полное определение вашего пакета, чтобы мы могли воспроизвести весь процесс распаковки.   -  person Andrés Alcarraz    schedule 02.03.2017
comment
Похоже на шестнадцатеричное представление содержимого и должно обрабатываться с помощью IFB_LLNUM. Правая буква «F» — это просто правильное дополнение поля по умолчанию.   -  person apr    schedule 02.03.2017
comment
[02003020058020C010040058020C010040010000000000550800000830021000100374622441715005175D230712619160929912619160929999992313233343533132333435363738313233343536323820202020202020200000000000000202000000000000000000000000000006303030303139] Это мой шестнадцатеричный   -  person Shekhar Jadhav    schedule 03.03.2017
comment
Я пробовал IFB_LLNUM, но он не работает   -  person Shekhar Jadhav    schedule 03.03.2017


Ответы (1)


Я использовал необработанные данные вместо шестнадцатеричного, тогда он работает

person Shekhar Jadhav    schedule 06.03.2017