Проверка XML по схеме XSD

XSD-схема. Онлайн-валидатор. Как исправить ошибки XSD?

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

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

XML отвечает на вопрос «Какие данные переданы?», а XSD определяет, соответствует ли документ установленным правилам. Именно поэтому проверка XML по XSD помогает обнаруживать ошибки до отправки документа в другую систему.

На сайте CIO-Navigator доступна онлайн-проверка XML, которая позволяет проверить структуру документа и разобраться в принципах валидации. Для полноценной проверки по XSD необходима соответствующая схема: она определяет допустимые элементы, их порядок, типы данных и другие ограничения. Разберёмся, что такое XSD, как с ней работать, где искать ошибки и почему эта технология по-прежнему важна для обмена данными между информационными системами.

Что такое XSD-схема

Чтобы понять назначение XSD, представим ситуацию: две информационные системы должны обменяться данными о заказе. Одна отправляет номер заказа, дату оформления, сведения о покупателе и сумму. Другая ожидает те же данные, но в определённой структуре. Если отправитель случайно поменяет местами поля, передаст дату в неожиданном формате или забудет обязательный элемент, получатель может не суметь обработать документ. XSD-схема устанавливает правила, по которым можно проверить XML до его обработки.

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

Предыстория

XML появился в конце 1990-х годов как универсальный текстовый формат для представления структурированных данных. Его разработали в рамках работы Всемирного консорциума по веб-технологиям — W3C. Идея заключалась в том, чтобы разные программы могли обмениваться информацией в понятном и достаточно гибком формате.

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

Одним из ранних подходов был DTD — Document Type Definition. Он позволял описывать допустимые элементы и связи между ними, но имел ограничения, в частности в работе с типами данных. Например, с помощью DTD нельзя было так же удобно и подробно, как в XSD, объявлять числовые типы, даты и ограничения на значения.

В 2001 году W3C опубликовал рекомендации по XML Schema, известные как XML Schema 1.0. Позднее появилась версия 1.1, расширившая возможности языка. С тех пор XSD стала распространённым способом описания и проверки XML-документов в корпоративных интеграциях и других системах обмена данными.

Расшифровка и перевод

XSD расшифровывается как XML Schema Definition. По-русски это можно перевести как «определение XML-схемы» или «описание схемы XML». В повседневной речи часто используют выражение «XSD-схема», хотя в нём присутствует небольшое смысловое дублирование: буква S в аббревиатуре уже означает Schema.

Файл XSD обычно имеет расширение .xsd. Внутри находится XML-документ, который описывает правила для других XML-документов. Получается забавная конструкция: XML описывает данные, а другой XML — схему, которая определяет, каким должен быть первый XML.

order.xml  → документ с данными заказа
order.xsd  → схема, определяющая правила для order.xml

XML + XSD → валидатор → результат проверки

Само расширение файла не гарантирует, что его содержимое действительно является корректной схемой. Файл с названием schema.xsd может содержать обычный текст, ошибочный XML или схему, которая не подходит для нужного документа. Поэтому проверять нужно не только XML, но и корректность самой XSD.

Зачем нужен XSD

Основная задача XSD — установить единые правила структуры и содержания XML-документов. Благодаря этому отправитель и получатель могут заранее договориться о формате обмена данными, а программное обеспечение — автоматически обнаруживать несоответствия.

Схема может определять:

• Обязательные и необязательные элементы. Например, номер заказа должен присутствовать всегда, а комментарий покупателя можно не указывать.
• Порядок элементов. Если сначала должен идти номер документа, а затем дата, переставленные местами поля могут привести к ошибке.
• Типы данных. Сумма может быть десятичным числом, дата — датой, а количество товаров — целым числом.
• Допустимые значения. Например, статус заказа может принимать только значения «новый», «оплачен» или «отменён».
• Минимальные и максимальные значения. Можно задать допустимый диапазон числа или длину текстового поля.
• Количество повторений. Например, документ может содержать от одного до ста товарных позиций.
• Структуру вложенных элементов. Схема определяет, какие поля могут находиться внутри элемента покупателя, адреса или товара.

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

XSD простыми словами

Представим, что XML — это анкета, которую заполняет человек. В ней есть поля «Фамилия», «Дата рождения» и «Количество детей». Можно написать фамилию цифрами, дату — словами, а вместо количества детей указать «много». Текстовая форма сама по себе не запрещает этого делать. Но принимающая сторона может потребовать соблюдения определённых правил.

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

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

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

Как выглядит формат XSD

XSD-схема записывается в формате XML. В ней используются специальные элементы из пространства имён XML Schema, обычно с префиксом xs: или xsd:. Эти префиксы условны: разработчик может выбрать другое имя, если правильно объявит пространство имён. Важен не сам текст префикса, а соответствующее ему пространство имён `http://www.w3.org/2001/XMLSchema`.

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

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="Transport">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Number" type="xs:positiveInteger"/>
        <xs:element name="Date" type="xs:date"/>
        <xs:element name="Amount" type="xs:decimal"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

Разберём основные элементы этого примера:

• xs:schema — корневой элемент схемы, объявляющий документ XSD.
• xs:element — описание элемента, который может присутствовать в XML.
• name="Transport" — имя корневого элемента проверяемого документа.
• xs:complexType — объявление сложного типа, который может содержать вложенные элементы или атрибуты.
• xs:sequence — требование соблюдать заданный порядок элементов.
• xs:positiveInteger — положительное целое число.
• xs:date — дата в формате XML Schema, например `2026-10-23`.
• xs:decimal — десятичное число, например `1500.50`.

Теперь посмотрим на XML, который соответствует этой схеме. Корневой элемент называется `Transport`, а внутри него три дочерних элемента расположены именно в том порядке, который определён через `xs:sequence`.

<?xml version="1.0" encoding="UTF-8"?>
<Transport>
  <Number>123</Number>
  <Date>2026-10-23</Date>
  <Amount>1500.50</Amount>
</Transport>

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

Если заменить `123` на `-123`, проверка обнаружит нарушение типа `xs:positiveInteger`. Если указать дату `23.10.2026`, значение не будет соответствовать типу `xs:date`. Если поменять местами `Number` и `Date`, нарушится порядок, установленный в `xs:sequence`.

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

Чем открыть XSD

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

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

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

Ошибки XSD — что делать?

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

Для начала проверьте три вещи: XML вообще разбирается парсером, XSD корректно загружается и компилируется, а затем уже выполняется проверка документа по схеме. Такой порядок помогает не смешивать ошибки разных уровней. Например, сообщение о незакрытом теге не следует путать с отсутствием обязательного элемента по XSD.

Ошибка проверки по XSD-схеме

Это наиболее распространённый случай: XML синтаксически корректен, но не соответствует правилам схемы. Например, документ содержит обязательные поля, однако одно из них имеет неправильный тип, находится не на своём месте или содержит недопустимое значение.

Если XML не прошёл валидацию, не начинайте исправлять все поля подряд. Найдите первое конкретное сообщение валидатора и сопоставьте его с соответствующим правилом схемы.

Предположим, XSD требует положительное целое число, а XML содержит отрицательное значение:

<Number>-123</Number>

Правило XSD:
<xs:element name="Number" type="xs:positiveInteger"/>

Ошибка: значение не соответствует типу positiveInteger.

Исправление, если значение действительно должно быть положительным:
<Number>123</Number>

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

Ещё одна типичная ситуация — неправильный порядок элементов. Если схема использует `xs:sequence`, порядок дочерних элементов имеет значение. При этом `xs:choice` и `xs:all` задают другие правила, поэтому нельзя считать, что любой XML обязан соответствовать одному универсальному порядку.

Отсутствует соответствующая XSD-схема

Валидатору нужна схема, с которой он будет сравнивать документ. Если XSD не предоставлена и не определена в настройках системы, полноценная проверка структуры невозможна. Программа может проверить синтаксис XML, но не сможет достоверно определить, какие элементы обязательны именно для этого формата.

Иногда схема есть, но её не удаётся найти. Например, основной файл подключает другую схему через `xs:include` или `xs:import`, а дополнительный файл отсутствует. В результате проверка не запускается или завершается ошибкой загрузки зависимостей.

Что делать в такой ситуации:

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

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

Ошибка синтаксиса XML

Прежде чем проверять XML по XSD, программа должна разобрать сам документ. Если тег не закрыт, атрибут оформлен неправильно или элементы вложены с нарушением правил XML, валидация по схеме не сможет нормально продолжиться.

Например, в следующем документе открыт элемент `Number`, но перед закрытием корневого элемента он не закрывается:

<Transport>
  <Number>123
</Transport>

Исправленный вариант:
<Transport>
  <Number>123</Number>
</Transport>

Похожая проблема возникает, если внутри XML встретить символ `<` в обычном тексте без корректного оформления. Например, запись `

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

Несовпадение пространств имён

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

Например, схема может ожидать элемент `Transport` в определённом пространстве имён, а документ содержит одноимённый элемент без пространства имён. Для человека названия выглядят одинаково, но для валидатора это могут быть разные элементы.

XML с пространством имён:
<Transport xmlns="urn:example:transport">
  <Number>123</Number>
</Transport>

XML без пространства имён:
<Transport>
  <Number>123</Number>
</Transport>

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

Чтобы исправить проблему, сравните атрибуты `targetNamespace`, `xmlns` и `elementFormDefault` в схеме с пространствами имён элементов XML. В сложных документах также стоит проверить префиксы и объявления пространств имён на вложенных элементах.

Несовместимая версия XSD

Ещё одна причина ошибок — использование схемы, которая предназначена для другой версии формата. Это особенно актуально для государственных информационных систем, электронного документооборота и интеграций, где форматы постепенно меняются.

Допустим, старая версия XSD разрешала три элемента, а новая добавила четвёртый обязательный элемент. Документ, соответствующий старой схеме, может не пройти проверку по новой. Возможна и обратная ситуация: XML содержит новое поле, которое старая схема не разрешает.

Перед исправлением документа проверьте дату и версию XSD, источник её получения и требования системы, в которую будет отправлен XML. Не следует удалять новые поля или добавлять отсутствующие только ради успешной проверки: сначала нужно убедиться, что выбран правильный формат.

В чём разница

В технической документации рядом с XSD часто встречаются другие аббревиатуры: XML, WSDL, JSON, SOAP и даже SAGA. На первый взгляд они относятся к одной теме, поскольку используются при разработке программного обеспечения и интеграции приложений. Однако эти понятия решают разные задачи.

Чтобы не путаться, полезно разделять формат данных, описание структуры данных, описание сетевого интерфейса и архитектурные подходы к взаимодействию систем. XML — это формат представления данных, XSD — способ описать допустимую структуру XML, WSDL — описание веб-сервиса, а SAGA — архитектурный шаблон организации распределённых бизнес-транзакций.

XML и XSD

XML и XSD тесно связаны, но не являются одним и тем же. XML содержит конкретные данные, а XSD описывает правила, которым эти данные должны соответствовать. XML можно создать без XSD, но для проверки по схеме валидатору потребуется сама схема или ссылка на неё в настройках инструмента.

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

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

WSDL и XSD

WSDL расшифровывается как Web Services Description Language. Это язык описания веб-сервисов, который позволяет определить доступные операции, параметры запросов и ответов, а также способы взаимодействия с сервисом. Он особенно известен в интеграциях на основе SOAP.

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

WSDL:
Какие операции предоставляет сервис?
Какие сообщения он принимает и возвращает?

XSD:
Какие элементы содержит сообщение?
Какие типы данных и ограничения действуют?

XML:
Конкретный запрос или ответ с данными.

Например, сервис может предоставлять операцию `CreateOrder`, которая принимает XML с информацией о заказе. В WSDL описывается операция и связываемые с ней сообщения, а XSD определяет структуру заказа: номер, дату, список товаров и сумму. Если запрос не соответствует схеме, сервис может отклонить его ещё до выполнения основной бизнес-операции.

Важно, что WSDL не обязателен для любого XML-обмена, а XSD не является обязательной частью абсолютно каждого веб-сервиса. Это инструменты, которые применяются тогда, когда они соответствуют архитектуре и требованиям конкретной интеграции.

SAGA и XSD

SAGA — это архитектурный шаблон для организации распределённых бизнес-транзакций. Он применяется, когда одна бизнес-операция затрагивает несколько независимых сервисов или баз данных. Вместо одной общей транзакции операция выполняется последовательностью локальных транзакций, а при сбое могут запускаться компенсирующие действия.

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

XSD решает совершенно другую задачу: она описывает структуру XML-документов. Эти технологии могут использоваться в одной системе, но не заменяют друг друга. Если сервисы внутри SAGA обмениваются XML-сообщениями, XSD может проверять структуру этих сообщений, а SAGA — управлять последовательностью бизнес-операций.

Зачем использовать XSD-схемы для запросов JSON

Здесь есть важный нюанс: XSD предназначена для XML, а не для JSON. Поэтому напрямую проверять обычный JSON-документ по XSD нельзя. У JSON другая структура записи данных, и для описания его формата обычно применяют JSON Schema.

Например, JSON-запрос к API может выглядеть так:

{
  "orderNumber": 123,
  "date": "2026-10-23",
  "amount": 1500.50
}

Для этого документа логично использовать JSON Schema, которая определяет типы полей, обязательные свойства и ограничения. XSD не сможет напрямую проверить такой JSON как XML, поскольку фигурные скобки и пары «ключ — значение» не соответствуют синтаксису XML.

Но почему тогда иногда говорят об XSD в контексте JSON? Есть несколько возможных причин. Например, система может преобразовывать JSON в XML, чтобы проверить полученный документ по XSD. Или организация может использовать XML и JSON для разных интерфейсов одного сервиса, поддерживая отдельные схемы для каждого формата. Наконец, API может принимать JSON, структура которого концептуально повторяет структуру XML-сообщения, описанного в XSD, — однако это ещё не означает, что XSD проверяет JSON напрямую.

Если API принимает JSON, выбирайте JSON Schema. Если он принимает XML, для проверки структуры можно использовать XSD. Формат данных определяет, какой инструмент валидации подходит для задачи.

JSON Schema позволяет описывать типы значений, обязательные свойства, допустимые диапазоны чисел, форматы строк, вложенные объекты и массивы. Например, можно потребовать, чтобы поле `orderNumber` было целым положительным числом, `date` имело формат даты, а `amount` было числом не меньше нуля.

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

Выводы

XSD — это язык описания правил для XML-документов. Он позволяет определить структуру данных, обязательные элементы, допустимые типы значений, порядок полей и другие ограничения. Благодаря этому системы могут проверять входящие документы до того, как передавать их на дальнейшую обработку.

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

Если XML не проходит проверку, полезно последовательно проверить:

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

Не менее важно использовать подходящий инструмент. Для XML подходит XSD, для JSON — JSON Schema, а для описания интерфейсов SOAP-сервисов может применяться WSDL. SAGA, в свою очередь, помогает организовать распределённые бизнес-транзакции и относится к другой области проектирования программных систем.

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