Пример XML-файла

Если вы тестируете API, то должны знать про два основных формата передачи данных:

Сегодня я расскажу вам про XML.

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

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

Содержание

Как устроен XML
Теги
Корневой элемент
Значение элемента
Атрибуты элемента
XML пролог
XSD-схема
Составляем свой запрос
Well Formed XML
Есть корневой элемент
У каждого элемента есть закрывающийся тег
Теги регистрозависимы
Правильная вложенность элементов
Атрибуты оформлены в кавычках
Итого
Рабочий стол
Входной XML-документ
Онлайн-сервис преобразования документов и отчётов из Excel и аналогов в электронные форматы XML (в том числе для ЭДО) — XMLdoc
Нормативная база
Введение в XML¶
Структура XML¶
Правила синтаксиса (Валидность)¶
Сущности¶
Поиск информации в XML файлах (XPath)¶
Кодировки¶
XSD схема¶
Sample Employee XML file
Simple XML file for Student details
Sample XML With Multiple Records
Что такое эти ваши json и xml?
Знакомство в python
Мой опыт, заключение
Исправление невалидных XML-файлов¶
Удаление лишних блоков(абзацев) из XML по заданному условию¶
Суть проблемы¶
Решение проблемы¶
Работа с файлами отчетов Росстата¶

Как устроен XML

Возьмем пример из документации подсказок Дадаты по ФИО:

И разберемся, что означает эта запись.

Корневой элемент

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.

Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».

Он мог бы называться по другому:

Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.

Значение элемента

Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.

Внутри — значение запроса.

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

См также:
Что тестировщику надо знать про панель разработчика — подробнее о том, как использовать консоль.

Но оба значения идут

кавычек. В XML нам нет нужды брать строковое значение в кавычки (а вот в JSON это сделать придется).

Атрибуты элемента

У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде

название_атрибута = «значение атрибута»

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

Давайте разберем эту запись. У нас есть основной элемент party.

У него есть 3 атрибута:

Внутри party есть элементы field.

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;
— у него есть элементы field;
— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. Т З может устареть, а код будет актуален.
— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.

В общем, любой подход имеет право на существование. Надо смотреть по проекту, что будет удобнее именно вам. У меня в примере неговорящие названия элементов — все как один будут field. А вот по атрибутам уже можно понять, что это такое.

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:

У элемента attribute есть атрибуты:

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

XML пролог

Иногда вверху XML документа можно увидеть что-то похожее:

Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.

UTF-8 — кодировка XML документов по умолчанию.

XSD-схема

Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».

Если мы создаем SOAP-метод, то указываем в схеме:

Поэтому зачем запускать сложную процедуру, если запрос заведом «плохой»? И выдавать ошибку через 5 минут, а не сразу? Валидация по схеме помогает быстро отсеять явно невалидные запросы, не нагружая систему.

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

Да-да, в идеале у нас есть подробное ТЗ, где всё хорошо описано. Но увы и ах, такое есть не всегда. Иногда ТЗ просто нет, а иногда оно устарело. А вот схема не устареет, потому что обновляется при обновлении кода. И она как раз помогает понять, как запрос должен выглядеть.

Итого, как используется схема при разработке SOAP API:

Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:

А в WSDl сервиса она записана еще проще:

Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:

А еще в схеме можно ссылаться на другую схему, что упрощает написание кода — можно переиспользовать схемы для разных задач.

См также:
XSD — умный XML — полезная статья с хабра
Язык определения схем XSD — тут удобные таблички со значениями, которые можно использовать
Язык описания схем XSD (XML-Schema)
Пример XML схемы в учебнике
Официальный сайт w3.org

Составляем свой запрос

Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!

Что, если я хочу, чтобы мне вернулись только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:

В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:

Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. « Женский» по английски будет FEMALE, в документации также. Итого получили:

Ненужное можно удалить. Если нас не волнует количество подсказок, параметр count выкидываем. Ведь, согласно документации, он необязательный. Получили запрос:

Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))

Well Formed XML

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. X ML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

См также:
Сообщения об ошибках — тоже документация, тестируйте их! — зачем тестировать сообщения об ошибках

Есть корневой элемент

Нельзя просто положить рядышком 2 XML и полагать, что «система сама разберется, что это два запроса, а не один». Не разберется. Потому что не должна.

