Парсер против лексера и XML
Сейчас я читаю об архитектуре компиляторов и синтаксических анализаторов и меня интересует одна вещь ... , Когда у вас есть XML, XHTML, HTML или любой другой язык на основе SGML, , какова будет роль лексера здесь, и какими будут токены?
Я читал, что токены как слова , подготовленные для разбора лексером . Хотя у меня нет проблем с поиском токенов для языков C, C ++, Pascal и т. Д., Где есть ключевые слова, имена, литералы и другие словоподобные строки, разделенные пробелами, с XML у меня есть проблема, потому что нет ' т любые слова! Это только обычный текст, чередующийся с разметкой (тегами).
Я подумал, что эти теги и фрагменты простого текста могут быть токенами, что-то вроде этого: [TXT] [TAG] [TAG] [TXT] [TAG] [TXT] [TAG] [TAG] [TXT] ... . Это было бы вполне разумно, так как SGML не волнует, что Я не вижу способа распознать разметку с помощью простого детерминированного конечного автомата (DFA) в лексере. Похоже, что он требует отдельного контекста для автомата, когда он находится внутри тега, и другого контекста, когда он встречает значение атрибута. Я думаю, что для этого потребуется стек состояний / контекстов, поэтому DFA может с этим не справиться. Я прав?
Что ты думаешь? Хорошо ли делать токены из тегов (разметки) и простого текста?
Здесь: http://www.antlr.org/wiki/display/ANTLR3/Parsing+XML
используется какой-то другой техника: они обрабатывают и > (а также и /> ) как отдельные токены и внутри тегов, которые используют GENERIC_ID в качестве токена и т. Д. Они обычно переносят большую часть работы на анализатор. Но они также должны изменить контексты для токенизатора: они используют другой контекст в простом тексте и различаются в разметке (но я думаю, что они забыли о контексте значений атрибутов, потому что первое появление > завершит тег в их лексере).
Так, каков наилучший подход для анализа SGML-подобных языков? Лексер действительно используется там? Если да, какие строки составляют токены?
1 ответ
После создания парсеров XML и HTML у меня есть мнение.
Лексемы в целом должны быть узнаваемыми языковыми элементами.
Для XML и HTML они в основном соответствуют
- TAGBEGIN, что-то в форме
- TAGEND, в форме >
- TAGCLOSE, в форме
- TAGENDANDCLOSE в форме /> (только XML)
- ATTRIBUTENAME в форме NAME
- EQUALSIGN, то есть =
- ATTRIBUTEVALUE, являющееся значением точной строки символов, представленной атрибутом, независимо от кавычек (или даже отсутствия кавычек для устаревшего HTML). Если внутри атрибута есть экранированные коды символов, эти коды следует преобразовать в их фактические коды символов.
- CONTENT — текст между тегами TAGEND и TAGBEGIN. Как и в ATTRIBUTEVALUES, любые экранированные символы должны быть преобразованы, поэтому СОДЕРЖИМОЕ между foo
Мы можем спорить о том, хотите ли вы создавать токен для комментариев HTML/XML или нет. Если вы делаете, вы делаете.
Если мы игнорируем сложности DTD и схем для XML, это все, что вам действительно нужно.
То, как лексер производит их, более сложно; с XML и HTML возникает много беспорядка, связанного с экранированием во входном потоке, <[CDATA ...]> (если я прав), это просто забавная цитата, которая исчезает при создании лексемы CONTENT. Чтобы справиться со всем этим, вам нужен довольно сложный лексический движок. И да, на практике вам нужны разные лексические состояния («режимы») для обработки разных частей текста. У меня в значительной степени есть один основной режим для обработки вещей внутри <... > и один основной режим для обработки СОДЕРЖИМОГО.