Здесь тэг script содержит текстовую ноду div. Любой другой тэг в этой ситуации содержал бы вложенный тэг div. А значит, парсить скрипты нужно всё-таки несколько по-другому.
Для парсера без разницы — что внутри у тега script. Синтаксический анализатор построил токены, лексический прошелся по ним, и после обработки все, что внутри script, превращается в текстовую ноду. Да, для данного случая анализ сложнее, но сути это не меняет. То, что код внутри не валиден — не проблема парсера html. Уж логика у вас больно странная — автор может вырезать script, но не может вместо этого создать ноду с текстом.
Неа, нельзя. HTML не является регулярным языком.
Читайте не между строк. Писалось о простом парсере, который будет работать с минимумом проблем. Хотя, если пойти дальше, то все равно: https://habr.com/ru/post/171667/ Льзя. Вы уж простите, но nikic'у я верю больше. https://www.w3.org/TR/WD-html-lex/ Ну и у w3c получилось на lex, который использует регулярные выражения. А вы и дальше считайте, что нельзя.
Это небольшая ошибка, я имел ввиду то, что парсер меняем состояние и начинает дальнейшую цепочку символов обрабатывать как тег.
Это смысловая ошибка, читатель не должен догадываться о том, что вы имели ввиду.
Прошу прощения, хотя с другой стороны, тем кто вообще не знаком с синтаксическими анализаторами, как мне кажется, будет более понятен мой вариант объяснения.
Да, читатель может не знать о анализаторах, но вы публикуетесь на техническом ресурсе, где соответствующая аудитория, и контент должен соответствовать. Аудитории будет понятнее и удобнее, если они будут встречать определенные, устойчевые, термины и методы, используемую литературу. Если содержания статьи им будет недостаточно, появиться желание углубиться — они будут знать о том, что им нужно искать.
Также я читал книгу по трансляторам, более того, некоторый материал будет использоваться в дальнейших частях цикла.
Собственно, данный материал должен был использоваться и в этой статье.
Например про те же состояния и теорию конечных автоматов. Частей будет еще где-то две.
Если бы вы описывали процесс, с информацией, указанной выше, то можно было бы еще поверить в две хорошие части, разделенные на: теоретическую и практическую, либо на: разбор и анализ. Что же вы хотите растянуть на три, описывая информацию вашей манерой — непонятно.
Касательно нод. Вы не учли ноду комментариев, а ведь они тоже будут в документе, и их тоже нужно будет обрабатывать.
Вы не учли то, что я писал комментарий, а не статью. Да, для них будет отдельное правило.
Также хочу отметить, что вариант написания парсера на регулярках — плохая идея. Такой парсер будет работать примерно так же, как simple dom.
Естественно — на одной регулярке, получится простая поделка и далеко не уедешь, но другого я и не утверждал. Боюсь, сейчас вы показали полное отсутствие компетентности в данной теме. В профильной литературе, и, например, в lex регулярные выражения используются повсеместно.
Сомнительная статья. Как такое попадает в лучшее?
На первом же изображении: «Берем символ, если он равен '<' — считаем его тегом и обрабатываем». Считаем символ тегом? И таких ошибок — куча.
Информации мало.
Сама информация — низкого качества. Выдумываете бред.
С наскоку дам больше информации лучшего качества:
Html — имеет простую структуру, смотрим rfc1866.
Имеем два типа нод: TagNode и TextNode (не может иметь детей).
Скрипты и стили к парсингу отношения не имеют и рассматриваются как обычные теги, содержащие одну дочернюю TextNode.
Самый простой парсер можно написать на регулярках, и через рекурсию строить дерево.
Если есть желание написать что-либо более интересное — читаем «книгу Дракона», да, она о разработке компиляторов, но в ней полно информации по интересующей нас теме — синтаксическом и лексическом анализе. Определяем алфавит, лексемы. Пишем лексический анализатор (автомат), который все это обрабатывает, пропускаем исходный код и на выходе получаем список лексем. Дальше строим из лексем плоский массив из открывающих/закрывающих тегов, блоков текста. В конце проходим по этому массиву строим дерево и заодно выявляем ошибки — незакрытые теги, цепи и.т.д.
Собственно, не смотря на то, что пост явно рекламный, опишу iiko. Работаем с одним предприятием на данной системе. Половина сайтов с информацией — нерабочие и сырые. Информация разбросана по куче разных мест. Описание api в google doc файле. Скудный функционал api, желания заказчика просто не реализовать без костылей. Тестовой среды нет. Все временами падает.
Не путайте комментарий с постом.
Для парсера без разницы — что внутри у тега script. Синтаксический анализатор построил токены, лексический прошелся по ним, и после обработки все, что внутри script, превращается в текстовую ноду. Да, для данного случая анализ сложнее, но сути это не меняет. То, что код внутри не валиден — не проблема парсера html. Уж логика у вас больно странная — автор может вырезать script, но не может вместо этого создать ноду с текстом.
Читайте не между строк. Писалось о простом парсере, который будет работать с минимумом проблем. Хотя, если пойти дальше, то все равно:
https://habr.com/ru/post/171667/
Льзя. Вы уж простите, но nikic'у я верю больше.
https://www.w3.org/TR/WD-html-lex/ Ну и у w3c получилось на lex, который использует регулярные выражения. А вы и дальше считайте, что нельзя.
Это смысловая ошибка, читатель не должен догадываться о том, что вы имели ввиду.
Да, читатель может не знать о анализаторах, но вы публикуетесь на техническом ресурсе, где соответствующая аудитория, и контент должен соответствовать. Аудитории будет понятнее и удобнее, если они будут встречать определенные, устойчевые, термины и методы, используемую литературу. Если содержания статьи им будет недостаточно, появиться желание углубиться — они будут знать о том, что им нужно искать.
Собственно, данный материал должен был использоваться и в этой статье.
Если бы вы описывали процесс, с информацией, указанной выше, то можно было бы еще поверить в две хорошие части, разделенные на: теоретическую и практическую, либо на: разбор и анализ. Что же вы хотите растянуть на три, описывая информацию вашей манерой — непонятно.
Вы не учли то, что я писал комментарий, а не статью. Да, для них будет отдельное правило.
Естественно — на одной регулярке, получится простая поделка и далеко не уедешь, но другого я и не утверждал. Боюсь, сейчас вы показали полное отсутствие компетентности в данной теме. В профильной литературе, и, например, в lex регулярные выражения используются повсеместно.
На первом же изображении: «Берем символ, если он равен '<' — считаем его тегом и обрабатываем». Считаем символ тегом? И таких ошибок — куча.
Информации мало.
Сама информация — низкого качества. Выдумываете бред.
С наскоку дам больше информации лучшего качества:
Html — имеет простую структуру, смотрим rfc1866.
Имеем два типа нод: TagNode и TextNode (не может иметь детей).
Скрипты и стили к парсингу отношения не имеют и рассматриваются как обычные теги, содержащие одну дочернюю TextNode.
Самый простой парсер можно написать на регулярках, и через рекурсию строить дерево.
Если есть желание написать что-либо более интересное — читаем «книгу Дракона», да, она о разработке компиляторов, но в ней полно информации по интересующей нас теме — синтаксическом и лексическом анализе. Определяем алфавит, лексемы. Пишем лексический анализатор (автомат), который все это обрабатывает, пропускаем исходный код и на выходе получаем список лексем. Дальше строим из лексем плоский массив из открывающих/закрывающих тегов, блоков текста. В конце проходим по этому массиву строим дерево и заодно выявляем ошибки — незакрытые теги, цепи и.т.д.
Можно еще возвращать объект — коллекцию, реализующую итератор, но без дженериков все это выглядит кривовато.