Как стать автором
Обновить

Комментарии 36

Как обстоят дела с распознаванием страниц с табличной версткой? Ведь таблицы могут быть как структурой страницы, так и контентом.
хуже чем с div. Текст таблицы (контент) которая уже в таблице (структура страницы) будет распознан как отдельные элементы. Если окружающего таблицу тескта будет много, то более или менее
… текст в элементах в блоке Фрилансим (он у нас уже получили минус за повторяющийся класс), получают минус в догонку за некрасивое соотношение ссылок к тексту равное единице. Понятно, что чем меньше этот коэффициент, тем больше текст похож на осмысленную статью
Каков коэффициент случайной статьи Mithgol'a?
демку нашей реализации мы выложим позже, но вот что дает например одна известная реализация:
http://boilerpipe-web.appspot.com
они нашли самый большой коммент )

Спасибо, примерно такого результата и следовало ожидать )))
у них не все из того что описано в статье используется
Я могу ошибаться, но насколько я знаю, предпросмотр в ВК доступен только тем сообществам, которые подали заявку на сотрудничество. Обработка ручная, значит и парсер можно подстроить, если он сам не справится :)
да, там даже учитывается тэг habracut. Но это неспортивно )
есть интересный проект для этой задачи code.google.com/p/boilerpipe/
и там же демка для примера со спаршенной статьей приведенной в качестве примера boilerpipe-web.appspot.com/extract?url=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F198982%2F&extractor=ArticleExtractor&output=htmlFragment&extractImages=
да да, ссылка на его paper есть в сорцах. Дело в том не смотря на то что написано все с кучей формул, они ведут к одному заключению:
We have shown that textual content on the Web can ap- parently be grouped into two classes, long text (most likely the actual content) and short text (most likely navigational boilerplate text) respectively. Through our systematical anal- ysis we found that removing the words from the short text class alone already is a good strategy for cleaning boiler- plate and that using a combination of multiple shallow text features achieves an almost perfect accuracy. To a large ex- tent the detection of boilerplate text does not require any inter-document knowledge (frequency of text blocks, com- mon page layout etc.) nor any training at token level.
Сразу скажу, что это «белый» парсинг, вебмастеры сами добровольно пользуются нашим сервисом.

Лишь белые сеошники, наверное, зеленеют от злости (не все, а чьи труды парсят).
не очень понятно ) у нас для задач поиска используется
Доиграются — рекламу будут прям в текст совать :\
ненавязчивое упоминание в статье )
Почему-то считал, что один из основных методов автоматического нахождения статей — длина блока или его размер/положение на странице.
Скажите, такой метод применяется?

Вообще авторам спасибо огромное. Действительно полезная статья.
да, вы правы. В статье я как раз и написал что длина блока сработает в 90% случаев
ха, не знал, и эта штука гораздо лучше распарсила «неудобную» статью habrahabr.ru/post/194852/
Коль автор настолько глубоко погрузился в тему, не подскажите ли алгоритм для парсинга подписи в емейлах?
посмотреть 2 письма от одного человека и сравнить их нижнюю часть?
Есть стандартное соглашение, котрого в основном придерживаются — подпись идет вот такого: " --" с новой строки — то есть после строки, состоящей из пробела и двух дефисов.
Можно просто искать div с наибольшим количеством p. Часто это работает. Если нет, тогда переходить к более изощренным алгоритмам.

Ваша статья очень полезная. Как раз сейчас этим занимаюсь и почерпнул несколько здравых идей. Удивительно, как сам не додумался.
да, как вариант. Это можно сочетать с подсчетом точек(предложений)
На некоторых сайтах бывают довольно большие блоки внутри статьи. То есть статья делиться на два-три больших, но не равномерных куска, а между ними рекламные баннеры, ссылки на другие статьи и еще куча всего (движки стараются напихать кучу html, который не очень нужен). Ваш алгоритм как-то это учитывает? Мне из текста показалось, что ищет один длинный кусок с предложениями и выбирает только его.
Ну все равно сама статья находится обычно в одном div, а вложенные баннеры — во вложенном div. Мы разбиваем DOM по div элементам и берем только текст с текущего уровня, вложенный div отбрасывается и обрабатывается в свою очередь как отдельный элемент.
То есть все эти баннеры и блоки со ссылками будут отброшены
А вы не учитываете, что перед текстом статьи обычно идёт заголовок с большими буквами, а комментарии, например, расположены обычно под текстом статьи? А заголовок можно определить по схожести с title.
нет, это уже оформление. Его полезно учитывать, но все очень усложняется
Совсем недавно нелал парсер новостной ленты, ориентируясь на классы блоков. Хорошо работал только с lenta.ru, как я ни старался подобрать условия для gazeta.ru и ещё пары сайтов — парсер валился, и или не ловил совсем ничего — или выдавал чуть ли не весь текст со страницы (кроме тегов, их то он вырезал железно).

Нужно или регулярки писать по-серьезнее, либо мечтать о более валидных новостных лентах.
а в чем там возникла проблема? У газеты вон вообще <article> используется, молодцы
Любопытно. Почти полностью повторили мой путь когда много лет назад я делал feedex.net (на храбре об этом тоже писал). Сейчас там несколько захардкоженных эвристик, вроде описанных вами. Думаю как поимею избыток свободного времени (например, на пенсии :) — переделаю все так чтобы эвристики программа находила самостоятельно, так куда удобнее будет.
круто, правда RSS счаз стал нишевой штукой, но я думаю алгоритм не пропадет. А на чем писали если не секрет (язык)?
Нашел свой анонс пятилетней давности — habrahabr.ru/post/42877/
Там есть ответы на некоторые вопросы. А язык — python, я как раз тогда его только начал всерьез осваивать, вот и подыскал на чем практиковаться.
у вас есть преимущество, вы знаете где текст начала статьи (из rss), пол дела сделано )
Конкретно этим преимуществом я не пользуюсь. А вот чем пользуюсь, так это тем что у меня практически всегда есть список ссылок на разные статьи одного ресурса.
Несколько месяцев назад для подобной цели пытался написать на Python кастомизируемый конвертер html to markdown: html2md

Смысл в том чтобы можно было получить текстовую версию html страницы в формате markdown а затем уже отрендерить её в нужном стиле. В идеале конвертер должен позволять простым перекрытием метода либо таблиц матчинга подстроиться под вёрстку конкретного сайта.

Пока работа застряла, если есть желающие присоединиться — велкам!
А не подскажите насколько ваше решение ресурсоемко и как быстро получается результат для страницы? Еще интересно на чем писали?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий