Написание HTML Parser

В настоящее время я пытаюсь (или планирую попытку) написать простую (по возможности) программу для синтаксического анализа html-документа в дерево.

После googling я нашел много ответов, в которых говорилось: "Не делайте этого, это было сделано" (или слова на этот счет); и ссылки на примеры парсеров HTML; а также довольно решительная статья о том, почему нельзя использовать регулярные выражения. Однако я не нашел руководства по правильному написанию парсера. (Это, кстати, то, что я пытаюсь сделать больше, чем учащееся, чем что-либо, поэтому я бы очень хотел это сделать, а не использовать готовый)

Я считаю, что могу создать рабочий синтаксический анализатор XML, просто прочитав документ и добавив теги/текст и т.д. к дереву, повысив уровень, когда я нажимаю тег close (опять же, просто, без надобности или эффективности на данном этапе.). Однако для HTML не все теги закрыты.

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

Есть ли у кого-нибудь другие (надеюсь, лучшие) предложения? Есть ли лучший способ сделать это вообще?

Ответ 1

Итак, я попробую ответить здесь -

в основном, что делает "простой" анализ html (не говоря уже о действительном xhtml здесь), отличном от синтаксического анализа xml, - это множество правил, таких как бесконечные теги <img>, или, строго говоря, тот факт, что даже самый небрежный из всех html-разметки будут несколько отображаться в браузере. Вам понадобится валидатор вместе с парсером, чтобы построить ваше дерево. Но вам нужно будет принять решение о стандарте для HTML, который вы хотите поддержать, так что, когда вы столкнетесь с слабостью разметки, вы узнаете об этом ошибку, а не только неаккуратный html.

знать все правила, создавать валидатор, а затем вы сможете создать парсер. что план А.

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

надеюсь, что это помогло!

Ответ 2

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

Вы сохраните стек (возможно, неявно с деревом) текущего контекста. Например, { <html>, <body>} означает, что вы сейчас находитесь в теле документа html. Когда вы сталкиваетесь с новым node, вы сравниваете требования для этого node к тому, что в настоящее время находится в стеке.

Предположим, что ваш стек в настоящий момент просто { html}. Вы встречаете тег . Вы смотрите  в таблице, в которой говорится, что абзац должен находиться внутри <body>. Поскольку вы не находитесь в теле, вы неявно нажимаете <body> на свой стек (или добавляете тело node к вашему дереву). Затем вы можете поместить  в дерево.

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

В конце вашего документа вы выталкиваете каждый оставшийся элемент из вашего стека, как если бы вы видели тег close для каждого из них.

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

Ответ 3

Поскольку теперь существует стандарт html5, запись анализатора html больше не является пробной и ошибочной информацией.

Вместо этого вам просто нужно реализовать стандартизованный алгоритм синтаксического анализа.

Ответ 4

Резкий. Перейти

HTML не XML. XHTML - это XML. Большинство сайтов - это HTML; некоторые из них - XHTML. В XHTML все теги должны быть закрыты (или не имеют тела, которое все еще закрыто).

Если вы хотите написать парсер HTML как учебный эксперимент, тогда идите. Если вы хотите написать следующий "Самый большой парсератор HTML", то отпустите его. Побеждает Апач (или кто-то другой); важная информация: вы не знаете больше, чем большие группы, которые специализируются на анализе HTML.

Чтобы ответить на вопрос "Как мне с этим справиться?" Прочитайте спецификацию W3C на HTML. Это отвечает на ваш вопрос. Если ваш ответ "но я тоже не хочу", вы на самом деле говорите: "Я ленивый goofrocket, который хочет притворяться, что учиться". Если это так, я предлагаю вам удалить сообщение и перейти дальше; У команды Microsoft IE probabaly есть некоторые документы, которые вас будут интересовать.

Менее суровый ответ

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

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

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

Ответ 5

Вы пытались использовать эту библиотеку: http://simplehtmldom.sourceforge.net/?