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

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

например: мой ввод = 0200B2200000001000000000000000800000201234000000010000011072218012345606A5DFGR021ABCDEFGHIJ 1234567890

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

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

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


hex decoder iso8583
person user3985315    schedule 28.08.2014    source источник
comment
Кто-нибудь знает об этой проблеме?   -  person user3985315    schedule 01.09.2014
comment
Существует множество различных реализаций ISO 8583, и они отличаются способом кодирования полей и значением значений в полях. В реализациях, которые я видел, комбинация MTI и кода обработки (поле 3) определяет тип сообщения. В любом случае, чтобы интерпретировать сообщение, вы должны получить документацию по реализации ISO 8583, для которой предназначено это сообщение.   -  person Stuart    schedule 21.09.2014

Ответы (2)


arrow_upward
5
arrow_downward

Существует большой список диалектов, основанных на спецификациях 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  0000201234000000
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"

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

person iso8583.info support    schedule 01.06.2015

arrow_upward
1
arrow_downward

Ваш пример ввода выглядит как стандартная входная строка 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, вы обычно можете посмотреть на блок текста, как показано выше, в котором нет двоичного файла, и мысленно проанализировать большую его часть, чтобы получить представление о том, что это за тип транзакции без растрового изображения, иногда даже если вы знакомы с этим конкретным вариантом.

person CRSouser    schedule 09.10.2014