xml обучение с нуля
Основы XML для начинающих
Сегодня приступим к рассмотрению очень популярного и удобного языка разметки XML. Так как данный формат представления данных очень гибок и универсален, и его можно использовать практически везде, имеется в виду совестно с чем-то. Поэтому начинающему программисту рано или поздно придется столкнуться с этим языком, и неважно чем конкретно Вы занимаетесь, будь то web-программированием или администрированием баз данных, потому что XML используют все, и Вы его также будете использовать в реализации нужных Вам задач.
Начинать будем как обычно с теории, давайте рассмотрим, что же это за язык, чем он хорош, как им пользоваться и где его используют.
Определение языка XML
XML (eXtensible Markup Language) – универсальный и расширяемый язык разметки данных, который не зависит от операционной системы и среды обработки. Xml служит для представления неких данных в виде структуры, и эту структуру Вы можете сами разработать или подстроить под ту или иную программу или какой-то сервис. Именно поэтому данный язык называют расширяемый, и в этом является его главное достоинство, за которое его так ценят.
Как Вы знаете, языков разметки существует достаточно много, например, язык HTML, но все они, так или иначе, зависят от обработчика, например, тот же самый html, код которого парсит браузер, является стандартизированным и не расширяемым, там есть четкие теги, синтаксис который нельзя нарушать, а в xml Вы можете сами создавать свои теги, т.е. свою разметку. Главным отличием HTML и XML является то, что html всего лишь описывает разметку для отображения данных, а xml — это абстрактная структура данных, которую можно обработать и отобразить как угодно и где угодно и поэтому сравнивать эти языки не нужно, у них абсолютно разное назначение.
Как уже отметилось выше xml очень распространенный и универсальный язык, посредствам которого практически все приложения, как web, так и просто для компьютера используют его в качестве обмена информации, так как с помощью него можно очень легко обмениваться данными между приложениями или сервисами, которые даже написаны на разных языках. В связи с чем, каждый начинающий программист, который занимается абсолютно любым программированием, должен иметь представление об XML. Если Вы хотите стать web мастером, то Вы просто обязаны знать XML, а как стать WEB Мастером и что для этого нужно знать, мы с Вами уже рассматривали.
Например, у меня однажды встала задача написать некий сервис, который должен по запросу возвращать данные в виде xml, т.е. своего рода разработать серверную часть приложения, а я даже понятия не имел, на чем написан клиент, который будет обрабатывать эти данные, и что, я написал сервис, который возвращал данные в виде xml и все, приложение работало отлично. И это только пример, с которым мне пришлось столкнуться, а теперь представьте, сколько различных организаций, сотрудничает и совестно разрабатывают программное обеспечение и обмениваются данными, и я не удивлюсь, что эти данные будут в виде xml.
Например, у меня однажды была задача написать некий сервис, который должен по запросу возвращать данные в виде xml, т.е. своего рода разработать серверную часть приложения, а я даже понятия не имел, на чем написан клиент, который будет обрабатывать эти данные, и что, я написал сервис, который возвращал данные в виде xml и все, приложение работало отлично. И это только пример, с которым мне пришлось столкнуться, а теперь представьте, сколько различных организаций, сотрудничает и совестно разрабатывают программное обеспечение и обмениваются данными, и я не удивлюсь, что эти данные будут в виде xml.
Также мне один раз пришлось хранить данные xml в базе MS SQL 2008, для того чтобы лучше представлять эти самые данные и обмениваться ими между сервером и клиентской частью приложения, это мы рассматривали в статье — Transact-sql – работа с xml.
Сам по себе язык XML очень простой, и запутаться в нем просто нельзя, вся сложность возникает именно в обработке и взаимодействие xml с другими приложениями, технологиями, т.е. всем тем, что окружает xml, в чем как раз и можно легко запутаться.
Сегодня мы с Вами разговариваем пока только об основах XML, и заострять внимание на технологиях обработки и взаимодействия с этим языком мы не будем, так как это правда, очень объемный материал, но я думаю, в дальнейшем мы продолжим знакомиться с сопутствующими технологиями.
Переходим к практике. И все примеры, которые мы будем рассматривать, я буду писать в Notepad++ только потому, что он очень удобен, но сейчас не будем об этом разговаривать, так как мы уже это рассматривали в статье — Чем хорош Notepad++ для начинающего разработчика.
XML теги
Язык XML для разметки использует теги (теги регистрозависимы), но не такие теги как в html, а те, которые Вы придумаете сами, но у xml документа есть также четкая структура, т.е. есть открывающий тег и закрывающий, есть вложенные теги и есть, конечно же, значения, которые расположены в этих тегах. Другими словами, все, что нужно для начальных знаний xml — это просто придерживаться этим правилам. Все вместе открывающий, закрывающий тег и значение называется элементом и весь xml документ состоит именно из элементов, которые в совокупности образуют структуру данных. У xml документа может быть только один корневой элемент, это запомните, так как если Вы напишите два корневых элемента, то это будет ошибка.
И пришло время привести пример xml разметки, и первый пример пока для синтаксиса:
Как видите все довольно просто, и таких вложенных друг в друга элементов может быть очень много.
Теперь давайте приведем пример, настоящего xml документа:
Как видите, я здесь просто привел пример своего рода каталога книг, но я не объявлял этот документ, т.е. не писал XML декларацию, которая говорит приложению, которое будет обрабатывать эти данные, что здесь расположены данные именно xml и в какой кодировке они представлены. Также можно писать комментарии и атрибуты, так давайте приведем пример такого документа:
Где первая строка и есть объявление декларации о том, что это документ XML и его необходимо читать в кодировке UTF-8.
Эти данные без обработки будут выглядеть, например, в браузере (Mozilla Firefox) следующим образом:
Надеюсь, Вы понимаете, что здесь catalog — это корневой элемент, который состоит из элементов book, который в свою очередь состоит из элементов name, author и comment, также для примера я задал несколько атрибутов у элемента catalog и у элемента book.
Для основ я думаю достаточно, так как если мы будем все глубже и глубже погружаться в XML, и во все технологии, которые связаны с этим языком, то тогда эта статья никогда не закончится. Так что на сегодня это все. Пока!
I. Коротко об XML¶
Введение в XML¶
XML ( англ. eXtensible Markup Language) — расширяемый язык разметки, предназначенный для хранения и передачи данных.
Простейший XML-документ выглядит следующим образом:
Документ XML состоит из элементов (elements). Элемент начинается открывающим тегом (start-tag) в угловых скобках, затем идет содержимое (content) элемента, после него записывается закрывающий тег (end-teg) в угловых скобках.
Некоторые элементы, не содержащие значений, допустимо записывать без закрывающего тега. В таком случае символ / ставится в конце открывающего тега:
Структура XML¶
XML документ должен содержать корневой элемент. Этот элемент является «родительским» для всех других элементов.
Все элементы в XML документе формируют иерархическое дерево. Это дерево начинается с корневого элемента и разветвляется на более низкие уровни элементов.
Все элементы могут иметь подэлементы (дочерние элементы):
Правила синтаксиса (Валидность)¶
Основные правила синтаксиса XML:
Открывающий и закрывающий теги должны определяться в одном регистре:
Сущности¶
Некоторые символы в XML имеют особые значения и являются служебными. Если вы поместите, например, символ внутри XML элемента, то будет сгенерирована ошибка, так как парсер интерпретирует его, как начало нового элемента.
Также ошибка будет сгенерирована и в слудющем примере, если название организации взять в обычные кавычки (английские двойные):
Чтобы ошибки не возникали, нужно заменить символ на его сущность. В XML существует 5 предопределенных сущностей:
| Сущность | Символ | Значение |
|---|---|---|
| меньше, чем | ||
| > | > | больше, чем |
| & | & | амперсанд |
| ‘ | ‘ | апостроф |
| « | « | кавычки |
Только символы и & строго запрещены в XML. Символ > допустим, но лучше его всегда заменять на сущность.
Таким образом, корректными будут следующие формы записей:
В последнем примере английские двойные кавычки заменены на французские кавычки («ёлочки»), которые не являются служебными символами.
Поиск информации в XML файлах (XPath)¶
XPath ( англ. XML Path Language) — язык запросов к элементам XML-документа. XPath расширяет возможности работы с XML.
XML имеет древовидную структуру. В документе всегда имеется корневой элемент (инструкция version=”1.0”?> к дереву отношения не имеет). У элемента дерева всегда существуют потомки и предки, кроме корневого элемента, у которого предков нет, а также тупиковых элементов (листьев дерева), у которых нет потомков. Каждый элемент дерева находится на определенном уровне вложенности (далее — «уровень»). У элементов на одном уровне бывают предыдущие и следующие элементы.
Это очень похоже на организацию каталогов в файловой системе, и строки XPath, фактически, — пути к «файлам» — элементам. Рассмотрим пример списка книг:
XPath запрос /bookstore/book/price вернет следующий результат:
Чтобы получить больше информации, необходимо модифицировать запрос //book[title[@lang=»it»]] вернет:
В приведенной ниже таблице представлены некоторые выражения XPath и результат их работы:
Кодировки¶
И еще один важный момент, который стоит рассмотреть — кодировки. Существует множество кодировок, о них подробнее можно прочитать в статье Набор символов.
В XML файле кодировка объявляется в декларации:
Часто можно столкнуться с ситуацией, когда текстовый редаткор некорректно распознает кодировку и отображает кракозябры. В такой случае, необходимо выбрать кодировку вручную, для этого выполните:
| Программа | Кодировка |
|---|---|
| Notepad++ | «Документ → Кодировка» |
| Geany | «Документ → Установить кодировку» |
| Firefox | «Вид → Кодировка» |
| Chrome | «Настройка → Дополнительные инструменты → Кодировка» |
Если ничего не помогает, вполне возможно, что файл был поврежден.
XSD схема¶
XML Schema — язык описания структуры XML-документа, его также называют XSD. Как большинство языков описания XML, XML Schema была задумана для определения правил, которым должен подчиняться документ. Но, в отличие от других языков, XML Schema была разработана так, чтобы её можно было использовать в создании программного обеспечения для обработки документов XML.
После проверки документа на соответствие XML Schema читающая программа может создать модель данных документа, которая включает:
Каждый элемент в этой модели ассоциируется с определённым типом данных, позволяя строить в памяти объект, соответствующий структуре XML-документа. Языкам объектно-ориентированного программирования гораздо легче иметь дело с таким объектом, чем с текстовым файлом.
Подробнее об XSD смотрите:
Примером использования XSD cхем может служить электронная отчетность:
Что такое XML
Если вы тестируете API, то должны знать про два основных формата передачи данных:
XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.
Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!
См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.
Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.
Содержание
Как устроен XML
Возьмем пример из документации подсказок Дадаты по ФИО:
И разберемся, что означает эта запись.
В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:
Текст внутри угловых скобок — название тега.
Тега всегда два:
Ой, ну ладно, подловили! Не всегда. Бывают еще пустые элементы, у них один тег и открывающий, и закрывающий одновременно. Но об этом чуть позже!
С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:
— На въезде в город написано его название: Москва
— На выезде написано то же самое название, но перечеркнутое: Москва*
* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!
Корневой элемент
В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.
Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».
Он мог бы называться по другому:
Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.
Значение элемента
Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!
Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.
Внутри — значение запроса.
Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):
Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.
Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».
Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.
Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.
Атрибуты элемента
У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде
Зачем это нужно? Из атрибутов принимающая 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-ка получилась. Причем упрощенная. В реальных системах, где хранятся физ лица, данных сильно больше: штук 20 полей самого физ лица, несколько адресов, телефонов, емейл-адресов…
Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…
А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.
XML пролог
Иногда вверху XML документа можно увидеть что-то похожее:
Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.
UTF-8 — кодировка XML документов по умолчанию.
XSD-схема
XSD (XML Schema Definition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.
Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».
Если мы создаем SOAP-метод, то указываем в схеме:
Поэтому зачем запускать сложную процедуру, если запрос заведом «плохой»? И выдавать ошибку через 5 минут, а не сразу? Валидация по схеме помогает быстро отсеять явно невалидные запросы, не нагружая систему.
Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!
А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?
Итого, как используется схема при разработке SOAP API:
| Правильный запрос | Неправильный запрос |
|---|---|
| Нет обязательного поля name | |
| Опечатка в названии тега (mail вместо email) | |
| . | . |
Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:
А в WSDl сервиса она записана еще проще:
Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:
А еще в схеме можно ссылаться на другую схему, что упрощает написание кода — можно переиспользовать схемы для разных задач.
Практика: составляем свой запрос
Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!
Что, если я хочу, чтобы мне вернуть только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:
В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:
Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. «Женский» по английски будет FEMALE, в документации также. Итого получили:
Ненужное можно удалить. Если нас не волнует количество подсказок, параметр count выкидываем. Ведь, согласно документации, он необязательный. Получили запрос:
Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))
Попробуй сам!
Напишите запрос для метода MagicSearch в Users. Мы хотим найти всех Ивановых по полному совпадению, на которых висят актуальные задачи.
Well Formed XML
Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.
Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.
В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.
Правила well formed XML:
Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?
1. Есть корневой элемент
Нельзя просто положить рядышком 2 XML и полагать, что «система сама разберется, что это два запроса, а не один». Не разберется. Потому что не должна.
И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:
| Нет | Да |
|---|---|
| Есть элементы «test» и «dev», но они расположены рядом, а корневого, внутри которого все лежит — нету. Это скорее похоже на 2 XML документа | А вот тут уже есть элемент credential, который является корневым |
Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!
2. У каждого элемента есть закрывающийся тег
Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.
Но тут стоит заметить, что тег может быть один. Если элемент пустой, мы можем обойтись одним тегом, закрыв его в конце:
Это тоже самое, что передать в нем пустое значение
Аналогично сервер может вернуть нам пустое значение тега. Можно попробовать послать пустые поля в Users в методе FullUpdateUser. И в запросе это допустимо (я отправила пустым поле name1), и в ответе SOAP Ui нам именно так и отрисовывает пустые поля.
Итого — если есть открывающийся тег, должен быть закрывающийся. Либо это будет один тег со слешом в конце.
Для тестирования удаляем в запросе любой закрывающийся тег.
3. Теги регистрозависимы
Как написали открывающий — также пишем и закрывающий. ТОЧНО ТАК ЖЕ! А не так, как захотелось.
А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным
4. Правильная вложенность элементов
Элементы могут идти друг за другом
Один элемент может быть вложен в другой
Но накладываться друг на друга элементы НЕ могут!
5. Атрибуты оформлены в кавычках
Даже если вы считаете атрибут числом, он будет в кавычках:
Для тестирования пробуем передать его без кавычек:
Итого
XML (eXtensible Markup Language) используется для хранения и передачи данных.
Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.
Хранение данных — это когда XML встречается внутри кода. Его легко понимает как машина, так и человек. В формате XML можно описывать какие-то правила, которые будут применяться к данным, или что-то еще.
Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).
Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.
Правила well formed XML:
Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.
А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!
Что такое JSON — второй популярный формат
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале