Кодирование и декодирование сообщений Iso8583

Question

Мой вопрос основан на стандартном стандарте сообщения по стандарту ISO8583. Моя проблема заключается в разработке приложения, которое будет декодировать сообщение ISO8583, которое предоставляется в виде ввода в формате HEX.

напра: мой входного = 0200B22000000010000000000000008000002A5DFGR021ABCDEFGHIJ 1234567890

Использование библиотеки JPOS я разбор этого шестнадцатеричного кода и вывод следующим образом: MTI: 0200 Field-3: 2 Field-4: 000000010000 полевом 7: 0110722180 Field-11: 123456 Field-44: A5DFGR Field-105: ABCDEFGHIJ 1234567890

Теперь этот разобранный вывод я хочу, чтобы расшифровать то я хочу, чтобы преобразовать это я в формате строки. Я хочу знать, что именно он передает, например, если это запрос баланса или запрос на транзакцию и т. Д.

так, мой вопрос в том, есть ли какой-либо инструмент для понимания шестнадцатеричного кода сообщения iso8583?

Answer 1

Ввод вашего примера выглядит как стандартная входная строка ASCII ISO-8583, а не в HEX или двоичном формате любого типа. Поэтому, если все ваши данные выглядят так, что большая часть вашей проблемы уже решена.

Что касается понимания того, что у вас есть, существует множество доступных общедоступной информации, характерной для декодирования форматов сообщений ISO-8583 и их значений. Для большинства из них они обычно следуют стандартным форматам полей, но могут иметь настраиваемые значения полей, уникальные для спецификации. Самое большое исключение - VISA и MasterCard, но региональные в США в целом довольно близки к ISO-8583-87.

Страница Википедии и документация jPOS, которые я предположил бы, предоставят вам большую часть документации, которую вы ищете, например, «Что такое поле 44?». Я поддерживаю и смотрю различные спецификации ISO-8583 в течение примерно 15 лет, и вам обычно нужно получить конкретную спецификацию поставщика непосредственно от них для всех вариантов данных и уникальной обработки данных, характерных для интерфейса. Есть несколько доступных для публики, которые довольно легко обнаруживаются путем поиска «ISO-8583 .PDF» в Google.

Улов является большинством спецификаций, и особенно оригинальная спецификация ISO-8583 от самой организации ISO не содержит примеров того, как выглядят конкретные транзакции. Хотя, если вы знаете контент элемента данных 003, вы должны иметь возможность логически собирать множество основных типов сообщений, чтобы хотя бы идентифицировать типы транзакций (т.е. 310000 = Запрос баланса по умолчанию) для вашей программы парсера, улов будет знать все поддерживающие поля и их соответствующие поля, специфичные для этой спецификации сущностей, которые необходимы для того, чтобы действительно сделать головы или хвосты, но с некоторым здравым смыслом вы тоже можете объединить их.

Как только вы знакомы с ISO-8583, вы можете обычно смотреть на блок текста, как у вас выше, который не имеет двоичного кода и мысленно разбирает большую часть его, чтобы получить представление о том, какой тип транзакции он не имеет битмап иногда даже если вы знакомы с этим конкретным вариантом.

Answer 2

Существует большой список диалектов, основанный на спецификациях ISO 8583 от 1987, 1993 и 2003 годов. Модифицированные протоколы используют сочетание данных ASCII, Binary, BCD, EBCDIC в полях.

Ваш образец сообщения похож на реализацию OmniPay Host to Host, за исключением поля 105, который не используется в этой спецификации.

без дополнительных модификаций был проанализирован с помощью онлайн-инструмента на https://iso8583.info/lib/OmniPay/H2H/msg

Используйте ваше сообщение «двоичный» представление:

0000: 30 32 30 30 42 32 32 30 │ 30 30 30 30 30 30 31 30 0200B22000000010 
0010: 30 30 30 30 30 30 30 30 │ 30 30 30 30 30 30 38 30 0000000000000080 
0020: 30 30 30 30 32 30 31 32 │ 33 34 30 30 30 30 30 30 00002
0030: 30 31 30 30 30 30 30 31 │ 31 30 37 32 32 31 38 30 0100000110722180 
0040: 31 32 33 34 35 36 30 36 │ 41 35 44 46 47 52 30 32 12345606A5DFGR02 
0050: 31 41 42 43 44 45 46 47 │ 48 49 4A 20 31 32 33 34 1ABCDEFGHIJ 1234 
0060: 35 36 37 38 39 30  │       567890 

Вот некоторые мусора в исходном сообщении, но это не вина парсеров.))

--- # Cheef's parser (Limited version - 5 levels deep only) 
- msg: # OmniPay H2H message 
    MTI: "0200" # Message Type ID. 
    DE000: "B220000000100000" # Primary bitmap // 1.3.4.7.11.44. 
- BM0: # Fields at Primary Bitmap 
    DE001: "0000000000800000" # Secondary bitmap // 105. 
    - DE003: # PC 
    S01: "20" # Transaction Code. // Refund 
    S02: "12" # Account, from. 
    S03: "34" # Account, to. 
    DE004: "000000010000" # Amount, transaction. // 10000 
    - DE007: # Date and time, transmission 
    date: "0110" # Date, local transmission. // 2015.01.10 
    time: "722180" # Time, local transmission. // 00:22:20 
    DE011: "123456" # STAN. 
    - DE044: # Additional response data 
    len: "06" 
    - val: 
     RFU: "A5DFGR" 

Онлайн-парсеры, определенные для нескольких диалектов, поэтому вы можете играть с данными своих сообщений и анализировать результаты.