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)
Ответ на: комментарий от beck

И в чем отличие? Просто кто-то когда-то сделал протокол для передачи аккредитивов на xml. Могли и на json сделать, а особо упоротые и на yaml :) Некоторые и на idoc наяривают, но это не значит, что у какого-то формата есть технические преимущества, просто так исторически сложилось.

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

Если ваш SOAP так хорош, то что ж тогда межбанковское и межзаказчиковое общение идет обычно не через него, а через внутри-SAP-овские «формы», самописный костыль, который стал отраслевым стандартом. ERP -> Purchase Order Form -> EDI 850 -> CRM -> EDI 855 -> ERP. Вот эти самые EDI - это и есть самописное говно, по которому общаются все, у кого есть Oracle.

ISA*00*          *00*          *ZZ*PARTNERID    *ZZ*SUPPLIERID   *YYMMDD*HHMM*U*00401*000000001*0*P*:
GS*PO*PARTNERID*SUPPLIERID*YYMMDD*HHMM*1*X*004010
ST*850*0001
BEG*00*NE*123456789**20201015
REF*PD*PO12345
DTM*002*20201020
N1*ST*BUYER NAME
N3*123 BUYER STREET
N4*BUYER CITY*NY*12345
N1*SN*SUPPLIER NAME
N3*456 SUPPLIER STREET
N4*SUPPLIER CITY*CA*67890
PO1*1*10*EA*19.99**IN*ABC123*VN*XYZ789
PID*F***Product Description
PO4*10*CT*10*75*20
CTT*1
SE*20*0001
GE*1*1
IEA*1*000000001
PPP328 ★★★★★
()
Ответ на: комментарий от beck

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

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

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

Может где и есть такие девиации, но межбанковское взаимодействие, которое я видел, идёт исключительно через xml.

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

Очевидно стандарты были приняты во времена, когда модно было везде пихать XML и городить развесистые иерархии классов. Обе идеи оказались неудачные, но слезть с этой иглы будет не просто. Зато хоть не на коболе.

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

слезть с этой иглы будет не просто

…но без трубки Холмса Ватсон уже не мог :)

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

Я с самого начала написал, что есть разные задачи, которые решают разные инструменты.

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

Ты умеешь отличать передачу информации от приложения к приложению и передачу информации от банка к банку?

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

Капитан Очевидность напоминает, что банковское приложение — это тоже приложение. Как и все остальные. Ну, если смыть дешёвый пафос «работать в нашем банке большая честь».

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

Полагаю, что он намекает на DTD, XSD, XSLT, XPath, XMLNS и прочую половину лиспа, которую накрутили вокруг языка разметки. И прямо скажем, если очень хочется, чтобы эта задача так и решалась, лучше бы прямо на лиспе и писали бы.

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

Ага, классно же, когда взаимодействие построено так, что тебе заранее неизвестен формат ответа, по их процессингу надо скачивать каждый раз из инета схему, которая лежит в xmlns/xsd, валидировать ответ согласно этой схеме, но в каком поле лежит нужна тебе информация это тоже не говорит.

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

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

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

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

Понимаешь, многие люди не работают в банковской сфере и им до фонаря этот стандарт. Раз ты эксперт в этой области, то мог бы рассказать, что там такое, что невозможно описать в json.

И да, оказывается в json там тоже можно https://www.iso20022.org/sites/default/files/documents/D7/ISO20022_API_JSON_Whitepaper_Final_20180129.pdf :)

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

Он просто не может принять факт, что время xml уходит и многие конторы переводят поддержку xml в разряд legacy.

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

Опять обобщаешь :) Не все люди мечтают пролезть в начальство.

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

Сознаю, что мой опыт ограничен, как и любой другой, но по-моему, xml перешёл в разряд наследия лет 15 назад. Сейчас везде стандарт де-факто: в качестве языка разметки — yaml, в качестве промежуточного представления/сериализации/обмена данных — json.

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

Сложно назвать дату, когда xml сдал позиции, он и сейчас ещё достаточно популярен, но то что новые протоколы на нем практически не делают, факт.

И ещё уточнение: всё-таки yaml не для разметки, а для конфигов часто используется. Для разметки markdown популярен :)

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

Моя вина. Именно конфиги и имел в виду. Даже не знаю как это я так опечатался.

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

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

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

А какие популярные альтернативы были? Кроме ASN.1 ничего не вспоминается. Но его тоже никто шибко не хвалит :)

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

Альтернативы для чего? Если для «сделать формат сами не знаем каких данных» - то может и не было, но эта задача сама по себе порочна. А так для каждого применения есть нормальные способы. Для не сильно запутанных конфигов - ini-файлы например (некоторую древовидность больше 2 уровня вложенности им можно добавить с помощью точек в именах секций или полей, как sysctl -a например). Для обмена информацией между двумя демонами - обычно разные двоичные форматы без текстовых названий полей вообще.

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

К слову, а какие претензии к ASN.1. Я его лично никогда не использовал, но судя по документации, выглядит как вещь, которая просто работает. На одном конце записал, на другом — прочитал. Чего ещё надо?

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

Те же что и к xml: излишняя сложность, не полная реализация стандартов в библиотеках.

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

Ну так во времена зарождения xml был популярен обмен упакованными сишными структурами, быстро, но в отладке тяжко)

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

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

json схемы появились буквально вчера и более менее устоявшегося стандарта пока нет. Переезд на схемы json произойдёт, но только когда стандарт устоится. Глядишь и пространства имён появятся как стандарт, а не как сейчас.

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

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

только скобочки иначе расставлены.

А каких ещё отличий ты хотел? Все форматы сериализации ассоциативных массивов по сути делают одно и то же. И xml - один из худших способов - куча лишних букв и общая ненаглядность. В json как минимум нет надобности дублировать имя поля в его конце, это наверно самый существенный его плюс.

Что касается всяких схем итд - это отдельная тема по замусориванию представления данных, и ты правильно заметил что её можно натянуть куда угодно. Тем страннее выглядит твоё заявление «в json нет схем» в качестве аргумента к чему-то. Видимо за время этой темы ты всё-таки немного поумнел.

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

Что касается всяких схем итд - это отдельная тема по замусориванию представления данных

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

В json действительно нет схем, как стандарта. Есть некие договорённости делать так-то, не более.

PS отличия в схемах есть, но это совсем другая история, и отдельная большая тема.

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

Вся валидация строится вокруг описания xsd.

Просто любопытно стало. Допустим мы сошли с ума и договорились обмениваться по сети прямоугольными треугольниками в формате XML. Как-то так:

<triangel>
  <side-a>3</side-a>
  <side-b>4</side-b>
  <side-c>5</side-c>
</triangle>

Как будет выглядить xsd для него? Допустим, пространство эвклидово и достаточно сравнить квадрат одной стороны с суммой квадратов двух других.

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

«Способ оформления документов» у нормальных людей записывается в человеко-читаемом виде. Предназначен он для тех, кто будет писать софт для генерации этих документов, и какой там формат (xml, json, txt, csv, jpg или ещё что) тут значения никакого не имеет.

Вот пример: https://www.ietf.org/rfc/rfc2616.txt - тут описывается, как правильно оформить документ под названием «http-запрос» (ну, там не только это описывается, но и это тоже). Авторы бразуеров и http-клиентов смотрели эту спецификацию, когда кодили свои проги.

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

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

Нормальные люди сто лет уже описывают протокол в OpenAPI, из него же порождают клиентов и серверов для работы. После чего все данные создаются, передаются, читаются в нужном (или по крайней мере гарантированно согласованном) формате. Всё. Но приверженцы некротехнологий из 90-х, могут, конечно, упорствовать до конца. Вольному воля.

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

Мир немножко шире, чем передача структур между микросервисами.

Впрочем, я это уже раза четыре повторял.

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

А каких ещё отличий ты хотел?

Например не ходить по дереву наследования, а получить всё сразу в одном месте, используя при этом библиотеки и пространства имён.

Что, однако, хорошо в json схемах, так это возможность семантической валидации документа. В xsd проверяется только синтаксис.

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

Оно и так сразу в одном месте. Твои проблемы от кривого софта, а не от формата. И проверку чего угодно можно сделать хоть в xml хоть в json, то что твой софт это не умеет - это проблемы твоего софта. Походу древнего такого же как xml и писавшегося некомпетентными людьми.

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

json схемы появились буквально вчера и более менее устоявшегося стандарта пока нет. Переезд на схемы json произойдёт, но только когда стандарт устоится.

Как у тебя время сжимается: первый драфт вышел 15 лет, последняя ревизия в 2022, а для тебя это буквально вчера.

Глядишь и пространства имён появятся как стандарт, а не как сейчас.

Что не устраивает в текущем стандарте? Слишком просто в сравнении с xml? :)

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

То есть всё-таки переводишь с xml на json и вся боль из-за того что работать заставляют? :))

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

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

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

Так поделись своим опытом, чем ты пользовался для просмотра массива байт. Мой опыт в том, что чаще всего приходилось всё делать руками.

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