Что такое код xslt_set_log

Содержание

Что такое код xslt_set_log

(PHP 4 >= 4.0.6, PECL)

xslt_set_log — Set the log file to write log messages to

Description vo >xslt_set_log ( resource xh [, mixed log] )

A reference to the XSLT parser.

This parameter is either a boolean value which toggles logging on and off, or a string containing the logfile in which log errors too.

This function allows you to set the file in which you want XSLT log messages to, XSLT log messages are different than error messages, in that log messages are not actually error messages but rather messages related to the state of the XSLT processor. They are useful for debugging XSLT, when something goes wrong.

By default logging is disabled, in order to enable logging you must first call xslt_set_log() with a boolean parameter which enables logging, then if you want to set the log file to debug to, you must then pass it a string containing the filename.

Замечание: Учтите, что в случае использования Windows, вам нужно указать file:// в начале пути.

Что такое код xslt_set_log

(PHP 4 >= 4.0.6, PECL)

xslt_set_log — Set the log file to write log messages to

Description vo >xslt_set_log ( resource xh [, mixed log] )

A reference to the XSLT parser.

This parameter is either a boolean value which toggles logging on and off, or a string containing the logfile in which log errors too.

This function allows you to set the file in which you want XSLT log messages to, XSLT log messages are different than error messages, in that log messages are not actually error messages but rather messages related to the state of the XSLT processor. They are useful for debugging XSLT, when something goes wrong.

By default logging is disabled, in order to enable logging you must first call xslt_set_log() with a boolean parameter which enables logging, then if you want to set the log file to debug to, you must then pass it a string containing the filename.

Note: Please note that file:// is needed in front of path if you use Windows.

XSLT первый шаг

1. Введение

Не прошло и трёх лет с тех пор, как у меня зародилась мысль о том, что пора изучать XSLT -))). Мысль зародилась, а везде ещё стоял PHP 4 и зверствовал Salbotron , который, мягко говоря, не отличался высокой производительностью. Да и редко какой браузер мог похвастаться поддержкой этого самого XSLT. По этим соображениям изучение столь перспективного направления я отложил до лучших времён. На данный момент можно смело заявить, что эти времена настали, поскольку вышел PHP 5 с поддержкой XSLT и сносной объектной моделью, а все топовые браузеры уже сами уверенно держат преобразования, только подавай XML. :)

Важные ссылки по теме, первоисточники:

  • http://w3c.org — комитет по разработке и продвижению стандартов всемирной паутины Internet. На данный момент он является первоисточником практически всех веб-ориентированных стандартов и рекомендаций.
  • http://www.w3.org/TR/xml — спецификация расширяемого языка разметки XML, который является основой современного веба. На момент написания статьи доступна пятая редакция версии 1.0, а также вторая редакция версии 1.1.
  • http://www.w3.org/TR/xml-names — спецификация использования пространств имён в XML.
  • http://www.w3.org/TR/xpath — спецификация по использованию языка поиска частей XML-документа XPath.
  • http://www.w3.org/TR/xsl/ — спецификация расширенного языка стилей XSL.
  • http://www.w3.org/TR/xslt — спецификация языка преобразований XSLT.
  • http://validator.w3.org/ — валидатор HTML.
  • http://www.w3.org/TR/xhtml1/ — спецификация XHTML1.0.

Переводы на русский язык:

Для лучшего понимания всего происходящего я рекомендую читать спецификации в следующем порядке:

  1. XML (это основа!)
  2. пространства имён (механизм разнородного XML-кода в одном файле)
  3. XPath (язык выборки элементов из дерева структуры)
  4. XSLT (преобразования)
  5. XHTML (то, к чему нужно стремиться)

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

2. Валидный XHTML

Что такое валидный XHTML? В первую очередь, это XML-документ, который должен соответствовать спецификации XML. Во-вторую, почти обычная HTML-страница, к которой все привыкли.

Почему нужен именно XHTML? Исключительно из соображений совместимости и кросс-браузерности. Страница в XHTML будет с большей вероятностью отображаться корректно в популярных браузерах, чем обычный HTML.

