Лучший способ разобрать сообщение FIX?

Вы имеете в виду использование QuickFIX? (Я вижу QuickFIX в ваших тегах)

если это так, то я не знаю. Как правило, написать простой анализатор для FIX-сообщения несложно. Я обнаружил, что веб-инструменты на действительном исправлении справляются со своей задачей.

Помимо использования фактического механизма quickfixengine, легко проанализировать сообщение об исправлении, если вы знаете, что оно содержит определенные теги.

Он содержит разделенные 0x1 пары строк «ключ = значение». Одной из сложностей являются группы, потому что вы должны выяснить, что тег является первым в группе (заголовок группы), а затем выяснить, когда группа заканчивается (когда он сталкивается с другим тегом, не входящим в группу).

Другим проблемным полем является поле RawData, которое может содержать что угодно, включая разделитель полей 0x1, но ему предшествует RawDataLength, поэтому вам нужно сначала прочитать это, а затем прочитать количество байтов RawDataLength после тега RawData, чтобы перейти к следующему полю.

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

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

Формат FIX на удивление раздражает при анализе (поскольку формат, отличный от XML, т. е. тот, который до сих пор используется почти всеми, не имеет начальных и конечных маркеров подгруппы, вместо этого вы должны работать с ним на основе правил порядка тегов и тегов, которые не находятся в подгруппе, заголовок или хвост могут быть в любом порядке).

Поэтому вместо того, чтобы разбирать его самостоятельно, я бы рекомендовал вам использовать для этого существующую библиотеку.

Единственным хорошо поддерживаемым вариантом с открытым исходным кодом является библиотека Java QuickFIX/J.

Есть много коммерческих решений, например. CameronFIX

попробуйте http://fix.nowing.com

это веб-парсер сообщений об исправлениях

из исходного кода quickfixj он использует treeMap для обработки сообщения FIX.

что касается формата XML, я думаю, что FIX лучше, хотя анализ в JAVA сложнее. потому что XML слишком тяжелый.

Не существует одного лучшего способа, но, учитывая тег quickfix, который вы или система SO прикрепили, взгляните на QuickFix движок FIX с открытым исходным кодом был бы хорошим местом для начала.

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

Удачи