И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:

Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!

У каждого элемента есть закрывающийся тег

Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.

Но тут стоит заметить, что тег может быть один. Если элемент пустой, мы можем обойтись одним тегом, закрыв его в конце:

Это тоже самое, что передать в нем пустое значение

Итого — если есть открывающийся тег, должен быть закрывающийся. Либо это будет один тег со слешом в конце.

Для тестирования удаляем в запросе любой закрывающийся тег.

Теги регистрозависимы

Как написали открывающий — также пишем и закрывающий. Т ОЧНО ТАК ЖЕ! А не так, как захотелось.

А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным

Правильная вложенность элементов

Элементы могут идти друг за другом

Один элемент может быть вложен в другой

Но накладываться друг на друга элементы НЕ могут!

Атрибуты оформлены в кавычках

Даже если вы считаете атрибут числом, он будет в кавычках:

Для тестирования пробуем передать его без кавычек:

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

Хранение данных — это когда XML встречается внутри кода. Его легко понимает как машина, так и человек. В формате XML можно описывать какие-то правила, которые будут применяться к данным, или что-то еще.

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

Что такое XML
Учебник по XML
Изучаем XML. Эрик Рэй (книга по XML)
Заметки о XML и XLST

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Время на прочтение

В сети доступно масса документации по языку XSL. Данный раздел не претендует на роль документации по языку, а лишь кратко, по шагам объясняет, как создать свой XSLT-шаблон.

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

Рабочий стол

Определим, что нам нужно для работы:

У меня входной XML документ выдает CMS-система, в которой каждая страница с материалом собирается в XML-дерево.

К XHTML-макету никаких ограничений нет. Есть лишь определенные рекомендации по верстке, которые позволят значительно сэкономить время на формирование шаблона.

Хотя, как показала практика, этот механизм довольно глючный (мне пришлось пользовать IE). Лучше воспользоваться средствами XML-парсинга языка, на котором написана CMS-система. Я использую Parser (на нем, вообщем-то, у меня вся система и работает).

Входной XML-документ

Для начала разберемся со входным XML-документом. Для того, чтобы использовать XSL нужно иметь полное представление о его структуре.

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

— корневой элемент документа (можно придумать свое имя). Атрибуты:

Приглашаем вас попробовать уникальный разработанный нами

Онлайн-сервис преобразования документов и отчётов из Excel и аналогов в электронные форматы XML (в том числе для ЭДО) — XMLdoc

Наша конвертация не требует жёсткого формата исходного Excel-документа, поскольку данные в нужный XML-документ собираются не по конкретным ячейкам листа Excel, а по опорным заголовкам. Фактически можно передать Excel-документ, сформированный любой системой или вручную, — главное, чтобы Excel-документ имел вид нужного документа.

Пока онлайн-сервис работает в режиме тестовой эксплуатации, поэтому просим вас внимательно контролировать результаты конвертаций и сообщать о выявленных проблемах.

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

Применение одного электронного формата для различных форм документов объясняется тем, что указанный электронный формат является универсальным, достаточно масштабным, объединяющим в себе всю логику электронного взаимодействия контрагентов и необходимые для этого данные. Однако это порождает некоторые сложности при конвертации конкретной, привычной нам, формы печатного документа для контрагента в такой электронный формат — в печатном документе полей на порядок меньше, чем в описании электронного формата. В зависимости от вашей ситуации и рода деятельности далеко не все «ветки структуры» электронного документа используются. Верно и обратное — не вся информация из соответствующих печатных форм документов может быть передана в указанный электронный формат «по умолчанию».

Наши примеры документов мы постарались сделать заточенными под определенные ситуации — есть примеры и для маркировки, и для услуг, и для импортированных товаров. Но, обращаем ваше внимание на то, что предложенные примеры (особенно если это не электронные счета-фактуры и электронные УПД, которые уже имеют широкое распространение) — только лишь возможные варианты передачи необходимых данных в соответствии с данным электронным форматом, не обязательно полностью применимые для вашей ситуации. Где-то предложенная нами, передаваемая в электронном документе, информация может оказаться излишней, а где-то у покупателей/заказчиков или у продавцов/исполнителей существуют дополнительные требования и предполагается «расширение» формата для передачи других необходимых данных (коды товаров, коды для внутренней системы и т.п.).

Нормативная база

Проверяйте ваши XML-файлы в нашем

Это проверка всех актуальных XML-форматов для налоговой и ЭДО с автоопределением типа документа

Это быстро, наглядно и конфиденциально

Если вам нужна помощь с настройкой передачи ваших данных в форматы XML/чтения данных из форматов XML — обращайтесь, всегда сможем помочь.

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

Введение в XML¶

XML ( англ. e Xtensible Markup Language) — расширяемый язык разметки,
предназначенный для хранения и передачи данных.

Простейший XML-документ выглядит следующим образом:

Первая строка — это XML декларация. Здесь определяется версия XML (1.0) и кодировка файла. На следующей строке описывается корневой элемент документа (открывающий тег). Следующие 4 строки описывают дочерние элементы корневого элемента ( , , , ). Последняя строка определяет конец корневого элемента (закрывающий тег).

Документ XML состоит из элементов (elements). Элемент начинается открывающим тегом (start-tag) в угловых скобках, затем идет содержимое (content) элемента, после него записывается закрывающий тег (end-teg) в угловых скобках.

Информация, заключенная между тегами, называется содержимым или значением элемента: . Т.е. элемент принимает значение . Элементы могут вообще не принимать значения.

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

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

Структура XML¶

XML документ должен содержать корневой элемент. Этот элемент является «родительским» для всех других элементов.

Все элементы в XML документе формируют иерархическое дерево. Это дерево начинается с корневого элемента и разветвляется на более низкие уровни элементов.

Все элементы могут иметь подэлементы (дочерние элементы):

Правила синтаксиса (Валидность)¶

Структура XML документа должна соответствовать определенным правилам.
XML документ отвечающий этим правилам называется валидным (англ.
Valid — правильный) или синтаксически верным. Соответственно, если
документ не отвечает правилам, он является невалидным .

Основные правила синтаксиса XML:

Открывающий и закрывающий теги должны определяться в одном регистре:

Это неправильно
Это правильно

Некорректная вложенность
Корректная вложенность

В большинстве XML файлов отчетов для ФНС корневым элементом является . После закрывающего тега больше ничего быть не должно.

Корректная запись
Некорреткная запись

Сущности¶

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

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

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

Чтобы ошибки не возникали, нужно заменить символ на его
сущность. В XML существует 5 предопределенных сущностей:

Только символы и строго запрещены в XML. Символ допустим, но лучше его всегда заменять на сущность.

Таким образом, корректными будут следующие формы записей:

В последнем примере английские двойные кавычки заменены на французские кавычки («ёлочки»), которые не являются служебными символами.

Поиск информации в XML файлах (XPath)¶

XPath ( англ. X ML Path Language) — язык запросов к элементам
XML-документа. X Path расширяет возможности работы с XML.

XML имеет древовидную структуру. В документе всегда имеется корневой
элемент (инструкция к дереву отношения не имеет).
У элемента дерева всегда существуют потомки и предки, кроме корневого
элемента, у которого предков нет, а также тупиковых элементов (листьев
дерева), у которых нет потомков. Каждый элемент дерева находится на
определенном уровне вложенности (далее — «уровень»). У элементов на
одном уровне бывают предыдущие и следующие элементы.

Это очень похоже на организацию каталогов в файловой системе, и строки
XPath, фактически, — пути к «файлам» — элементам. Рассмотрим пример
списка книг:

XPath запрос вернет следующий результат:

Сокращенная форма этого запроса выглядит так: .

Everyday Italian
Giada De Laurentiis
2005
30.00

В приведенной ниже таблице представлены некоторые выражения XPath и
результат их работы:

Кодировки¶

И еще один важный момент, который стоит рассмотреть — кодировки. Существует множество кодировок, о них подробнее можно прочитать в статье Набор
символов.

Самыми распространенными кириллическими кодировками являются и . Последняя является одним из стандартов, но большая часть ФНС отчетности имеет кодировку .

В XML файле кодировка объявляется в декларации:

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

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

Если ничего не помогает, вполне возможно, что файл был поврежден.

XSD схема¶

