советы по выбору различных бинарных XML-инструментов

Question

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

Существует довольно много двоичных XML-протоколов и инструментов. Я нашел EXI (эффективный обмен XML) лучше по сравнению с другими. Пробовал его версию с открытым исходным кодом Exificient и нашел его хорошим.

Я слышал о буферах протокола Google и экономии Facebook, может кто-нибудь сказать мне, могут ли эти двое выполнить работу, которую я ищу?

ИЛИ просто дайте мне знать, если есть что-то лучше, чем EXI, я должен искать.

Кроме того, существует хороший синтаксический анализатор XML VTD-XML (я сам не пробовал, просто погуглил и почитал некоторые статьи), который обеспечивает лучшую производительность анализа по сравнению с DOM, SAX и Stax.

Я хочу лучшее из обоих миров, лучшее сжатие + лучшая производительность при разборе, какие-либо предложения?

Еще одна вещь, касающаяся EXI, как EXI может претендовать на скорость анализа синтаксического файла XML? Потому что он анализируется DOM, SAX или STax? Я бы поверил, что это правда, если бы был другой двоичный парсер для чтения декодированной версии. Поправь меня, если я ошибаюсь.

ТАКЖЕ, есть ли хорошая реализация C ++ с открытым исходным кодом для формата EXI? Версия в Java доступна EXIficient, но я не могу обнаружить реализацию с открытым исходным кодом C ++?

Есть один из них, но он коммерческий.

Answer 1

Надим,

Это очень хорошие вопросы.Вы можете быть новичком в домене, но ветераны XML часто задают одни и те же вопросы.Я постараюсь обратиться к каждому из них.

Я слышал о буферах протокола Google и экономии Facebook, может кто-нибудь сказать мне, могут ли эти двое выполнить работу, которую я ищу?

Как упоминалось Марком, Protocol Buffers и Thrift являются двоичными форматами данных, но они не являются форматами XML, предназначенными для передачи данных XML.Например, они не поддерживают такие концепции XML, как пространства имен, атрибуты и т. Д., Поэтому сопоставление между XML и этими двоичными форматами потребует немалой работы с вашей стороны.

ИЛИ просто дайте мне знатьесли есть что-то лучше, то EXI я должен искать.

EXI, вероятно, ваш лучший выбор.W3C завершил довольно тщательный анализ реализаций формата XML и обнаружил, что реализация EXI (Efficient XML) последовательно достигла наилучшей компактности и была одной из самых быстрых.Они также обнаружили, что он неизменно достигал лучшей компактности, чем сжатие GZIP, и даже упакованных двоичных форматов, таких как ASN.1 PER (см. Оценка EXI W3C ).Ни один из других форматов XML не смог этого сделать.В тестах, которые я видел, сравнивая EXI с буфером протокола, EXI был как минимум в 2-4 раза меньше.

Я хочу лучшего из обоих миров, лучшего сжатия + лучшей производительности разбора, какие-либо предложения ??

Если это вариант, вы можете рассмотреть коммерческие продукты.Упомянутые выше тесты W3C EXI использовали Efficient XML , что намного быстрее, чем EXIficient (иногда> в 10 раз быстрее синтаксического анализа и> в 20 раз быстрее сериализации).Ваш пробег может варьироваться, поэтому вы должны проверить его самостоятельно, если это вариант.

Еще одна вещь, касающаяся EXI, как EXI может утверждать, что она быстро обрабатывает декодированный XML-файл?

Причина, по которой EXI может быть меньше и быстрее для анализа, чем XML, заключается в том, что EXI может передаваться напрямую в / из памяти через стандартные API-интерфейсы XML, не создавая данных в промежуточном формате XML.Таким образом, вместо сериализации ваших данных в виде XML с помощью стандартного API, сжатия XML, отправки сжатого XML, декомпрессии XML на другом конце, а затем анализа его через один из API XML, ... вы можете сериализовать свои данные напрямуюкак EXI через стандартный XML API, отправьте EXI, а затем проанализируйте EXI напрямую через один из XML API на другой стороне.Это принципиальная разница между сжатием и EXI.EXI - это не сжатие как таковое - это более эффективный формат XML, который можно передавать прямо в / из вашего приложения.

Надеюсь, это поможет!

Answer 2

Вы упоминаете буферы протокола (protobuf); это двоичный формат, но не имеет прямого отношения к XML. В частности, имена членов (имена элементов / имена атрибутов / пространства имен) не кодируются - это просто данных (с числовыми маркерами для идентификаторов).

Таким образом, вы не можете восстановить произвольный XML из потока protobuf, если вы уже не знаете, как отобразить «поле 3» и т. Д.

Тем не менее! Если у вас есть объектная модель, которая работает с XML и protobuf, преобразование тривиально; десериализовать с любым - сериализовать с любым. Насколько хорошо это работает, зависит от реализации; например, с protobuf-net это тривиально, и именно так я делаю кодоген (загружаю двоичный файл; пишу как XML; запускаю XML через слой xslt для генерации кода).

Если вы на самом деле просто хотите передать данные объекта (а XML - это просто предлагаемая деталь реализации), тогда я полностью рекомендую protobuf; независимость от платформы, широкий спектр реализаций, толерантность к версии, очень маленький вывод и очень быстрая обработка как при чтении, так и при записи.

Answer 3

Сжатие унифицировано с грамматической системой в формате EXI. API декодера обычно дает вам последовательность событий, таких как события SAX, когда вы позволяете декодерам обрабатывать потоки EXI, однако декодеры не внутренне преобразуют EXI обратно в текст XML для подачи в другой анализатор. Вместо этого декодер выполняет весь сложный процесс распаковки / сканирования, чтобы получить последовательность событий API, такую ​​как SAX. Поскольку EXI и XML совместимы на уровне событий, довольно просто выписать XML-текст с учетом последовательности событий.