Для рядового клепателя страниц словосочетание XML-документ должно означать следующее:

  1. Документ содержит объявление XML-документа в самом начале страницы:
  2. Документ содержит один корневой элемент, в котором находятся все остальные.
  3. Все элементы (тэги) должны иметь закрывающую часть (
    ,

).

  • Атрибуты всегда имеют значение, которое обязательно указывается в кавычках (одинарных или двойных). Например, «radio» disabled= «disabled» /> .
  • Управляющие символы & , и > всегда должны маскироваться. Например, «?a=1&b=2» > & . Исключение составляет только , внутри которого спецсимволы можно не маскировать.
  • Также сам XHTML обязывает выполнять следующие условия:

    1. Документ должен объявлять пространство имён, в рамках которого будут использоваться элементы HTML.
    2. Документ должен объявлять DOCTYPE перед корневым элементом и указывать в нём один из типов XHTML и соответствующий DTD.

    Пример простого документа XHTML1.0:

    И так обо всём по порядку.

    Объявление XML-документа, в котором указывается его версия и кодировка.

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

    Объявление типа документа и его схемы.

    Для XHTML 1.0 есть три типа — Strict (строгое соответствие рекомендациям W3C), Transitional (переходный тип) и Frameset (использование фреймов). Для каждого из них предусмотрен отдельный DTD.

    Объявление пространства имён и используемого языка.

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

    Три версии XHTML1.0 предназначены для лучшей обратной совместимости:

    • Strict — обеспечивает наибольшее соответствие рекомендациям W3C со стороны браузеров. Однако и сам HTML-код должен следовать этим рекомендациям.
    • Transitional — менее строгое соответствие, которое заставляет браузер вести себя так, как если бы это был обычный HTML-документ.
    • Frameset — позволяет использовать фреймы.

    Помимо XHTML1.0 на данный момент доступен XHTML1.1:

    XHTML1.1 по сути является тем же XHTML1.0 Strict и призван вытеснить другие версии XHTML1.0. Однако, по сравнению с XHTML1.0 Strict, у него есть ряд отличий:

    1. Удалён атрибут lang , его роль выполняет xml:lang . (Модуль [ XHTMLMOD ])
    2. Для элементов a и map вместо атрибута name нужно использовать атрибут id . (Модуль [ XHTMLMOD ])
    3. Доступен набор элементов ruby . (Модуль [ RUBY ])

    Итак, если вам нужна наибольшая кросс-браузерность и совместимость с рекомендациями W3C, то XHTML1.1 самое оно!

    Из этих соображений результатом моих преобразований будет именно XHTML1.1.

    3. XSLT-преобразования

    Что такое XSLT? Это язык преобразований XML-документа, который был разработан как часть расширенного языка стилей (XSL).

    Зачем нужен XSLT? Он позволяет реализовать схему, при которой данные хранятся отдельно, а их представление отдельно. То есть, один XML-документ преобразуется с помощью другого XML-документа (XSL, в котором находятся XSLT-шаблоны) в конечный документ. Результатом может быть XML, HTML или текстовый документ любого формата.

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

    Валидным XSL-документом является XML-документ, у которого задано пространство имён xsl и присутствует корневой элемент stylesheet. В самом простом случае стиль может выглядеть, например, так:

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

    За подключение стиля отвечает строка:

    Если файлы text.xml и test.xsl созданы и находятся в одной папке, то с помощью любого XSLT-парсера можно преобразовать исходный test.xml в результирующий документ. В качестве парсера могут выступать все популярные браузеры (IE5+, FF2+, Opera9+ и другие), а также модули в языках программирования, например, в PHP. Если вы используете браузер, то достаточно открыть test.xml, и он сразу отобразит примерно такой результат:

    При этом кодировка результата будет UTF-8, несмотря на то, что исходный документ был сформирован в windows-1251. К сожалению, браузеры обычно не позволяют просмотреть код результирующего документа, но модуль XSLT в PHP5 даёт возможность передать результирующий код в переменную, которую можно сохранить в файл. Поэтому, используя PHP, я приведу исходный код результирующего документа:

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

    В качестве примера я приведу XSL-стиль, который при помощи XSLT будет выводить список атрибутов исходного XML-документа с их значениями, при этом будет формироваться валидный XHTML1.1. Итак, стиль:

    Чтобы понять, как он работает, я распишу каждое действие отдельно:

    Документ сформирован в кодировке windows-1251, о чём сообщается в атрибуте encoding. Версию XML-документа желательно всегда указывать, это рекомендация W3C.

    Затем идёт объявление корневого элемента, стиля:

    Обязательным атрибутом является определение пространства имён xsl через атрибут xmlns:xsl= «http://www.w3.org/1999/XSL/Transform» .

    Следующим шагом в корневом элементе stylesheet объявляется, каким образом нужно формировать результирующий документ:

    • method= «xml» — метод вывода документа. Результирующий документ будет в формате XML.
    • encoding= «windows-1251» — кодировка результирующего документа.
    • omit-xml-declaration= «no» — пропускать или нет начальное объявление XML-документа ( ). Может иметь значение «yes» или «no» (актуально только для html).
    • indent= «yes» — формировать отступы согласно уровню вложенности. Может иметь значение «yes» или «no».
    • media-type= «text/xml» — MIME-тип результирующего документа (используется только для метода вывода html).
    • doctype-public= «-//W3C//DTD XHTML 1.1//EN» — тип результируюшего документа (DOCTYPE)
    • doctype-system= «http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd» — ссылка на DTD

    Если метод вывода объявлен html, то значения атрибутов encoding и media-type будут подставлены в заголовок страницы ( . ) посредством метатега.

    Объявление основного шаблона:

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

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

    Формирование XHTML-страницы. Оно начинается с элемента , у которого указано пространство имён xhtml:

    Атрибут xmlns= «http://www.w3.org/1999/xhtml» указывает на пространство имён xhtml, которое будет применено по умолчанию к этому элементу и всем дочерним элементам, у которых оно не задано явно.

    Атрибут xml:lang= «ru» указывает на язык, в котором сформирована страница (будущая).

    Эта часть стиля была нужна для формирования атрибутики валидного XHTML1.1 кода.

    Теперь что касается XSLT-преобразований:

    Вставка простого текста:

    Текст «Мой список:» будет подставлен в тег

    Организация цикла по выборке:

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

    В данном случае выборка вернёт список атрибутов для этого (корневого) и всех дочерних элементов.

    В данном случае проверяется на чётность позиция элемента в списке выборки. Если тест возвращает true (порядковый номер элемента чётный), то срабатывает содержимое этого элемента.

    Управление атрибутами вышестоящего элемента:

    В данном случае, если позиция элемента чётная (определяется вышестоящим if), то в стиль элемента
    будет прописан серый цвет фона.

    Вывод значений элемента:

    Этот код подставит в вышестоящий элемент строку, собранную из имени текущего элемента и его значения. Содержимое атрибута select соответствует XPath.

    Вывод ссылки на разработчика парсера XSLT:

    Этот небольшой код XSLT формирует ссылку на разработчика парсера XSLT. Во многих случаях она будет разная и содержать разные значения.

    Результатом обработки этого стиля ( test.xsl ) станет такой код:

    Этот код соответствует стандарту XHTML1.1 и был сформирован на основе исходного XML-документа. Для проверки можно воспользоваться валидатором от W3C, который расположен по адресу http://validator.w3.org/.

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

    IE 6 FireFox 3 Opera 9.02

    4. Приложение

    Ссылки на исходный код

    Постоянный адрес статьи //anton-pribora.ru/articles/xml/xslt-first-step/. /Автор: Прибора Антон Николаевич, 2009 год/

    Использование PHP5 для обработки XSLT

    Для получения результирующего документа при помощи PHP5 я использовал такой код:

    Дополнительную информацию по использованию XSLT в PHP5 можно найти по адресу http://ru2.php.net/manual/ru/book.xslt.php.

    Мысли вслух

    «Товарищи, мы стоим на краю огромной пропасти! И я предлагаю сделать большой, решительный шаг вперёд!»

    © 2020 Антон Прибора. При копировании материалов с сайта, пожалуйста, указывайте ссылку на источник.

    XSLT на стороне сервера

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

    Кросс-браузерное решение

    В предыдущей главе рассказывалось как при помощи XSLT можно преобразовывать XML документ в XHTML в самом браузере. Для этого использовался JavaScript и XML парсер. Тем не менее, данный подход не сработает, если в браузере нет XML парсера.

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

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

    XML и XSLT файлы

    Посмотрите на XML документ, который мы уже видели в предыдущих главах:

    И на сопутствующую ему таблицу стилей XSL:

    ВАЖНО: Обратите внимание, что в XML файле нет ссылки на XSL файл. Это означает, что XML файл может преобразовываться при помощи множества различных таблиц стилей XSL.

    Преобразование XML в XHTML на стороне сервера. Код на PHP.

    Ниже приводится исходный код на PHP, который позволяет преобразовать XML файл в XHTML на стороне сервера:

    Преобразование XML в XHTML на стороне сервера. Код на ASP.

    Ниже приводится исходный код на ASP, который позволяет преобразовать XML файл в XHTML на стороне сервера:

    Введение в XSLT

    Преобразование формата XML-данных посредством преобразований расширяемого языка таблиц стилей (XSLT)

    Перед началом работы

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

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

    О чем это руководство?

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

    В данном руководстве вы изучите:

    • Основы XSLT
    • Использование простых шаблонов
    • Публикацию данных
    • Управление пробелами
    • Основы XPath
    • Функции XPath
    • Циклы и условные операторы
    • Импорт и включение других таблиц стилей
    • Расширение XSLT
    • Переменные XSLT

    Начало работы

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

    Например, у вас могут быть данные в XML, которые вы хотите опубликовать в Интернете, что означает перевод их в HTML. Конечно, вы могли бы вручную просмотреть документ и сделать в нем необходимые изменения, или может быть, вы подумали о том, чтобы загрузить XML в DOM, а затем вручную создать документ вывода.

    Что такое XSLT?

    Преобразования расширяемого языка таблиц стилей (XSLT) предоставляют способ для автоматического перевода XML-данных из одной формы в другую. Целевая форма — это обычно другой XML-документ, но не обязательно; вы можете преобразовать XML практически во что угодно, просто создав таблицу стилей XSLT и обработав данные. Если вы хотите изменить результаты, вы просто меняете таблицу стилей и обрабатываете XML заново. Здесь есть дополнительное преимущество, расширяющее возможности непрограммистов, например, дизайнеров, которые могут изменять таблицу стилей и влиять на результаты.

    Давайте посмотрим пример.

    Поставленная задача

    В данном руководстве мы возьмем XML-документ и преобразуем его в XHTML-документ, который можно отобразить как Web-страницу. Входные данные — это просто файл с рецептами (см. листинг 1).

    Листинг 1. Основные данные

    Замечание редактора: Эти рецепты –приведены просто для примера, так, как их представляет себе автор. Правильный рецепт для Gush’gosh (полученный от его жены, которая и готовит это блюдо) состоит из 1 фунта (0,454 кг) рубленой говядины, 1 фунта рожков, 1/2 стакана желтого сахара, 1 небольшого пакета (около 300 грамм) мелко нарезанного лука, 1 чайной ложки сушеного укропа и 1 небольшой банки томатной пасты, в которую добавляется желтый сахар.

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

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

    Листинг 2. Результат

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

    Рисунок 1. Результат, отображенный в браузере

    Как уже упоминалось, конечной целью может быть любой формат, не только XHTML, и даже не обязательно XML.

    Давайте начнем с простых преобразований.

    Простая таблица стилей

    Самая простая таблица стилей — это просто XML документ, включающий XSLT-вывод (см. листинг 3).

    Листинг 3. Самая простая таблица стилей

    Обратите внимание на использование пространства имен xsl . Добавление этого пространства имен говорит процессору, какие элементы связаны с обработкой, а какие должны быть просто выведены. Элементы value-of говорят процессору вставить определенные данные в это место. Какие именно данные вставлять определяется содержимым атрибута select .

    Атрибут select состоит из выражения XPath. Подробнее XPath будет обсуждаться в разделе Подробнее об XPath, однако здесь вы можете видеть, что доступ к элементам «название», «ингредиенты» и «инструкция по приготовлению» происходит через иерархию документа. Мы начинаем с корневого элемента, /recipes , и от него движемся вниз.

    Как выполнить преобразование

    Простейший способ выполнить XML-преобразование — это добавить указание на таблицу стилей в XML и отобразить его в браузере (см. листинг 4).

    Листинг 4. Добавление в XML инструкции по обработке при помощи таблицы стилей

    Эта инструкция по обработке говорит браузеру извлечь таблицу стилей, расположенную в basicstylesheet.xsl, и использовать ее для преобразования XML-данных и вывода результатов. Если вы откроете наш XML-документ в браузере Microsoft® Internet Explorer®, то увидите результат, похожий на рисунок 2.

    Рисунок 2. Извлечение таблицы стилей и преобразование XML-данных

    Однако это не совсем то, что мы хотели получить. Если вы выберете в браузере Вид>Просмотр HTML-кода, то увидите изначальный XML. Чтобы увидеть результат преобразования, необходимо произвести это преобразование и создать выходной файл. Это можно сделать через командную строку, используя Java-код со следующей командой (см. листинг 5):

    Листинг 5. Преобразование документа через командную строку

    Если вы получите исключение ClassNotFoundException , возможно, вам нужно загрузить Apache Xalan (см. «Получить продукты и технологии» в разделе Ресурсы) и добавить включенные в него JAR-файлы в путь к классам.

    Выполнив преобразование, показанное в листинге 5, вы увидите, что файл result.html содержит следующий код (см. листинг 6).

    Листинг 6. Результаты

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

    Добавление шаблонов

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

    Создание шаблонов

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

    Листинг 7. Переделанная таблица стилей

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

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

    Листинг 8. Создание дополнительных шаблонов

    Обратите внимание, что вместо того, чтобы просто вывести элемент value-of , мы теперь указываем таблице стилей применять соответствующие шаблоны к элементам ingredients и instructions. Затем мы создали отдельные шаблоны для этих элементов, задав их в атрибуте match . Добравшись до элемента apply-templates , процессор выбирает все элементы ingredients в документе. Затем он ищет шаблон для ингредиентов, а, найдя его, выводит этот шаблон. То же самое он делает с элементом instructions . Результат должен быть похож на изображенный на рисунке 3.

    Рисунок 3. Применение соответствующих шаблонов к элементам ingredients и instructions

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

    Публикация шаблонов

    Чтобы лучше организовать данные, обратим внимание на то, как мы разделяем и публикуем шаблоны. XSLT позволяет обрабатывать информацию итеративным образом. Например, можно поделить информацию на отдельные рецепты, а затем отформатировать инструкции и ингредиенты (см. листинг 9).

    Листинг 9. Выделение рецептов

    В данном случае таблица стилей выводит основную страницу (HTML), а затем просматривает каждый рецепт, выводя название, ингредиенты и инструкции для каждого рецепта. Опять-таки XPath мы будем изучать в разделе Подробнее об XPath, но в данном случае элемент recipe становится контекстным узлом, поэтому атрибуты select относятся к этому узлу так же как файлы к конкретному каталогу в файловой системе. Результат должен быть похож на рисунок 4.

    Рисунок 4. Элемент recipe становится контекстным узлом

    Отлично, формат приблизился к желаемому, однако нам все еще нужно отобразить фактическую информацию. Для этого надо изменить шаблоны ingredients и instructions (см. листинг 10).

    Листинг 10. Работа над шаблонами ingredients и instructions

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

    Наоборот, мы воспользовались тем, что когда указали процессору применять подходящие шаблоны к элементу ingredients , он ищет не только элемент ingredients , но и дочерние элементы элемента ingredients . Таким образом, он находит шаблон для ингредиентов, в котором вы выводите количество, единицы измерения, название продукта и разрыв строки.

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

    Результат должен быть похож на рисунок 5.

    Рисунок 5. Создание упорядоченного списка в основном шаблоне рецепта

    Определенно формат приближается к желаемому. Однако если вы посмотрите на вывод, то увидите, что проблема с пробелами все еще существует (см. листинг 11).

    Листинг 11. Недоработанный вывод

    Добавление пробелов

    Почему это случилось, если мы включали пробелы в таблицу стилей? Должны они были появиться в выводе? Разумеется, необязательно. Есть способы указать таблице стилей оставлять пробелы — они будут изучены в разделе Организация циклов и импорт — однако в некоторых случаях проще явно добавить текст в вывод (см. листинг 12).

    Листинг 12. Добавление текста

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

    Листинг 13. Окончательный вывод

    Результат показан на рисунке 6.

    Рисунок 6. Проблема отсутствующих пробелов решена

    Далее вы узнаете, как добавлять на страницу определенную информацию с помощью XPath.

    Основы XPath

    Возможность преобразовывать данные в форму, в какой вы желаете их видеть, требует понимания языка маршрутов XML, или XPath, который позволяет контролировать, какие именно данные публикуются и/или отображаются. Данный раздел объясняет основные понятия XPath и показывает, как создавать простые выражения.

    Что такое XPath?

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

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

    Вы также узнаете о некоторых более мощных функциях XPath и о предикатах — это в основном условные утверждения, которые можно добавлять в выражения. Например, в разделе Настройка контекста вы увидите, как выбирать все элементы recipe в документе; предикаты позволяют выбрать только конкретный элемент на основании конкретных критериев.

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

    Давайте начнем с изучения контекста выражения.

    Настройка контекста

    Первым шагом в понимании XPath является понимание того, что полученные результаты в большой степени определяются текущим контекстным узлом. Контекстный узел можно считать своеобразным знаком «ты находишься здесь», от которого можно двигаться в различных направлениях согласно выражению XPath. Например, рассмотрим простую таблицу стилей в листинге 14.

    Листинг 14. Демонстрация контекста

    Здесь есть новый элемент — copy-of . Там, где value-of выводит содержимое элемента, copy-of делает именно то, о чем говорит его название, и выводит фактический узел, на который ссылается атрибут select .

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

    Листинг 15. Простейшее преобразование

    Вы видите, что это просто повторение того же документа; это потому, что контекстный узел, как указано атрибутом шаблона match, — это корень документа, или /. Если вы измените контекстный узел, вывод изменится. Например, вы можете установить контекстный узел на первый рецепт (см. листинг 16).

    Листинг 16. Перемещение контекстного узла

    Теперь, запустив преобразование, вы увидите разницу (см. листинг 17).

    Листинг 17. Результаты

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

    Листинг 18. Выбор только заголовка

    Здесь вы выбираете элемент name , расположенный на один уровень ниже, чем текущий контекстный узел, поэтому результат будет как в листинге 19.

    Листинг 19. Результаты

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

    Листинг 20. Еще одно перемещение контекстного узла

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

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

    Листинг 21. Результаты

    Для чего нужны оси

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

    Для начала давайте поговорим о системе обозначений. Мы использовали упрощенную, укороченную форму запроса потомков. В «длинной форме» выражения задаются как child::name вместо ./name

    В обоих случаях вы задаете любой узел, который является потомком контекстного узла, а также является элементом name . Вы также можете связать их вместе, как в предыдущем случае, используя /child::recipes/child::recipe вместо /recipes/recipe .

    Потомки

    Возможно, вы недоумеваете, зачем мучаться с длинной формой, если короткая настолько проще. Это не было бы нужно, если бы единственное, что вы могли бы делать — это выбор потомков. Однако эту нотацию также можно использовать для выбора других отношений. Например, выражение XPath descendant::instruction выбирает все элементы instruction, которые являются потомками контекстного узла, а не только дочерние элементы. Кроме того, можно комбинировать инструкции. Например, вы можете выбрать все инструкции второго рецепта: /recipes/recipe[2]/descendant::instruction .

    Одной из разновидностей оси потомков является ось потомок-или-сам-элемент, которая выбирает заданный узел из всех потомков, а также ищет в самом контекстном узле. Например, выражение descendant-or-self::instructions выбирает все узлы instruction в контекстном узле и ниже его. Обычным сокращением для этой оси является двойная косая черта, //. Это означает, что выражения: /recipes/recipe[2]//instructions и //instructions выбирают все инструкции для второго рецепта и все инструкции в документе, соответственно. Этот второй пример очень широко применяется, он удобен, когда вы хотите просто выбрать все элементы определенного типа в документе.

    Атрибуты

    Еще одна общая задача, с которой вы столкнетесь — это необходимость выбрать атрибут для конкретного элемента. Например, вы, возможно, захотите выбрать recipeId для конкретного рецепта. Выражение /recipes/recipe/attribute::recipeId выбирает атрибут recipeId для всех элементов recipe . Эта ось также имеет сокращенную форму: это же выражение можно записать так: /recipes/recipe/@recipeId .

    Родители

    Все, что мы видели до этого, переносило нас вниз по дереву иерархии, но также существует возможность пойти вверх, выбрав предка конкретного узла. Предположим, что контекстным узлом была одна из инструкций, а вы хотите вывести recipeId для текущего рецепта. Вы можете сделать это следующим образом: ./parent::node()/parent::node()/@recipeId .

    Это выражение начинается в текущем узле — instruction -, а затем двигается к предку этого узла — элементу instructions — а затем к предку ТОГО элемента — recipe -, а затем к соответствующему атрибуту. Возможно, вам лучше знакома сокращенная форма: ./../../@recipeId .

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

    Более продвинутые возможности XPath

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

    Использование предикатов

    Зачастую требуется не просто любой узел, а конкретный узел, выбранный на основе конкретных условий. Вы ранее уже видели пример, когда использовали выражение /recipes/recipe[2]//instructions . Это на самом деле сокращенная версия выражения /recipes/recipe[position() = 2]//instructions , которое означает, что процессор XPath должен пройти через каждый элемент recipes (конечно, такой элемент только один) и для каждого элемента recipes пройти через каждый элемент recipe. Для каждого элемента recipe проверить истинность выражения position() = 2 . (Другими словами, есть ли в списке этот второй рецепт?) Если это предложение, называемое предикатом, истинно, то процессор использует этот узел и продолжает, возвращая любые инструкции.

    С помощью предикатов можно сделать множество вещей. Например, можно вернуть только рецепты, в которых есть название: /recipes/recipe[name] . Это выражение просто проверяет, существует ли элемент name — потомок элемента recipe . Также можно поискать конкретные значения. Например, можно возвращать только элементы, которые называются «A balanced breakfast»: //recipe[name=»A balanced breakfast»] .

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

    Листинг 22. Возвращение только названия первого рецепта

    В первом выражении сначала мы выбираем все элементы recipe , а затем возвращаем только тот, у которого есть атрибут элемента recipeId , равный 1. Найдя этот узел, мы двигаемся к его дочернему узлу, который называется name, и возвращаем его. Во втором выражении сначала отыскиваются все элементы name , а затем выбирается только тот, у чьего родителя имеется атрибут 1. В любом случае, вы получите один и тот же вывод (см. листинг 23).

    Листинг 23. Вывод

    Функции

    XPath также предоставляет ряд функций. Некоторые из них относятся собственно к узлам, — например, те, которые ищут конкретную позицию, — некоторые обрабатывают строки, некоторые , — такие как суммирование, — с числами, некоторые с булевскими значениями.

    Функции, связанные с узлами

    Функции, связанные с узлами, помогают, например, выбрать конкретный узел в зависимости от позиции. Например, вы можете специально запросить последний рецепт: //recipe[last()] . Данное выражение выбирает все элементы recipe , а затем возвращает только последний. Вы также можете использовать функции отдельно, вместо того чтобы использовать их как часть предиката. Например, вы можете специально запросить посчитать элементы recipe: count(//recipe) .

    Вы уже видели функцию position() и то, как она работает. Другие функции, связанные с узлами, включают id() , local-name() , namespace-uri() и name() .

    Строковые функции

    Большинство строковых функций предназначено для обработки строк, а не для их проверки, за исключением функции contains() . Функция contains() показывает, является ли данная строка частью большего целого. Это позволит, например, вернуть только узлы, содержащие определенные строки, такие как: //recipe[contains(name, ‘breakfast’)] .

    Это выражение возвращает элемент recipe, который содержит в своем элементе name строку «breakfast».

    Функция substring() позволяет выбрать конкретный диапазон символов из строки. Например, выражение: substring(//recipe[2]/name, 1, 5) возвращает A bal .

    Первый аргумент — это полная строка, второй — позиция первого символа, а третий — это длина диапазона.

    Среди прочих строковых функций имеются: concat() , substring-before() , substring-after() , starts-with() и string-length() .

    Числовые функции

    Числовые функции включают функцию number() , которая переводит значение в числовое, чтобы другие функции могли с ним работать. Числовые функции также включают: sum() , floor() , ceiling() и round() . Например, вы можете найти сумму всех значений recipeId при помощи выражения: sum(//recipe/@recipeId) .

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

    Функция floor() находит наибольшее целое, которое меньше или равно данному значению, а функция ceiling() находит наименьшее целое, которое больше или равно данному значению. Функция round() работает традиционным образом — округляет (см. листинг 24).

    Листинг 24. Результаты числовых функций

    Булевы функции

    Булевы функции наиболее полезны при работе с условными выражениями, о которых будет рассказано в разделе Условная обработка. Возможно, наиболее полезной функцией является not() , которая может быть использована для определения того, что определенный узел не существует. Например, выражение //recipe[contains(name, ‘breakfast’)] возвращает каждый рецепт, содержащий в элементе name строку «breakfast». Но что, если вам нужны все рецепты, кроме завтрака? Можно использовать выражение: //recipe[not(contains(name, ‘breakfast’))] .

    Другие булевы функции включают true() и false() , которые возвращают константы, и boolean() , которая преобразует значение в булево, чтобы его можно было использовать в качестве проверочного.

    Организация циклов и импорт

    Рассмотрим еще два важных аспекта использования таблиц стилей XSLT: создание циклов и импортирование внешних таблиц стилей.

    Организация циклов

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

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

    Листинг 25. Прямое применение стилей с использованием циклов

    Конструкция цикла очень похожа на структуру for-each , в честь которой она названа. Подобно тезке, каждый экземпляр цикла несет в себе следующее значение списка. В Java-программировании это могло бы быть следующее значение в массиве; здесь это следующий узел в совокупности узлов, возвращенных выражением XPath в атрибуте select . Это означает, что когда вы первый раз выполняете первый цикл, контекстным узлом является первый элемент ingredient . Это позволяет выбрать потомков этого элемента qty, unit и food и добавить их в документ так же, как это было сделано ранее при помощи шаблона. То же самое и с инструкциями, за исключением того, что они просто выводятся напрямую.

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

    Рисунок 7. Результаты

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

    Включение и импорт таблиц стилей

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

    Листинг 26. Файл ingredients.xsl

    Также можно создать отдельную таблицу стилей для инструкций (см. листинг 27).

    Листинг 27. Файл instructions.xsl

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

    Листинг 28. Включение таблиц стилей

    Хотя здесь мы разместили таблицы стилей в той же директории, что и основную таблицу, делать это не обязательно: атрибут href может содержать любой доступный URL. Обратите внимание, что мы отсылаем процессор на поиск шаблонов для элементов ingredients и instructions , которых нет в этом файле. Однако если обработать таблицу стилей, результат получится точно тот же, как если бы шаблоны были включены напрямую, а не через элемент include (см. рисунок 8).

    Рисунок 8. Результаты

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

    XSLT позволяет импортировать таблицу стилей в начало файла. Почему в начало? Потому что целью импорта таблицы стилей является возможность корректировки любых шаблонов, являющихся частью импорта. Например, мы можем импортировать шаблон ingredients и откорректировать его (см. листинг 29).

    Листинг 29. Импорт таблицы стилей

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

    Рисунок 9. Результаты

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

    Расширение XSLT

    Мы увидели, как сделать XSLT более похожим на программирование. Как насчет добавления к нему фактического программирования? Давайте взглянем на добавление функциональности Java к таблице стилей XSLT.

    Во-первых, следует отметить, что хотя механизм расширения является частью рекомендаций XSLT, рассматриваемая здесь реализация специфична для процессора Xalan XSLT. Основные идеи практически одинаковы для других процессоров, однако для уточнения деталей вам придется сверяться с документацией.

    Далее мы создадим расширение, которое позволит нам масштабировать рецепт на несколько порций.

    Элементы расширения

    Расширение XSLT производится с помощью различных методик. Первая — это использование элементов extension . Элемент extension — это элемент в пространстве имен, который указывает на класс Java. Взгляните, например, на следующий элемент extension (см. листинг 30).

    Листинг 30. Использование элемента extension

    Мы создали пространство имен, которое соответствует классу comp.backstop.RecipeScaler , который включает в себя статический метод под названием scaleMessage (см. листинг 31).

    Листинг 31. Класс RecipeScaler

    Добравшись до элемента, процессор видит префикс пространства имен scaler: и знает, что он обозначен как префикс элемента extension, и таким образом понимает, какой класс обозначен в определении пространства имен. Вызываемый им метод отвечает локальному имени элемента — scaleMessage . Сам метод получает два аргумента, из которых мы фактически используем один. Параметр context ссылается на контекст процессора, который позволяет взглянуть на элементы, относящиеся к элементу extension , однако мы просто займемся самим элементом extension . Так как мы получаем этот элемент как параметр метода, мы можем извлечь значения любых атрибутов, добавленных к этому элементу, таких как servings в данном случае. Текст, возвращенный методом, добавляется к выводу на месте элемента extension .

    Это означает, что если применить таблицу стилей, мы получим результаты, показанные на рисунке 10.

    Рисунок 10. Результаты элемента extension

    Элементы extension могут быть весьма полезны, хотя и несколько сложны в использовании.

    Функции extension

    Еще один способ добавить функциональность при помощи таблиц стилей — это использование функций extension, которые несколько проще реализовывать, чем элементы extension. Например, мы можем создать функцию, которая умножает количество ингредиентов и количество порций (см. листинг 32).

    Листинг 32. Метод scaleIngredient()

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

    Листинг 33. Добавление функции extension

    Учтите, что вызов функции включает префикс пространства имен. Как и ранее, процессор видит префикс и знает, что надо выполнить вызов класса RecipeScaler . В результате количество ингредиентов умножается на два (см. рисунок 11).

    Рисунок 11. Использование функции extension

    Хотя данный код и работает, поддерживать его сложно. Давайте посмотрим, как упростить поддержку.

    Программирование XSLT

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

    Переменные XSLT

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

    Листинг 34. Задание переменной

    XSLT позволяет создавать переменные; в ссылке используется знак доллара ($), который можно увидеть в листинге. Если применить таблицу стилей, можно увидеть два эффекта (см. рисунок 12).

    Рисунок 12. Использование переменной

    Обратите внимание, что ингредиенты были умножены на количество порций, как и ожидалось. Однако если вы посмотрите внимательнее, то увидите, что элемент extension сработал неверно, приняв переменную за строку, вместо того чтобы использовать значение самой переменной. Это не сбой; спецификация не требует, чтобы процессор что-либо делал со значениями атрибутов перед обработкой элемента extension. Поэтому нам надо как-то избежать этой проблемы.

    Условная обработка

    Первое, что мы можем сделать — это использовать условную обработку, чтобы сообщение отображалось, только если оно нужно. Например, см. листинг 35.

    Листинг 35. Использование элемента if

    Содержимое элемента if , заданное атрибутом test, должно быть равно true (истина). Если это не так, что и произошло в данном случае, вывод не появится вовсе (см. рисунок 13).

    Рисунок 13. Результаты предложения if

    В том виде, в каком оно написано, предложение не имеет особого смысла; если значение больше единицы, элемент extention отобразится со значением «3.» Лучше использовать множественный выбор (см. листинг 36).

    Листинг 36. Элемент choose

    В данном случае у нас имеется комбинация элементов if-then-else и предложения case из традиционных языков программирования. Элемент choose работает как контейнер, однако элемент when отображает его содержимое, только если его атрибут test равен true (истина). Наконец, если ни один из элементов when не равен true (истина), процессор отображает содержимое элемента otherwise .

    Результат получается такой, какого следует ожидать (см. рисунок 14).

    Рисунок 14. Результат

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

    Заключение

    Подведение итогов

    Данное руководство позволило продвинуться от начального знакомства с преобразованиями XSLT до составления достаточно сложных таблиц стилей. Сначала вы познакомились с основами таблиц стилей, затем с выражениями XPath — одной из основ XSLT. В последней части данного руководства были рассмотрены некоторые более сложные аспекты таблиц стилей XSLT — переменные, условная обработка и расширения. В результате у вас теперь должно быть достаточно знаний, чтобы делать с таблицами стилей XSLT практически все необходимое — или хотя бы понимать, что еще надо выяснить, если столкнетесь с проблемой.

    Основные команды XSLT

    Читайте также:

    1. A) Основные термины и определения
    2. Borland C и его основные режимы с характерными окнами
    3. D. Основные принципы.
    4. I. Основные права граждан
    5. I. Основные правила и принципы переноса слов
    6. II ОСНОВНЫЕ ПРАВИЛА МЕР БЕЗОПАСНОСТИ
    7. II. Основные понятия
    8. II.3.3. Основные направления денежно-кредитной политики
    9. III. Основные задачи и функции поисково-спасательных формирований ПСС МЧС России.
    10. III.2. Основные методы и критерии разрешения педагогических конфликтов
    11. V1: Предмет, метод и основные категории статистики как науки
    12. XIV. Основные понятия и методы математической статистики.

    xsl:apply-templates — Применение XSLT шаблона

    Атрибуты: select — расширенное X-Path выражение (опционально). Текстовое содержание отсутствует.

    Описание: Команда рекурсивно вызывает XSLT шаблон xsl:template с атрибутом match, совпадающим с X-Path выражением select, для всех потомков текущего XML узла, соответствующих данному выражению. Если атрибут select не задан, для каждого потомка текущего XML узла рекурсивно будет вызываться соответствующий XSLT шаблон xsl:template.

    Настольный справочник по атакам на XML-приложения

    Содержание статьи

    С одной стороны, тема XML injection — это жуткий баян, а с другой — она так популярна, что баги такого типа присутствовали во многих X-конкурсах последнего времени, например ZeroNights HackQuest и месяце поиска уязвимостей в Яндексе. В этой статье мы постарались собрать и систематизировать все, что известно об XML injection на данный момент.

    WARNING

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

    Часть первая, теоретическая

    Начнем издалека. Стандартом определены два уровня правильности документа XML:

    1. Правильно построенный (well-formed) документ. Такой документ соответствует общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный XML.
    2. Действительный (valid) документ. Действительный документ дополнительно соответствует некоторым семантическим правилам. Это более строгая проверка корректности документа на соответствие заранее определенным, но уже внешним правилам. Эти правила описывают структуру документа: допустимые названия элементов, их последовательность, названия атрибутов, их тип и тому подобное. Обычно такие правила хранятся в отдельных файлах специального формата — схемах.

    Основные форматы определения правил валидности XML-документов — это DTD (Document Type Definition) и XML Schema. Остановимся на DTD. Стандартом предусмотрено два варианта связывания документа с его схемой: либо через ссылку на схему в заголовке XML-документа (этот заголовок называется Document Type Declaration):

    либо через описание схемы в документе inline (аналогия: подключение CSS через ссылку или inline):

    Самое интересное в DTD — это то, что умные люди придумали так называемые сущности. Придумали, чтобы можно было подключать часто используемые фрагменты XML-документов по имени. Сущность определяется в DTD через директиву и используется в документе как &name;. А потом кто-то подумал, что глобализация должна быть глобальной, и придумал еще и внешние сущности (external entities). Например, можно определить внешнюю сущность current-date:

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

    Успешное разрешение внешней сущности, указывающей на /etc/passwd

    Хакер #156. Взлом XML Encryption

    Соответственно, наш пример с добавлением текущей даты заказа перепишется так:

    Последний элемент технологии — парсеры, которые, собственно, и разбирают XML-документы, валидируют их, разрешают внешние сущности, реализуют стандартный интерфейс к построенной объектной модели (DOM) и тому подобное. Парсеры бывают валидирующими и невалидирующими. Вот что сказано в стандарте о поведении парсера при наличии в документе ссылок на внешние сущности:

    «When an XML processor recognizes a reference to a parsed entity, in order to validate the document, the processor must include its replacement text. If the entity is external, and the processor is not attempting to validate the XML document, the processor may, but need not, include the entity’s replacement text. »

    Это важно! Тут говорится, что валидирующий парсер обязан включить в документ содержимое внешнего файла (логично, иначе как парсер проверит правильность структуры документа?), а невалидирующий — по желанию. Однако на практике это свойство «по желанию» выполняется практически у всех популярных парсеров.

    Популярные XML-парсеры

    Интерпретируемые языки (PHP, Perl, Python, Ruby и другие):

    • большинство парсеров используют библиотеки libxml2 (xmlsoft.org, последняя версия — 2.7.8) и libxslt (xmlsoft.org/XSLT/);
    • некоторые парсеры используют другие библиотеки (например, модуль expat-XML::Parser в Perl использует библиотеку Expat XML Parser) либо полностью реализуются на «родном» языке (например, парсер REXML в Ruby).

    Java:

    • Apache Xerces: xerces.apache.org, последняя версия — 2.11.0;
    • (для XSLT) Apache Xalan-Java: xml.apache.org/xalan-j/, последняя версия — 2.7.1;
    • работа с XML-парсерами в Java реализуется через общий интерфейс Java API for XML Processing (JAXP. В ранних версиях Java через JAXP был доступен парсер Crimson от Sun).

    Windows-платформа, .NET:

    • в большинстве Windows-приложений (написанных на Delphi, JScript, VBScript и так далее) для обработки XML используется парсер MSXML (goo.gl/hPdbg, последняя версия — 6.0 SP2);
    • в .NET-приложениях для парсинга XML используются классы из пространства имен System.XML (XmlTextReader, XslTransform и другие).

    Часть вторая, переходная

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

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

    1. В HTTP-запрос, в котором на сервер передается XML, вставляем .
    2. В теле XML-документа даем ссылку на сущность — &xxe; .
    3. В ответе получаем содержимое локального файла.

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

    Есть три класса популярных платформ: .NET, Java и интерпретируемые языки (PHP, Perl, Python, Ruby и подобные). Отметим, что все перечисленные ниже парсеры по умолчанию не производят валидацию обрабатываемого документа. В Windows и .NET используются MSXML-парсер и пакет System.xml соответственно. Только начиная с шестой версии, библиотека MSXML перестала разрешать ссылки на внешние сущности по умолчанию. В Java обычно используются пакеты Xerces и Xalan (для XSLT). И в том и в другом пакете ссылки на внешние сущности по умолчанию разрешаются. Наши же любимые интерпретируемые языки используют библиотеки libxml2 и libxslt (для XSLT), которые тоже по умолчанию разрешают ссылки на внешние сущности. Вывод: запрет на разрешение внешних сущностей в подавляющем большинстве случаев (библиотек) — ответственность программиста.

    SOAP и DTD

    Спецификация протокола SOAP подробно регламентирует структуру SOAP-сообщения, в частности явно запрещает использование DTD:

    «The XML infoset of a SOAP message MUST NOT contain a document type declaration information item».

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

    Для того чтобы понять, насколько много уязвимостей XXE присутствует в реальном мире, надо разобраться с тем, где и когда в веб-приложениях используются парсеры. Мы выделяем два класса использования парсеров: на уровне платформы / стандартных библиотек и на уровне прикладного (своего) кода. Типичный пример использования парсеров на уровне платформы —поддержка протоколов XML-RPC и SOAP, на уровне прикладного кода — реализация обмена данными между приложением и пользователем: импорт, экспорт и так далее. Со вторым случаем все ясно — вряд ли найдется много программистов, которые при инициализации XML-парсеров подумают о том, чтобы запретить разрешение внешних сущностей. Поэтому большинство функций импорта данных в веб-приложение через XML являются уязвимыми к внедрению внешних сущностей (за примером далеко ходить не надо: LFI через XXE-уязвимость в phpMyAdmin — goo.gl/5RDrM).

    Разберемся теперь с первым случаем — уровнем платформы. Посмотрим, что говорят спецификации протоколов XML-RPC и SOAP про внешние сущности. В спецификации SOAP нас расстраивают: «a SOAP message MUST NOT contain a document type declaration information item». Как показывает опыт, наличие правил в стеке еще не означает, что их будут выполнять на практике. Тем не менее, шансов найти уязвимость в коде платформы, реализующей SOAP, намного меньше, чем в прикладном коде. С протоколом XML-RPC ситуация значительно лучше (для нас): про запрет внешних сущностей или подключение DTD в спецификации не сказано ни слова.

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

    1. Custom-приложения с функцией импорта данных в XML.
    2. Приложения, реализующие протокол XML-RPC.
    3. Веб-сервисы, реализующие протокол SOAP.

    Защищаемся

    На примере Xerces-парсера покажем, как можно защититься от XXE. Итак, устанавливаем необходимые значения для свойств парсера:

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

    • Протокол XML-RPC: разработан в 1998 году (xmlrpc.scripting.com/spec.html), автор — Дэйв Уинер (Dave Winer).
    • Протокол SOAP: разработан в 1998 году, текущая версия спецификации Simple Object Access Protocol specification Version 1.2 (www.w3.org/TR/soap12-part1/).

    Часть третья, практическая

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

    1. Необходимо разместить на своем веб-сервере тестовый документ extdoc.txt с каким-нибудь содержимым, например «include me please!» (на самом деле файл можно даже не размещать!).
    2. Дать ссылку на него в XML-теле HTTP-запроса.
    3. Проверить access.log нашего веб-сервера — а не обратился ли кто к нему? (Или ищем ошибку 404, если не размещали.)

    Входной параметр — URL модуля, который сделает XSLT-трансформацию
    по XSL-файлу

    Учитывая, что в протоколах SOAP и XML структура ожидаемого на сервере документа известна, описанный процесс тестирования легко автоматизируется (скрипты и описание ты найдешь на диске):

    1. Берем список URL, реализующих XML-протоколы, и в цикле отправляем по каждому адресу XML-документ (мы его заготовили заранее) формата SOAP или XML-RPC с внешней сущностью, которая ссылается на файл с нашего сервера. При отправке записываем IP-адрес и доменное имя очередного кандидата в файл.
    2. Наш веб-сервер сконфигурирован не отдавать документ с телом XML-сущности как статический файл, а перенаправлять запросы к нему на специальный обработчик (например, php). Mod_Rewrite в помощь. Обработчик фиксирует все входящие запросы в журнал, записывая IP-адрес отправителя.
    3. Чекаем полученные списки по IP-адресам и понимаем, какие URL заходили к нам за файлом.
    4. Здесь следует учесть, что сетевой фильтр на стороне тестируемого веб-приложения может запрещать исходящие соединения в интернет, тогда наш метод «в лоб» не сработает. Внимательный читатель спросит: откуда же взять эти начальные списки URL для проверки? Конечно, у заказчика тестирования, ответим мы; после чего случайно оброним парочку намеков на паттерны гуглопоиска:

    XXE в Safari позволяет вредоносной веб-странице считывать локальные файлы с машины клиента

    Итак, тестируемое нами приложение разрешает внешние сущности. Что дальше?

    1. DoS — на никсах и на винде (последнее работает нестабильно).
    2. Сканируем локальную сеть — . Помни, что сообщения об ошибках и временные задержки — наше все! Кстати, про случай из жизни, связанный с этим трюком, написано в статье «Funny hacks» Владимира Воронцова в этом номере.
    3. Читаем локальные файлы. Казалось бы, все должно быть просто: вставляем и мы на коне! Но нет.

    Во-первых, тебе кто-то обещал, что сущность, которую ты определил в HTTP-запросе, попадет в HTTP-ответ? Правильно, никто не обещал. Должно повезти. Стоит сказать пару слов про методику тестирования. В custom-приложениях и SOAP-сервисах формат обрабатываемого XML-документа известен (помним про WSDL). То есть нам необходимо во все теги отправляемого документа запихнуть ссылку на нашу сущность и посмотреть, вернется ли она в ответе. С XML-RPC дела обстоят хуже: в общем случае мы не знаем сигнатур методов, реализуемых приложением. Т.е. автоматизировать подстановку сущностей в параметры вызываемых RPC-методов в общем случае нам не удастся. Тут тебе в помощь может прийти спек, описывающий расширение XML-RPC, — http://xmlrpc-c.sourceforge.net/introspection.html. Используя его, ты, например, можешь получить список методов, поддерживаемых на сервере. Увы, далеко не все XML-RPC приложения реализуют интроспекцию. Во-вторых, почему после подстановки сущности итоговый XML должен остаться правильно построенным? Хорошо, что как минимум в случае с PHP по этому поводу беспокоиться не стоит, — делаем base64-обертку вокруг считываемых данных:

    Далее мы должны познакомить тебя еще с одним интересным методом внедрения XML. Данный метод может привести к выполнению кода на сервере. Есть такая технология, называется XSLT (см. врезку). Обычно она используется для перевода XML-документов, обрабатываемых веб-приложением, в пригодный для отображения в браузере вид. Для трансформации нужны два XML-документа: исходный документ, который мы хотим трансформировать, например, в XHTML, и документ с описанием трансформации. В 99% случаев документ, описывающий трансформацию, лежит на сервере веб-приложения, а путь к нему прописан в каком-нибудь конфиге. В остальном проценте случаев путь к нему передается в URL (:facepalm:). Учитывая такой дизайнерский шаг, можно быть уверенным в том, что интересующий нас HTTP-параметр не подвергается никакой обработке, то есть мы сможем указать XSL-документ, лежащий на нашем сервере. А дальше, если XSLT-трансформатор был инициализирован в PHP-коде кривого веб-приложения следующим образом:

    то мы сможем внутри XSL-документа использовать PHP-функции, например, вот так:

    Хорошо, что подобных приложений в природе мало (google кунг-фу поможет тебе их найти) и с каждым днем становится все меньше :).

    XSL и XSLT

    Extensible Stylesheet Language (XSL) — это группа языков, предназначенных для преобразования XML-документов или их визуального представления. Эта группа состоит из трех частей:

    • XSL Transformations (XSLT) — язык преобразований XML-документов;
    • XSL Formatting Objects (XSL-FO) — язык, специфицирующий визуальное представление XML-документа;
    • XML Path Language (XPath) — язык, предназначенный для доступа к определенным частям XML-документа (используется как в контексте XSLT, так и самостоятельно).

    Специфицируется консорциумом W3C (Extensible Stylesheet Language (XSL) Version 1.1).

    Часть четвертая, демонстрационная

    Мы подумали: интересно, а за сколько мы сможем найти в интернете приложение, уязвимое не просто к классической XXE-атаке, а чтобы там еще и XSLT-трансформация была? Сказано — сделано.

    Перво-наперво мы пошли на сервисы поиска программного кода (opensearch.krugle.org, koders.com), а также в Google (пользуясь случаем, хочу выразить глубокое сожаление по поводу так не вовремя закрытого сервиса Google Code Search). Нас интересовал заведомо уязвимый участок кода, связанный с загрузкой XML- или XSL-документа для последующей XSLT-трансформации, имя которого берется прямо из параметра GET-запроса. Таким образом мы искали строки вида «$xsldoc->load($_GET» и «$xmldoc->load($_GET». В результате нашлись проекты с уязвимым кодом, но масштаб проектов нам не понравился, и мы решили не связываться с ними. Следующей идеей был поиск веб-приложений, в которых есть модули XSLT-трансформации, принимающие в качестве аргумента имя XML-документа: inurl:»transform.php?xml=» (и потрясающее inurl:»transform.py?xml=» — от структуры URL на сайтах из выдачи слезы наворачивались на глаза). В итоге для дальнейшего анализа мы взяли одно из приложений, в URL которого было значение /path/transform.php?xml= . Нам повезло, что обо всех ошибках, возникших при трансформации, приложение радостно сообщало в HTTP-ответе. Первым делом нам интересно было узнать, что произойдет, если вместо имени локального XML-файла указать что-то удаленное: /path/transform.php?xml=http://ya.ru/. Как мы и предполагали, оно деловито полезло за XML-документом на Яндекс, но поперхнулось (см. иллюстрацию).

    Дальше план был таков:

    1. Скачать на управляемый нами веб-сервер исходный XML-документ, который успешно проходит трансформацию. Документ, очевидно, был доступен как /path/ .
    2. Добавить в документ inline-DTD, в которой определить парочку сущностей — простую и внешнюю:

    а в самом XML-документе сослаться на простую сущность pi (для начала).

  • Запросить трансформацию заряженного XML с нашего сервера: /path/transform.php?xml=http://youllneverguessthena.me/inc.xml и поискать в ответе число пи (почему его там могло не оказаться — читай ниже). Нам повезло — сущности, разрешаемые парсером в исходном документе, проходили трансформацию в конечный документ. Нам оставался последний шаг.
  • Модифицируем XML-документ на нашем сервере второй раз, добавляя ссылку на внешнюю сущность (&htaccess;) в тело документа, и повторяем запрос на трансформацию. Конечно, читать остальные файлы (в том числе /etc/passwd и /dev/zero) мы не стали, зато уведомили администратора сайта об уязвимости.
  • XXE в Яндексе обнаружилась при обработке SOAP (к слову о specification vs implementation)

    Теперь пару слов о том, почему нам повезло. Вообще-то XSLT-трансформатор не обязан выводить в итоговый документ сущности, разрешенные в исходном. Чтобы заставить его это сделать, в libxml2 (а следовательно, и в PHP) нужен дополнительный вызов. В итоге код, реализующий трансформацию, должен быть примерно таким (ключевая строка — substituteEntities ):

    • Спецификация XML 1.0L: goo.gl/nUKXz.
    • Список XML-протоколов от W3C: goo.gl/KzUVZ.
    • Блог Владимира Воронцова, описание XXE в Яндексе: goo.gl/9KIax.

    Заключение

    Вообще отношение к сущностям во время трансформации сильно зависит (внезапно!) от конкретного парсера. Так что на практике тебе придется проверять поведение в каждом конкретном случае. Сохранение сущностей после трансформации в современных XML-парсерах — отличная тема для хорошего и очень востребованного обзора. Anyone? У нас все.

    Что такое код xslt_set_log

    xslt_set_log — Set the log file to write log messages to

    Description vo >xslt_set_log ( resource xh, mixed log)

    A reference to the XSLT parser.

    This parameter is either a boolean value which toggles logging on and off, or a string containing the logfile in which log errors too.

    This function allows you to set the file in which you want XSLT log messages to, XSLT log messages are different than error messages, in that log messages are not actually error messages but rather messages related to the state of the XSLT processor. They are useful for debugging XSLT, when something goes wrong.

    By default logging is disabled, in order to enable logging you must first call xslt_set_log() with a boolean parameter which enables logging, then if you want to set the log file to debug to, you must then pass it a string containing the filename:

    Example 1. Using the XSLT Logging features

    $result = xslt_process ( $xh , ‘dog.xml’ , ‘pets.xsl’ );
    echo $result ;

    xslt_free ( $xh );
    ?>

    Note: Please note that file:// is needed in front of path if you use Windows.

    Что такое код xslt_set_log

    xslt_set_log — Set the log file to write log messages to

    Description vo >xslt_set_log ( resource xh [, mixed log] )

    A reference to the XSLT parser.

    This parameter is either a boolean value which toggles logging on and off, or a string containing the logfile in which log errors too.

    This function allows you to set the file in which you want XSLT log messages to, XSLT log messages are different than error messages, in that log messages are not actually error messages but rather messages related to the state of the XSLT processor. They are useful for debugging XSLT, when something goes wrong.

    By default logging is disabled, in order to enable logging you must first call xslt_set_log() with a boolean parameter which enables logging, then if you want to set the log file to debug to, you must then pass it a string containing the filename.

    Note: Please note that file:// is needed in front of path if you use Windows.

    Новые книги

    Рано или поздно продажи в любом бизнесе «замирают». Чтобы не сдать позиции конкурентам, необходимо ежедневно завоевывать и удерживать клиентов.

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

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

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

    В книге Бертрана Мейера рассматриваются основы объектно-ориентированного программирования. Изложение начинается с рассмотрения критериев качества программных систем и обоснования того, как объектная технология разработки может обеспечить требуемое качество. Основные понятия объектной технологии и соответствующая нотация появляются как результат тщательного анализа и обсуждений. Подробно рассматривается понятие класса — центральное понятие объектной технологии. Рассматривается абстрактный тип данных, лежащий в основе класса, совмещение классом роли типа данных и модуля и другие аспекты построения класса. Столь же подробно рассматриваются объекты и проблемы управления памятью. Большая часть книги уделена отношениям между классами – наследованию, универсализации и их роли в построении программных систем. Важную часть книги составляет введение понятия контракта, описание технологии проектирования по контракту, как механизма, обеспечивающего корректность создаваемых программ. Не обойдены вниманием и другие важные темы объектного программирования – скрытие информации, статическая типизация, динамическое связывание и обработка исключений. Глубина охвата рассматриваемых тем делает книгу Бертрана Мейера незаменимой для понимания основ объектного программирования.

    Илон Маск рекомендует:  ch в CSS
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL