SAX ( Simple API for XML ) — это управляемый событиями онлайн-алгоритм для лексического анализа и парсинга XML- документов с API , разработанным списком рассылки XML-DEV. [1] SAX предоставляет механизм для чтения данных из XML-документа, который является альтернативой тому, который предоставляется Document Object Model (DOM). В то время как DOM работает с документом в целом, строя полное абстрактное синтаксическое дерево XML-документа для удобства пользователя, SAX-парсеры работают с каждой частью XML-документа последовательно, выдавая события парсинга, выполняя один проход через входной поток.
В отличие от DOM , для SAX не существует формальной спецификации. Реализация SAX на Java считается нормативной . [2] SAX обрабатывает документы независимо от состояния, в отличие от DOM, который используется для зависящей от состояния обработки XML-документов. [3]
Парсеру SAX нужно только сообщать о каждом событии парсинга по мере его возникновения, и обычно он отбрасывает почти всю эту информацию после сообщения (однако он сохраняет некоторые вещи, например, список всех элементов, которые еще не были закрыты, чтобы отлавливать последующие ошибки, такие как конечные теги в неправильном порядке). Таким образом, минимальный объем памяти, требуемый для парсера SAX, пропорционален максимальной глубине XML-файла (т. е. XML-дерева) и максимальному объему данных, вовлеченных в одно XML-событие (например, имя и атрибуты одного начального тега или содержимое инструкции по обработке и т. д.).
Обычно такой объем памяти считается незначительным. Анализатор DOM, напротив, должен сначала построить древовидное представление всего документа в памяти, таким образом, используя память, которая увеличивается с длиной всего документа. Это занимает значительное время и место для больших документов (выделение памяти и построение структуры данных требуют времени). Компенсирующим преимуществом, конечно, является то, что после загрузки к любой части документа можно получить доступ в любом порядке.
Из-за событийно-управляемой природы SAX обработка документов, как правило, намного быстрее, чем парсеры в стиле DOM, если только обработка может быть выполнена в проходе от начала до конца. Многие задачи, такие как индексация, преобразование в другие форматы, очень простое форматирование и тому подобное, могут быть выполнены таким образом. Другие задачи, такие как сортировка, перестановка разделов, переход от ссылки к ее цели, поиск информации об одном элементе для помощи в обработке более позднего и тому подобное, требуют доступа к структуре документа в сложных порядках и будут выполняться намного быстрее с DOM, чем с несколькими проходами SAX.
Некоторые реализации не совсем подходят ни к одной из категорий: подход DOM может хранить свои постоянные данные на диске, умело организованные для скорости (редакторы, такие как SoftQuad Author/Editor, и браузеры/индексаторы больших документов, такие как DynaText , делают это); в то время как подход SAX может умело кэшировать информацию для последующего использования (любой проверяющий парсер SAX сохраняет больше информации, чем описано выше). Такие реализации размывают компромиссы DOM/SAX, но часто очень эффективны на практике.
Из-за природы DOM потоковое чтение с диска требует таких методов, как ленивая оценка , кэши, виртуальная память , постоянные структуры данных или другие методы (один из таких методов раскрыт в патенте США 5557722). Обработка XML-документов, превышающих размер основной памяти, иногда считается невозможной, поскольку некоторые парсеры DOM не позволяют этого. Однако это не менее возможно, чем сортировка набора данных, превышающего размер основной памяти, с использованием дискового пространства в качестве памяти для обхода этого ограничения. [4]
Событийно-управляемая модель SAX полезна для анализа XML, но у нее есть определенные недостатки.
Практически любая проверка XML требует доступа к документу в полном объеме. Самый простой пример — атрибут, объявленный в DTD как имеющий тип IDREF, требует, чтобы в документе был только один элемент, который использует то же значение для атрибута ID. Чтобы проверить это в парсере SAX, необходимо отслеживать все атрибуты ID (на любой из них может ссылаться атрибут IDREF в самом конце); а также каждый атрибут IDREF, пока он не будет разрешен. Аналогично, чтобы проверить, что каждый элемент имеет приемлемую последовательность дочерних элементов, информация о том, какие дочерние элементы были видны для каждого родителя, должна храниться до тех пор, пока родитель не закроется.
Кроме того, некоторые виды обработки XML просто требуют доступа ко всему документу. XSLT и XPath , например, должны иметь возможность доступа к любому узлу в любое время в проанализированном дереве XML. Редакторы и браузеры также должны иметь возможность отображать, изменять и, возможно, повторно проверять в любое время. Хотя парсер SAX вполне может быть использован для построения такого дерева изначально, SAX не предоставляет никакой помощи для такой обработки в целом.
Парсер , реализующий SAX (т. е. SAX Parser ), функционирует как потоковый парсер с API, управляемым событиями . [1] Пользователь определяет ряд методов обратного вызова , которые будут вызываться при возникновении событий во время парсинга. События SAX включают (среди прочих):
Некоторые события соответствуют объектам XML, которые легко возвращаются все сразу, например комментарии. Однако элементы XML могут содержать много других объектов XML, и поэтому SAX представляет их так же, как и сам XML: одним событием в начале и другим в конце. Строго говоря, интерфейс SAX имеет дело не с элементами , а с событиями , которые в значительной степени соответствуют тегам . Анализ SAX является однонаправленным; ранее проанализированные данные не могут быть повторно прочитаны без повторного запуска операции анализа.
Существует множество реализаций, подобных SAX. На практике детали различаются, но общая модель та же. Например, атрибуты XML обычно предоставляются как аргументы имени и значения, передаваемые событиям элемента, но также могут предоставляться как отдельные события или через хэш-таблицу или подобную коллекцию всех атрибутов. С другой стороны, некоторые реализации предоставляют обратные вызовы "Init" и "Fin" для самого начала и конца разбора; другие этого не делают. Точные имена для заданных типов событий также немного различаются между реализациями.
Дан следующий XML-документ:
<?xml version="1.0" encoding="UTF-8"?> <DocumentElement param= "value" > <FirstElement> ¶ Какой-то текст </FirstElement> <?some_pi some_attr="some_value"?> <SecondElement param2= "something" > Pre-Text <Inline> Встроенный текст </Inline> Последующий текст. </SecondElement> </DocumentElement> При передаче этого XML-документа через анализатор SAX будет создана последовательность событий, подобная следующей:
Обратите внимание, что первая строка приведенного выше примера представляет собой декларацию XML, а не инструкцию по обработке; как таковая она не будет сообщена как событие инструкции по обработке (хотя некоторые реализации SAX предоставляют отдельное событие только для декларации XML).
Результат выше может отличаться: спецификация SAX намеренно заявляет, что заданный раздел текста может быть представлен как несколько последовательных текстовых событий. Многие парсеры, например, возвращают отдельные текстовые события для числовых ссылок на символы. Таким образом, в примере выше парсер SAX может генерировать другую серию событий, часть из которых может включать:
Сокращение от Simple API for XML, API на основе событий, которое, как альтернатива DOM, позволяет кому-либо получать доступ к содержимому XML-документа. SAX изначально был API только для Java. Текущая версия поддерживает несколько сред языков программирования, отличных от Java. SAX был разработан членами списка рассылки XML-DEV.
Примечание: В двух словах, SAX ориентирован на независимую от состояния обработку, где обработка элемента не зависит от элементов, которые были до этого. StAX, с другой стороны, ориентирован на зависимую от состояния обработку. Для более подробного сравнения см. SAX и StAX в Basic Standards and When to Use SAX.
эти тесты этого не показывают, SAX-парсеры обычно быстрее для очень больших документов, где модель DOM обращается к виртуальной памяти или потребляет всю доступную память.