XML Schema — язык описания структуры XML-документа, его также называют XSD. Как большинство языков описания XML, XML Schema была задумана для определения правил, которым должен подчиняться документ. Но, в отличие от других языков, XML Schema была разработана так, чтобы её можно было использовать в создании программного обеспечения для обработки документов XML.

После проверки документа на соответствие XML Schema читающая программа может создать модель данных документа, которая включает:

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

Подробнее об XSD смотрите:

The sample XML(Extensible Markup Language) file will provide you file that contains XML data that will be used for your testing purpose. X ML files look like HTML files but XML has its custom tags. X ML files are also viewed in the browser and it is human and machine-readable. It is editable by any text editor.

XML files are stander ways to store and exchange data between the internet like JSON.

You can find below a list for sample files that will be free to use, download, and modify as you want.

Here I have provided you a sample file for your testing used and you can modify as much time you want.

Sample XML URL – https://www.learningcontainer.com/wp-content/uploads/2020/03/Sample-XML-Files.xml

Sample Employee XML file

Here, Employee data was added into the file that will help you to test accordingly and you don’t need to create a new file for that.

Above file URL – https://www.learningcontainer.com/wp-content/uploads/2020/03/Sample-employee-XML-file.xml

Simple XML file for Student details

Some Student Details Added for testing. I have created as per my understanding and knowledge. you can modify as you need and update as per your requirements.

Above file URL – https://www.learningcontainer.com/wp-content/uploads/2020/03/Simple-XML-file-for-student-details.xml

Sample XML With Multiple Records

Here, You can get a large XML file, many records, and multiple data. That will help when you need to testing for large data.

Sample XML URL – https://www.learningcontainer.com/wp-content/uploads/2020/03/Sample-XML-With-Multiple-Records.xml

Checkout Sample JSON File for your Testing.

Let me add something about XML.

XML is a Markup Language as an HTML(Hypertext Markup Language).

it was stored and transport data.

XML Contents sender/receiver Information.

The XML has Heading and Body.

XML has no predefined tags.

Check out below XML example:

Let us know if we forgot to add the files that you want.

— Любая -Финансы, бухгалтерия, аудит- Любая —

Сразу оговорюсь, что это лишь мой опыт, поэтому все будет объяснять на понятном МНЕ языке, но критику приветствую и всегда буду рада комментариям 🙂

Что такое эти ваши json и xml?

По сути два этих формата используются для передачи и хранения информации. Разница в том, что json можно преобразовать в объект JavaScript и обратно.

А вот с xml так не получится, потому что он используется в основном для кодирования файлов в читаемом формате.

В этом json есть атрибут «Персонал», в котором хранится информация о всех сотрудниках, с краткой информацией ФИО и возраст.

В нашем примере есть пары: «Имя»-«Саша», «Фамилия»-«Петров» и тд. Они находятся внутри общего json-объекта, и принадлежать паре «Персонал» и словарь json-объектов с описанием сотрудников.

Аналогичный набор xml будет выглядеть так:

Согласитесь: с виду, все вполне понятно, есть небольшие отличия в синтаксисе и все? Я тоже так думаю и даже скажу, что json можно легко преобразовать в xml.

Xml имеет свою кодировку, которую важно учитывать при создания файлов. ( Учитесь на моих ошибках). Также есть xsd или xml-схема, которая создается для проверки правильности xml и в каком-то смысле упрощения ее создания.

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

Знакомство в python

Для начала возьмем на обработку json, точнее попробуем его создать

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

Но проще всего менять значения в самом словаре и загружать его в json-файл.

Здесь у нас идет обращения к объектам сначала первый объект «personal». Потом мы выбираем первого сотрудника, поэтому индекс 0 и название значения «Age».

Соответственно далее все уже зависит от ваших задач и желаний. Теперь познакомимся и с xml.

import xml.etree. ElementTree as ET # Загружаем библиотеку

# Создаем основной элемент, в который будем добавлять последующие
data_xml = ET. Element(‘personal’)

# Добавляем первого сотрудника
employee = ET. SubElement(data_xml, ’employee’)
# Добавляем вложенные элементы в созданый employee
employee_n = ET. SubElement(employee, ‘Name’)
employee_n.text = «Саша»
employee_l = ET. SubElement(employee, ‘LastName’)
employee_l.text = «Петров»
employee_a = ET. SubElement(employee, ‘Age’)
employee_a.text = «34»

