LINUX.ORG.RU

TinyXML2 10.1.0 и 11.0.0

 , , ,


0

2

9 и 16 марта, после более года разработки, состоялись выпуски 10.1.0 и 11.0.0 небольшой, простой и эффективной C++ библиотеки TinyXML2, предназначенной для парсинга XML и распространяемой по лицензии Zlib.

Список изменений:

  • Устранена уязвимость CVE-2024-50615, связанная с проблемой разбора кодировок символов.
  • Исправлены некоторые внутренние типы (int -> size_t), в связи с чем нарушена совместимость c ABI прежних версий.
  • Исправлены ошибки сборки и опечатки.

Пример использования:

{
    XMLDocument doc;
    doc.LoadFile( "dream.xml" );

    // Structure of the XML file:
    // - Element "PLAY"      the root Element, which is the
    //                       FirstChildElement of the Document
    // - - Element "TITLE"   child of the root PLAY Element
    // - - - Text            child of the TITLE Element

    // Navigate to the title, using the convenience function,
    // with a dangerous lack of error checking.
    const char* title = doc.FirstChildElement( "PLAY" )->FirstChildElement( "TITLE" )->GetText();
    printf( "Name of play (1): %s\n", title );

    // Text is just another Node to TinyXML-2. The more
    // general way to get to the XMLText:
    XMLText* textNode = doc.FirstChildElement( "PLAY" )->FirstChildElement( "TITLE" )->FirstChild()->ToText();
    title = textNode->Value();
    printf( "Name of play (2): %s\n", title );
}

>>> Подробности на github.com

★★★★★

Проверено: CrX ()
Последнее исправление: CrX (всего исправлений: 1)

Хм... XML... Я думал это только для легаси осталось, для новых проектов только JSON или что-то мудрее, хотя бы за отсутствие пердолинга с массивами.

drfaust ★★★★★
()

Отличная шустрая реализация. Много лет использую в своих проектах, но давно не обновлялся.

andreyu ★★★★★
()
Ответ на: комментарий от drfaust

XML... Я думал это только для легаси осталось

Так и есть.

firkax ★★★★★
()

Не нужно, есть pugixml

annulen ★★★★★
()
Ответ на: комментарий от drfaust

Хм… XML… Я думал это только для легаси осталось, для новых проектов только JSON или что-то мудрее, хотя бы за отсутствие пердолинга с массивами.

Есть нюанс: XML — это изначально язык разметки (например, для XHTML, DocBook, FB2 и т.п.), а JSON в таких целях будет использовать только наркоман.

annulen ★★★★★
()
Ответ на: комментарий от dataman

Тогда стоит попробовать перейти на pugixml 1.15.

В свое время я рассматривал варианты перехода c tinyxml. Выбор делал из pugixm и tinyxml2. В итоге выбрал tiynuxml2.

andreyu ★★★★★
()
Ответ на: комментарий от annulen

Использовать для разметки xml тоже будет только наркоман. Одни из таких наркоманов уже породили нелепое XHTML, но к счастью его удалось закопать.

firkax ★★★★★
()
Ответ на: комментарий от drfaust

Хм... XML... Я думал это только для легаси осталось

Ну что ты, XML никуда не денется.

Rodegast ★★★★★
()
    const char* title = doc.FirstChildElement( "PLAY" )->FirstChildElement( "TITLE" )->GetText();

Гм… А что будет, если у элемента PLAY нет TITLE?

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

json появился как грязный хак в js, чтобы не использовать xml, вызывался eval('tst.json'), если комменты есть в js почему они исчезли в json?

s-warus ★★★☆
()
Ответ на: комментарий от rtxtxtrx

toml/yaml. в json нет комментариев, поэтому он тоже устаревший

В XML тоже нет комментариев. Есть договоренность, что определенное поле не нужно обрабатывать. Но оно никуда не девается, и при желании его можно обработать, и даже поместить туда важную инфу. То же самое ты можешь сделать и в JSON.

windows10 ★★★★★
()
Ответ на: комментарий от windows10

В XML тоже нет комментариев.

Так ведь есть.

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

Как будто в других языках иначе. Некоторые системы используют данные внутри комментариев для разных целей от директив компилятору/линкёру до автоматического построения документации.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от drfaust

Я думал это только для легаси осталось, для новых проектов только JSON или что-то мудрее, хотя бы за отсутствие пердолинга с массивами.

Формат XML овердофига где используется и ещё лет 20 будет использоваться, так что даже как легаси с ним дело иметь будут ещё очень долго.

В новых проектах тоже используется, особенно во всяких корпоративных документооборотах и около.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от s-warus

Это JS object notation. Там лишь скалярные типы (null, bool, number, string) и объекты (хеши, словари, ассоциативные массивы - в других языками) с массивами. Потому что - это не js, это лишь определенные выражения. И у json тоже есть проблемы с совместимостью: где-то разрешены только {} и [], а где-то можно любой из перечисленных типов хранить. А так же почти у всех этих JSON и ML есть роблемы с хранением всяких int, uint16, long long и тп, так как JSON хранит универсаьные числа, объединяющие float и int, а так же проблемы с точностью. Есть расширения JSON типа BSON более типизированные

rtxtxtrx ★★★
()
Ответ на: комментарий от rtxtxtrx

Пользователи и имплементаторы yaml должны погибнуть в пуках. В этом говне миллиард уязвимостей и скрытых преобразований, которые меняют например код Норвегии на false. А если использовать кавычки, то ВНЕЗАПНО формат превращается в JSON, только с пробелами вместо {}

https://habr.com/ru/post/710414/:

JSON прост. Вся спецификация JSON состоит из шести синтаксических диаграмм. Это простой формат данных с простым синтаксисом, и больше в нём нет ничего. В отличие от него, YAML сложен. Настолько сложен, что его спецификация состоит из десяти глав с разделами, пронумерованными на четыре уровня в глубину, и отдельным списком ошибок.

Спецификация JSON не разделена на версии. В 2005 году в неё внесены два изменения (удаление комментариев и добавление научной записи для чисел), но с тех пор она заморожена (уже почти два десятка лет). Спецификация YAML имеет версии. Последняя версия довольно свежая, 1.2.2 от октября 2021 года. YAML 1.2 существенно отличается от 1.1: один и тот же документ в разных версиях YAML может парситься по-разному. Ниже мы увидим много примеров этого.

Переход YAML с версии 1.2.1 на 1.2.2 потребовал многолетних усилий команды специалистов:

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

загрузка непроверенного YAML-документа в общем случае небезопасна, потому что может привести к исполнению произвольного кода.

разработчики YAML-библиотеки языка Go приняли решение реализовать собственный вариант, находящийся примерно посередине между YAML 1.1 и 1.2; в зависимости от контекста парсер ведёт себя по-разному

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 3)
Ответ на: комментарий от drfaust

В json нет схем, нет стандартов, нет кучи всего, что есть в xml.

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

Например: https://www.iso20022.org/

beck ★★★★
()
Ответ на: комментарий от beck

а XML – для описания стандартов документов.

А потом появляется такой звиздец как SOAP, где перечисление неймспейсов занимает страницу, сам документ весит 8 КБ и всё чтобы передать один единственный bool

В json нет схем

Мы просто написали свой валидатор, который использует схему, написанную на самом JSON

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от PPP328

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

загрузка непроверенного YAML-документа в общем случае небезопасна, потому что может привести к исполнению произвольного кода.

🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡/10

rtxtxtrx ★★★
()
Ответ на: комментарий от beck

В json нет схем, нет стандартов, нет кучи всего, что есть в xml.

Ну, посмотрели на эту кучу всего и сказали: „Ну, нахер, уж лучше как-нибудь так“. И это было весьма разумно.

ugoday ★★★★★
()
Ответ на: комментарий от rtxtxtrx

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

В статье подробно расписано какой пц этот ваш YAML. И эти люди запрещают ковыряться в носу считают XML плохим? Да он в 100500 раз удобнее и прозрачнее YAML выходит.

praseodim ★★★★★
()
Ответ на: комментарий от praseodim

он обычный. простой язык с простым синтаксисом. то очень субъективное мнение, причем не автор_ки с хабра, а перевод статьи голландца, который пишет на rust (тут уже понятно, что с ним что-то не так).

rtxtxtrx ★★★
()
Ответ на: комментарий от praseodim

он в 100500 раз удобнее

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

ugoday ★★★★★
()
Ответ на: комментарий от rtxtxtrx

простой язык с простым синтаксисом.

простой

спека на десятки страниц

простой

куча версий, которые парсятся разными парсерами по разному и нет возможности указать версию документа

простой

PPP328 ★★★★★
()
Ответ на: комментарий от s-warus

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

Minoru ★★★
()
Ответ на: комментарий от beck

В json нет схем, нет стандартов, нет кучи всего, что есть в xml.

Как хорошо что весь этот ненужный мусор там отсутствует.

XML – для описания стандартов документов.

Нет, он для имитации бурной деятельности и размножения всяческой графомании.

firkax ★★★★★
()
Ответ на: комментарий от PPP328

Не позорься. Парсер этот пишется с помощью 100-200 строк с помощью рекурсвиного спуска

https://github.com/hackebrot/poyo/blob/main/src/poyo/parser.py

Тот растоман-велосепидист не осилил свой парсер yaml написать, а использовать чужие не позволяли идеологические причины

rtxtxtrx ★★★
()
Ответ на: комментарий от PPP328

Ну вообще никто не заставляет писать парсер ко всей той графомании что описана в так называемом стандарте yaml, никто не заставляет реализовывать уязвимости или какие-то преобразования. Я, когда надо было парсить yaml-файлы, ограничился просто парсингом древовидной структуры нод вида key=>value (запоминая какие были отступы и считая любое его увеличение за начало новой вложенности). «Стандарт» даже не читал, судя по отзывам там и правда какая-то дичь.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

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

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от beck

В json нет схем, нет стандартов, нет кучи всего, что есть в xml.

А это что? JSON Schema уже сейчас используется в OpenApi, который кстати в разы проще чем WSDL.

amm ★★
()
Ответ на: комментарий от firkax

Причем здесь парсер? У него конкретные примеры, когда пользователь может прострелить себе ногу из-за «удобств» формата.

amm ★★
()
Ответ на: комментарий от amm

Может быть у него и есть какие-то примеры, но сюда он их не предоставил, так что не будем фантазировать. Лично я не вижу что там можно прострелить, если рассматривать yaml тупо как текстовое key-value дерево. Он в таком случае оказывается эквивалентен json-у у которого все значения типа «строка», только визуальное представление другое.

firkax ★★★★★
()
Ответ на: комментарий от amm

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от hobbit

Судя по стрелочке указателя, будет что то интересное. Вообще перед этим надо было провалидировать файл, и потом через XPath выбрать ноду, вместо ручного костыляния селектора. Надеюсь в TinyXML2 все для этого есть, лол.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от firkax

Ужас, что за творение графоманских веб-макак. Вот прям листаю страницу за страницей, а там вода, вода, вода.

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

Вопрос: а спеку по wsdl и xsd ты читал? И много лучше оно чем Json schema?

amm ★★
()
Последнее исправление: amm (всего исправлений: 1)
Ответ на: комментарий от firkax

Ну ты получается парсил yaml-подобный файл, а не yaml. Другой парсер уже по другому прочтет. Сомнительно это все. Так можно было и полностью свой формат сделать.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от amm

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

firkax ★★★★★
()
Ответ на: комментарий от amm

Вопрос: а спеку по wsdl и xsd ты читал? И много лучше оно чем Json schema?

Нет конечно, я всякую чушь не читаю. Эти так называемые «схемы» не нужны в любом их виде. Чисто способ пографоманить кодингом.

firkax ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Другой парсер уже по другому прочтет.

Да и пофиг.

Так можно было и полностью свой формат сделать.

Ну меня попросили реализовать конфиг в виде yaml, я и реализовал. Снабдив реализацию исчерпывающей спецификацией. То, что оно не совпадает с какими-то простынями на английском, не заботило ни меня, ни тех кто этим будет пользоваться, они тоже их не читали. Можно было, конечно, придумать другое название, но зачем, если всем привычно именно такое.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Да и пофиг.

Так и запишем, что для обмена информацией yaml не годится. В отличие от xml.

Вот, совершенно конкретный рабочий пример для чего применяется XML сейчас на практике.

Выгрузило какое-нибудь госведомство статистику в xml - формате, например патентное ведомство: https://www1.fips.ru/AuthorityFile/ (внутри zip-файлов xml) и Схема с DTD есть в описании https://www.wipo.int/en/web/standards/authority-file-guidelines

Формат стандартизирован между большинством патентных ведомств в мире. Данные можно стандартно верифицировать и парсить и использовать разными библиотеками в разных языках и средах.

Можно конечно сказать, что лучше бы вместо XML там был JSON или XXXX, но важно, чтобы это XXXX было стандартизировано и однозначно понималось. Ещё бы хорошо иметь наборы библиотек, чтобы не изобретать велосипед с разбором формата.

Можно было, конечно, придумать другое название, но зачем, если всем привычно именно такое.

Да на здоровье, просто странно слышать, что это может заменить xml. Не может.

Естественно, никто не мешает выдумывать ни с чем не совместимый свой конфиг для своего приложения. Более того, xml для этой цели может быть очень избыточен и не нужен. Но и использовать этот yaml для чего-то большего, чем конфиг к твоей программе неправильно.

Нет конечно, я всякую чушь не читаю. Эти так называемые «схемы» не нужны в любом их виде. Чисто способ пографоманить кодингом.

Чтобы запилить свой конфиг-файл они не нужны. Чтобы обмениваться между совершенно разными потребителями информации крупными объёмами данных, как показывает практика, нужны.

anonymous_incognito ★★★★★
()
Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от anonymous_incognito

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

ugoday ★★★★★
()
Ответ на: комментарий от amm

А это не стандарт, в отличие от xml.

Не надо путать передачу записей между микросервисами и передачу допустим аккредитивов между банками.

beck ★★★★
()
Ответ на: комментарий от firkax

«Некоторые вещи нам непонятны не потому, что круг наших понятий узок, но потому, что сии вещи не входят в круг наших понятий.»

beck ★★★★
()
Ответ на: комментарий от PPP328

А потом появляется такой звиздец как SOAP, где перечисление неймспейсов занимает страницу, сам документ весит 8 КБ и всё чтобы передать один единственный bool

Откуда и куда передаётся этот самый bool?

Мы просто написали свой валидатор, который использует схему, написанную на самом JSON

Отлично. Вот вы сделали документ, например выпустили гарантию и передали ея в другой банк. Как они проверят ваш документ? А если у вас корреспондентов тысячи? Или даже десятки тысяч?

beck ★★★★
()
Ответ на: комментарий от beck

Откуда и куда передаётся этот самый bool?

От кинооборудования. У одного из производителей протокол на SOAP. Ответ на запрос «включен ли режим по расписанию» занимает более 8 КБ и из полезной информации имеет только один bool (Да/нет)

PPP328 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.