XML-парсеры для Delphi.

← →
KilkennyCat © (2008-06-22 19:56) [0]

Какой лучше?

← →
Sergey Masloff (2008-06-22 20:32) [1]

msxml ;-)

← →
DrPass © (2008-06-22 20:46) [2]

> msxml ;-)

Ужос 8-)
Я обычно пользуюсь ECXMLParser. Шустрый, очень простой, что еще для счастья надо :) Там, правда, есть один небольшой бажок - буфер для распарсиваемой строки невелик, и оно может гавкнуться, если файл записан в одну длинную строку. Но лечится несложно.

← →
Поросенок Винни-Пух © (2008-06-22 21:14) [3]

msxml. Полет нормальный.

← →
KilkennyCat © (2008-06-22 21:23) [4]

Полет?

← →
Поросенок Винни-Пух © (2008-06-22 21:34) [5]

Шустрый, очень простой, что еще для счастья надо :) Там, правда, есть один небольшой бажок - буфер для распарсиваемой строки невелик, и оно может гавкнуться, если файл записан в одну длинную строку. Но лечится несложно.

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

← →
Поросенок Винни-Пух © (2008-06-22 21:35) [6]

опять же поддержа xpath в полный рост.

← →
KilkennyCat © (2008-06-22 21:45) [7]

> Поросенок Винни-Пух © (22.06.08 21:35) [6]

Я слышал обратное. Значит, доработали...

Поправьте меня, если ошибаюсь:

MSXML грузит весь документ в мозги
MSXML не гарантирует поддержку W3C

← →
Поросенок Винни-Пух © (2008-06-22 21:49) [8]

все дом парсеры грузят весь документ в память.
а что из якобы неподдерживаемых w3c стандартов интересует?
этож все таки xml, а не html.

← →
Игорь Шевченко © (2008-06-22 22:35) [9]

msxml

← →
Тимохов (2008-06-22 22:43) [10]

я native xml юзаю.
вполне доволен.

← →
Sergey Masloff (2008-06-22 22:50) [11]

Вобщем докладываю. Я в 2001 году начал использовать msxml для некой системы сбора отчетов. Суть такая: на выделенный адрес почты шлются отчеты а робот их парсит и раскладывает в базу. Отчетов в день от 50 до 500 размер до 30 Мб примерно в основном в пределах 3-4.
Вот что по итогам семилетней эксплуатации. Версия 2.5 при размере файла больше пары мегабайт была очень тормознутой (ошибок правда не давала но если скажем мегабайтный файл разбирался секунды то трехмегабайтный - десятки минут. Что вызывало проблемы когда за сутки иногда очередь не успевала прогрузиться. Проблема снялась в версии 2.6 а после версии 3.0 я вообще забыл про это...
Кстати msxml и SAX поддерживает, так что разговоры про "тормознутость" не имеют оснований.
Кстати версия 3 (вышедшая еще в 200 году так что я вообще не понимаю сейчас зачем я 2.5 использовал
- начала полностью поддерживать XPATH
- полная поддержка XSLT
- добавилась поддержка SAX 2

← →
KilkennyCat © (2008-06-22 23:22) [12]

Отлично. Но тогда какие основания для существования других вариантов?

← →
DrPass © (2008-06-23 00:44) [13]

> KilkennyCat © (22.06.08 23:22) [12]
> Отлично. Но тогда какие основания для существования других
> вариантов?

Я перешел на "другие варианты", когда MSXML 3.0 стал валиться с out of memory на одном в принципе безобидном документе довольно большого объема.

← →
Лабух (2008-06-23 01:39) [14]

Есть небольшой бажок у MSXML
Если в тексте встречаются нецензурные символы, типа #7, то записать он дает, а при чтении валится
должен или валиться при записи, или не валиться вообще

← →
atruhin1 (2008-06-23 07:25) [15]

> Отлично. Но тогда какие основания для существования других
> вариантов?

Скорость в несколько раз больше. Тестировал на множестве мелких файлов. Возможно связанно
не с самим парсером, а с COM. Поэтому если не нужно поддержка XPATH, XSLT ... и нужна максмальная
скорость, стоит рассмотреть варианты.
Из сторонних неплохой парсер SimDesign NativeXml (платный), очень стабильный, хотя не самый быстрый,
но быстрее msxml.

← →
Sergey Masloff (2008-06-23 21:03) [16]

atruhin1 (23.06.08 07:25) [15]
>Скорость в несколько раз больше.
Методика тестирования?

Я просто смотрел (очень давно правда) то что доктор боб у себя рекомендовал на сайте. Не устроил функционал а скорость не быстрее была... слова NativeXml в названии вроде были... не помню уже точно.

Тем более SAX же есть в том же msxml если вдруг скорость так важна будет.

← →
kaif © (2008-06-23 22:49) [17]

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

← →
Ega23 (zabyl password) (2008-06-23 22:52) [18]

IMHO. Полноценный парсер - слишком избыточен. Самый простой парсер пишется за день (по крайней мере я за день написал, ни разу в жизни подобным не занимамшись). Хороший и не с первого раза (как Ашот говорит) - вообще за час можно написать.

← →
atruhin1 (2008-06-23 23:26) [19]

> Методика тестирования?

Задача была парсить множество маленьких документов 10-50 узлов, но быстро.
Методика тестирования простая:
1. Загрузить документ
2. Прочитать узел по имени
3. Перейти к следующему.

← →
Sergey Masloff (2008-06-23 23:42) [20]

kaif © (23.06.08 22:49) [17]
уже написал такой который умеет проверять соответствие схеме с наследованием?

Ega23
тот же вопрос ;-) Или это избыточная функция?

← →
kaif © (2008-06-24 00:09) [21]

2 Sergey Masloff (23.06.08 23:42) [20]
kaif © (23.06.08 22:49) [17]
уже написал такой который умеет проверять соответствие схеме с наследованием?

Со схемами работать не было необходимости. Но я заметил, что в общем-то, возможно, идеального универсального решения и не существует. Все зависит от характера документов, с которыми имеешь дело. Иногда важна скорость, иногда - развитая функциональность, иногда - простота и надежность (допустим в атрибуте неверный тип данных, нужно принимать какие-то решения, соотвественно можно повесить событие или особенное исключение). В общем, я хочу сказать, что лично мне всегда проще написать с нуля, чем разбираться с чужим компонентом, да еще и упереться в глюк какой-нибудь скверный, когда уже все заточил под этот компонент. Да еще у компонента если исходного кода нет... Хотя такие я вообще стараюсь не использовать.

← →
Хохол (2008-06-24 03:28) [22]

Сам пользуюсь
http://www.simdesign.nl/xml.html

Быстрее msxml в 3-4 раза, без утечек памяти. Без проблем разбирал тестовый xml файл размером 600мб.

← →
Поросенок Винни-Пух © (2008-06-24 09:05) [23]

1. Загрузить документ
2. Прочитать узел по имени
3. Перейти к следующему.

В таком случае вообще странен сам выбор xml как формата. Купить бмв и ездить на нем заставляя жену на веревочке такать машину.

← →
Ega23 © (2008-06-24 10:23) [24]

> тот же вопрос ;-) Или это избыточная функция?

Под мои нужды - да, избыточная. Что схема, что X-Path.

← →
Поросенок Винни-Пух © (2008-06-24 10:43) [25]

А как без XPATH -то?
Ну вот нужно достать атрибут "name" у узла entity, имеющего атрибут id = 7
И как поступать без XPATH?
сверху вниз идем по чайлдам до уровня entity, затем в цикле по ним ищем узел с нужным атрибутом и читем параметр?

бррррр....

← →
Ega23 © (2008-06-24 10:45) [26]

> А как без XPATH -то?
> Ну вот нужно достать атрибут "name" у узла entity, имеющего
> атрибут id = 7
> И как поступать без XPATH?
> сверху вниз идем по чайлдам до уровня entity, затем в цикле
> по ним ищем узел с нужным атрибутом и читем параметр?
>
> бррррр....

Да легко. Мне нужно структурированные данные хранить, при старте - загрузить, при выходе - сохранить. Всё тупо.

понятно. мерседес в роли пепельницы. :)

> понятно. мерседес в роли пепельницы. :)

Не-а. Там формат свой. Гибрид XML и HTML.

В свое время на исходниках ребята проводили тест парсеров, я скопипастю:

> Итак, обещанные результаты тестирования парсеров XML. Пришлось,
> конечно, немного повозиться. Особенно со стандартным, так
> как он выдает глюки обычно где нужно и где не нужно. Например,
> если какой-то атрибут не присутствует, выдается ошибка.
>
>
> Для упрощения восприятия результатов, наилучший результат
> (наиболее быстрая скорость парсирования) была принята за
> 100%. Остальные результаты были получены в результате деления
> их скорости на наилучшую.
>
> В тестировании приняли участие:
> 1) стандартный Дельфийско-Микрософтовский парсер (TXmlDocument)
> 2) еще недавно мой любимый ECXML :(
> 3) Native XML (http://www.simdesign.nl/xml.html, "хорошая
> версия")
> 4) MVRB XML, XML Documents Parser (© 2002 Равиль Батыршин.
> ) с Torry (http://www.torry.net/vcl/internet/html/mvrbxmlparsers.
> zip)
> 5) Jan XML Parser2 (http://www.torry.net/vcl/internet/html/janxmlparser2.
> zip)
>
> Сразу оговорю, что в тесте использовал только полноценные
> парсеры, позволяющие извлекать в т.ч. и атрибуты тегов по
> индексу.
>
> Тест состоял в чтении XML и вывода его в TreeView с атрибутами.
>
>
> Тест 1. Файл размером 5 Кб.
> MS XML: 2000 % > ECXML: 300 % > Native XML: 200 % > MVRB XML: 200 % > JAN XML: 100 %
>
>
> Тест 2. Файл размером 1,75 МБ.
>
> Во втором тесте ECXML остановился на этапе загрузки документа
> с сообщением "Invalid pointer operation". Искать ошибку
> я пока не стал. А победителем, как и в первый раз, вышел
> Jan XML Parser2, которому пока можно присвоить звание "Самый
> быстрый парсер XML"
>
> MS XML: 820 % > Native XML: 515 % > MVRB XML: 285 % > JAN XML: 100 %
>
> Значит, теперь приступим к обещанному обзору парсеров со
> всеми их "подводными камнями".
>
> 1) TXMLDocument (Internet Tab)
> Скажу сразу, парсер - отвратительный. Если даже промолчать
> о его "тормознутости", то в нем еще куча неудобств. Например,
> отсутствие текста нода или атрибута приводит к весьма нежелательным
> сообщениям об ошибках, вместо того, чтобы "вежливо промолчать"
> и возвратить пустую строку. Это вынуждает программиста производить
> проверку на наявность атрибута или текста нода, что тоже
> сильно сказывается на производительности. Можно еще ставить
> try..except, но от этого не становится легче, особенно на
> этапе проектирования. Одним словом, код получается более
> громоздким и непонятным.
>
> Обновлено 3.04.2007:
> Но нужно оговориться, что все вышесказанное справедливо
> для TXMLDocument по отношению как к "парсеру", если им разбирать
> документы сложной, непостоянной или неопределенной структуры,
> как в приложенном выше коде. Для упрощения, ускорения и
> повышения удобства работы с TXMLDocument следует использовать
> биндинги: xml и delphi.
>
> 2) TECXMLParser
> Неплохой парсер, но, к сожелению, только для небольших файлов.
> На многих файлах больше мегабайта он вылетает. Средний
> по производительности. Так что требует доработки. Но в общем
> впечатление от него очень хорошие, парсер удобный. Свойства
> и методы интуитивно понятны. Особенно мне нравится работа
> с атрибутами нодов, поскольку они представлены в виде обычного
> TStrings. Благодаря этому можно вызывать как отдельные имена
> или значения нодов (Params.Names, Params.Values), так и
> полностью текст атрибута: Params[Index]. Так что если разобраться
> с его "вылетами", то можно считать его достойной заменой
> TXMLDocument. Особенно в свете того, что я еще скажу о лидере
> теста.
>
> 3) TNativeXml
> Тоже средний по скорости парсер, но уже входящий в тройку
> лидеров. В его пользу можно сказать то, что он исключительно
> стабильный. В то время, когда большинство его собратьев
> благополучно вылетает на больших или сложных файлах, это
> парсер продолжает благополучно работать. Тут уж разработчики
> постарались. Даже по беглому взгляду на его код можно сказать,
> что над ним хорошо постарались. Код красиво отформатирован,
> содержит много комментариев. А это уже половина успеха.
> Тестирование подтвердило 100%-ный успех. 3-ий по скорости
> парсер, но при этом удобный и очень стабильный. Он еще к
> тому же имеет методы для записи и чтения переменных различного
> типа в XML. Единственное, что может "вспугнуть" - это его
> цена ? 29,95.
>
> 4) TXmlDDocument
> Тоже довольно быстрый, удобный и стабильный парсер. Тоже
> ни разу не вылетал. В общем, никаких жалоб на него нет,
> единственное что плохо, что этот парсер вроде бы как больше
> не поддерживается разработчиками. Первая и единственная
> версия вышла в 2002 году, домашний сайт, указанный на торри
> не открывается. Поиск тоже ничего не дал. А жалко, если
> немного доработать, был бы действительно один из лучших
> парсеров.
>
> 5) TjanXMLParser2
> Как показало тестирование, это самый быстрый парсер. Во
> многом это достигается благодаря ассемблерным вставкам в
> коде. Но на самом деле он не является безоговорочным лидером.
> На файлах с большим количеством нодов он вылетает вместе
> с программой, что наводит на мысль об ошибках в ассемблерном
> коде. Еще этот парсер имеет поддержку XSL и XPath, хотя
> с тем, как это реализовано, я не разбирался, поскольку пока
> практически это не использую. Трудно сказать, насколько
> большая доработка требуется этому парсеру, но то, что требуется
> - это факт. Главное, что это возможно, так как код открыт
> и доступен.
>
> На данный момент это все, что я могу вкратце сказать о тестированных
> мной парсерах. Остальное покажет практика. В общем, думаю,
> что вопрос о том, какой парсер лучше, еще открыт, так как
> практически все вышеперечисленные парсеры (кроме TXMLDocument)
> заслуживают на внимание и у каждого из них есть свои преимущества.
>

Сама ветка:
http://forum.sources.ru/index.php?showtopic=81572&view=findpost&p=600614

← →
atruhin1 (2008-06-24 15:06) [31]

> В таком случае вообще странен сам выбор xml как формата.
> Купить бмв и ездить на нем заставляя жену на веревочке такать
> машину.

А тебе не кажется, что выбор не всегда от тебя зависит? Тем более что XML
разрабатывался, в первую очередь, как средство обмена данными, а судя по твоему посту,
если мне нужно предать из 1С 10 строк, я должен изобрести свой формат, так как
XML - это слишком круто!

> > Тест 2. Файл размером 1,75 МБ.

Это просто смешно. Мне для тестирования прикладного приложения даны XML-файлы порядка 70 мегабайт. MSXML, полет нормальный.

А тебе не кажется ...

А тебе не кажется, что смысл того поста бы иной и в нем ни намека не было на свой формат?

так как XML - это слишком круто!

Это говорят люди с синдромом xml фобии.
Я же использую его очень активно. Мне просто было непонятно почему многоие не пользуются xpath.

Тем более что XML разрабатывался, в первую очередь, как средство обмена данными

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

> Rouse_ © (24.06.08 11:47) [30]

Это я уже видел. К сожалению, устаревшая статья. Но как ни странно, подобной русскоязычной при быстром поиске не нашлось.

А ещё вот такая библиотека есть: http://www.philo.de/xml/

XML-парсеры для Delphi. Найти похожие ветки