Я считаю, что диалог с читателем должнен быть. В конце концов, читатели разные, с разным уровнем квалификации. Я считаю, что стоит придерживаться грани, в меру шутить и быть серьезным.
Лексический анализатор строит токены, а не синтаксический. Я вполне могу создать текстовую ноду, только смысла в этом нет. В том же simple dom все script и style вырезаются регулярками.
Боюсь, сейчас вы показали полное отсутствие компетентности в данной теме. В профильной литературе, и, например, в lex регулярные выражения используются повсеместно.
Нет, я показал отсутствие компетентности в регулярных выражениях, но никак не в синтаксическом анализе. В конце концов, если бы то, что вы сказали выше — правда, думаю моя статья вообще бы не вышла на хабре. К тому же, я не говорю, что использовать регулярные выражения вообще в синтаксических анализаторах это сразу плохо. Вовсе нет. Просто в данной задаче это не нужно, так как она достаточно простая и использовать регулярные выражения нет смысла.
Ого, спасибо за пояснение! Я сначала думал, что у меня мало знаний, поэтому я не смогу написать парсер на регулярках. А оказывается его написать и нельзя. Касательно script вы правы. В конце концов, в script могут быть разные выражения с использованием "<" и других символов, и нельзя допустить, чтобы такой код обрабатывался как обычные теги. Все это предусмотрено.
Неплохая идея, только тут стоит подумать о той же производительности. Ведь если я решу добавить подобный функционал, мне придется писать еще один синтаксический анализатор только для поиска. При этом получится, что этот синтаксический анализатор будет даже больше, чем анализатор html, ведь в XPath есть уже функции, операторы и др.
Касательно того, что я пишу бред. Это небольшая ошибка, я имел ввиду то, что парсер меняем состояние и начинает дальнейшую цепочку символов обрабатывать как тег. Прошу прощения, хотя с другой стороны, тем кто вообще не знаком с синтаксическими анализаторами, как мне кажется, будет более понятен мой вариант объяснения. Также я читал книгу по трансляторам, более того, некоторый материал будет использоваться в дальнейших частях цикла. Например про те же состояния и теорию конечных автоматов. Частей будет еще где-то две. Касательно нод. Вы не учли ноду комментариев, а ведь они тоже будут в документе, и их тоже нужно будет обрабатывать. Также хочу отметить, что вариант написания парсера на регулярках — плохая идея. Такой парсер будет работать примерно так же, как simple dom.
Вообще это очень размытая цифра. В конце концов, парсеру же еще нужно загрузить страницу, так что тут больше скорость загрузки зависит от интернета. Если брать текст из уже скачанной страницы, то он обрабатывает текст с все того же сайта за 250мс
Я не особо разбирался в этой теме, поэтому нет. Более того, мне это не нужно. Функционала моего парсера мне хватает, как и скорости. Я буду писать об этом дальше, но сейчас могу сказать, что мой парсер ищет текст с сайта new your times примерно за 1.5 секунды
Это вводная часть, она и не должна быть большой. Если бы я тут подробнее углубился бы в детали, тогда моя статья была бы не меньше той, ссылку на которую вы оставили. А это только теоритический материал, без кода. С помощью этой статьи я хотел заинтересовать читателя темой, а не полностью охватить эту тему.
Данная ошибка не пропущена. В этом случаи ошибка относится к ошибке, когда нету закрывающего тега, а открывающий есть. Касательно одиночных тегов — эта функция предусмотрена парсером, у меня есть список одиночных тегов, если тег совпадает с одиночным, он записывается в дом. Касательно краткого закрытия тега — тоже предусмотрено
Я считаю, что диалог с читателем должнен быть. В конце концов, читатели разные, с разным уровнем квалификации. Я считаю, что стоит придерживаться грани, в меру шутить и быть серьезным.
Нет, я показал отсутствие компетентности в регулярных выражениях, но никак не в синтаксическом анализе. В конце концов, если бы то, что вы сказали выше — правда, думаю моя статья вообще бы не вышла на хабре. К тому же, я не говорю, что использовать регулярные выражения вообще в синтаксических анализаторах это сразу плохо. Вовсе нет. Просто в данной задаче это не нужно, так как она достаточно простая и использовать регулярные выражения нет смысла.
Справедливо, спасибо за критику.
Спасибо за поддержку. Забрасывать не намерен, тема мне кажется интересной, поэтому хочу ее развивать.
Данная ошибка не пропущена. В этом случаи ошибка относится к ошибке, когда нету закрывающего тега, а открывающий есть. Касательно одиночных тегов — эта функция предусмотрена парсером, у меня есть список одиночных тегов, если тег совпадает с одиночным, он записывается в дом. Касательно краткого закрытия тега — тоже предусмотрено