Советы по выбору различных бинарных XML-инструментов
Мое требование состоит в том, чтобы сжать 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++?
Один из них - agile delta, но он коммерческий.
3 ответа
Вы упоминаете буферы протокола (protobuf); это двоичный формат, но не имеет прямого отношения к XML. В частности, имена элементов (имена элементов / имена атрибутов / пространства имен) не кодируются - это просто данные (с числовыми маркерами для идентификаторов).
Таким образом, вы не можете восстановить произвольный XML из потока protobuf, если вы уже не знаете, как отобразить "поле 3" и т. Д.
Тем не мение! Если у вас есть объектная модель, которая работает с XML и protobuf, преобразование тривиально; десериализовать с любым - сериализовать с любым. Насколько хорошо это работает, зависит от реализации; например, с protobuf-net это тривиально, и на самом деле я пишу кодоген (загружаю бинарный файл; пишу как XML; запускаю XML через слой xslt для генерации кода).
Если вы на самом деле просто хотите передать объектные данные (а XML - это просто предложенная деталь реализации), тогда я полностью рекомендую protobuf; независимость от платформы, широкий спектр реализаций, толерантность к версии, очень маленький вывод и очень быстрая обработка как при чтении, так и при записи.
Надим,
Это очень хорошие вопросы. Возможно, вы новичок в домене, но ветераны XML часто задают одни и те же вопросы. Я постараюсь обратиться к каждому из них.
Я слышал о буферах протокола Google и об экономности Facebook, может кто-нибудь сказать мне, могут ли эти двое выполнить работу, которую я ищу?
Как отметил Марк, Protocol Buffers и Thrift являются двоичными форматами данных, но они не являются форматами XML, предназначенными для передачи данных XML. Например, они не поддерживают такие понятия XML, как пространства имен, атрибуты и т. Д., Поэтому сопоставление XML и этих двоичных форматов потребует немалой работы с вашей стороны.
ИЛИ просто дайте мне знать, если есть что-то лучше, чем EXI, я должен искать.
EXI, вероятно, ваш лучший выбор. W3C завершил довольно тщательный анализ реализаций формата XML и обнаружил, что реализация EXI (Efficient XML) последовательно достигла наилучшей компактности и была одной из самых быстрых. Они также обнаружили, что он неизменно обеспечивает лучшую компактность, чем сжатие GZIP, и даже упакованные двоичные форматы, такие как ASN.1 PER (см. W3C EXI Evaluation). Ни один из других форматов XML не смог этого сделать. В тестах, которые я видел, сравнивая EXI с буфером протокола, EXI был как минимум в 2-4 раза меньше.
Я хочу, чтобы лучшее из обоих миров, лучшее сжатие + лучшая производительность синтаксического анализа, какие-либо предложения??
Если это вариант, вы можете рассмотреть коммерческие продукты. Упомянутые выше тесты WIC 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, который можно передавать прямо в приложение или из него.
Надеюсь это поможет!
Сжатие унифицировано с грамматической системой в формате EXI. API декодера обычно дает вам последовательность событий, таких как события SAX, когда вы позволяете декодерам обрабатывать потоки EXI, однако декодеры не преобразуют внутренне EXI обратно в текст XML для подачи в другой анализатор. Вместо этого декодер выполняет весь сложный процесс распаковки / сканирования, чтобы получить последовательность событий API, такую как SAX. Поскольку EXI и XML совместимы на уровне событий, довольно просто выписать XML-текст с учетом последовательности событий.