# Добавляем второго сотрудника
employee = ET. SubElement(data_xml, ’employee’)
# Добавляем вложенные элементы в созданый employee
employee_n = ET. SubElement(employee, ‘Name’)
employee_n.text = ‘Вася’
employee_l = ET. SubElement(employee, ‘LastName’)
employee_l.text = ‘Иванов’
employee_a = ET. SubElement(employee, ‘Age’)
employee_a.text = ’37’

# Посмотрим получившийся xml
print(ET.dump(data_xml))

Тут мы создаем вложенный элемент методом SubElement, в котором указываем элемент, куда добавляем, и название. То есть в элемент data_xml добавляем вложенный элемент employee, а в него уже Name, LastName, Age. И с помощью метода text добавляем сами значения.

Соответсвенно, как и в прошлом случае мы можем обратиться к элементам и изменить их.

Все выглядит достаточно просто. Мы научились создавать, изменять, выгружать в файл json и xml. В следующем разделе, я опишу свой пример создания xml-файла с json внутри.

Мой опыт, заключение

Я взяла готовый xml, загрузила его и не поняла. Во-первых, получилось не с первого раза.

Во-вторых, был только один тег.

С этого момента все стало еще запутаннее и непонятно. Выглядело все примерно так:

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

Поэтому я работала сначала с внутренним json, который меняла, добавляла новые объекты, а потом уже добавляла его в тег xml файла. Не хочу здесь писать более подробно про конкретный случай, поэтому описала вкратце.

В заключении: Очень надеюсь, что кому-то это поможет разобраться в непонятной теме. Готова к замечаниям и критики, большое спасибо за потраченное время 🙂

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

Исправление невалидных XML-файлов¶

Если по каким-то причинам между тегами оказывается символ или лбой другой управляющий символ (подробнее смотрите Таблица I.1 — Сущности), то при синтаксическом анализе XML-файла возникнет ошибка «Невалидный XML».

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

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

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

Удаление лишних блоков(абзацев) из XML по заданному условию¶

Теги в структуре XML образуют многострочные блоки. Иногда возникает необходимость удалить ряд целых блоков по заданному условию. В качестве примера будет рассмотрена ситуация с отчетом по НДС.

Для передачи налоговой отчетности по ТКС в контролирующие органы используется XML. Весь учет ведется в одних программах (например, в 1С), затем выгружается из них в xml формате и отправляется по ТКС непосредственно в контролирующие органы.

Из-за несовершенства некоторых программ, периодически возникают проблемы при передаче файлов в контролирующие органы.

Суть проблемы¶

Отрывок книги продаж выглядит следующим образом:

А нижеприведенный блок в Книге продаж необязателен:

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

Чтобы обойти эту ошибку пришлось вместо ИНН указать регистрационный номер контрагента в стране регистрации, а вместо КПП указать девять нулей.

Но при попытке отравить выгруженный отчет в контролирующий орган, возникала обратная ошибка. Так как ИНН и КПП были фиктивными, то при проверке отчета не выполнялись контрольные соотношения.

Проверка файла отчета программой Tester

ИНН и КПП это не произвольный набор чисел, они содержат определенные контрольные соотношения.

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

Решение проблемы¶

Так как файл содержал свыше 15000 строк и большое количество сделок, надо было автоматизировать данный процесс.

Надо было удалить порядка 700 строк, полностью содержащих блоки (причем
с разными псевдо-ИНН):

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

С этим успешно справилась программа UVFilesCorrector. Интерфейс программы прост до невозможности. В нижней части на вкладке Файлы выбираем нужный нам файл.

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

На скриншоте видно не все выражение, в поле Что найти: в режиме
Шаблон (регулярное выражение) введено:

Всего у организации было 14 контрагентов, с которыми в общей сумме было
заключено 266 сделок. Следовательно, после нажатия на кнопку Заменить
получилось 266 замены.

Буквально за один простой шаг по заданному условию было удалено свыше
700 строк. Проверка Tester’ом ошибок не выявила и файл был успешно отправлен в контролирующий орган.