Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
HTML -> XML делается при помощи того же самого tidy. Главным преимуществом XML — возможное использование XSLT
использование Javascript / AJAX / асинхронных загрузок очень усложняют написание парсеров
Зачастую наоборот. В большинстве случаев, сервером отдается JSON/XML dataset, т.е. данные сразу готовы к обарботке без парсинга
Имелось ввиду, что часто данные не отображаются в виде HTML, а «зашиты» в Javascript или подгружаются асинхронно (например, при разбивке страниц). В таком случае, чтобы получить HTML, необходимо выполнять Javascript, а уже потом парсить данные. Если данные отдаются в json, xml — это совершенно другая ситуация, для которой существует огромное количество уже готовых библиотек.
А зачем нам HTML? Почему не натравить парсер на тот URI, с которого подгружаются данные и не полуить их в чистом виде?
Ну что значит зачем? Можно подумать, что абсолютно все необходимые данные лежат в свободном доступе в XML формате? Если бы все было так просто, парсеры вообще были бы не нужны.
Стоп. Данные откуда-то подгружаются.
Если их может подгрузить браузер, то их может подгрузить и робот. При этом, нам абсолютно не важно какой вид они приобретут после отработки JS на стороне клиента — нам достаточно отправить точно такой же запрос и обработать не страницу целиком, а только полученный кусочек.
И именно поэтому использование AJAX на сайте упрощает а не усложняет задачу, т.к. ответ на ajax запрос содержит намного меньше «мусора» или не содержит его вовсе.
Если их может подгрузить браузер, то их может подгрузить и робот. При этом, нам абсолютно не важно какой вид они приобретут после отработки JS на стороне клиента — нам достаточно отправить точно такой же запрос и обработать не страницу целиком, а только полученный кусочек.
И именно поэтому использование AJAX на сайте упрощает а не усложняет задачу, т.к. ответ на ajax запрос содержит намного меньше «мусора» или не содержит его вовсе.
Во-первых, вам необходимо найти тот ajax запрос, который нужно послать. Во-вторых, вам необходимо исполнять javascript, т.е. логика парсера усложняется.
А если все ссылки на странице асинхронные? Вам придется разбираться с тонной javascript — это, конечно, легче, чем перейти по ссылке и ее распарсить.
А если все ссылки на странице асинхронные? Вам придется разбираться с тонной javascript — это, конечно, легче, чем перейти по ссылке и ее распарсить.
Вы, судя по каментам, не понимаете, о чем вам пишут.
1. Нужный URL прекрасно находится в том же firebug'e. Это даже проще, чем ковыряться в исходнике странички.
2. При этом не нужно разбирать и выполнять JS. Совсем не нужно.
В итоге, что нам остается? Получить нужные данные по прямому URL и заняться их разбором, а не разбирать всю страницу целиком. Профит? Однозначно!
1. Нужный URL прекрасно находится в том же firebug'e. Это даже проще, чем ковыряться в исходнике странички.
2. При этом не нужно разбирать и выполнять JS. Совсем не нужно.
В итоге, что нам остается? Получить нужные данные по прямому URL и заняться их разбором, а не разбирать всю страницу целиком. Профит? Однозначно!
Если бы я не понимал, о чем здесь пишут, то этой статьи вообще не было бы.
Нужный url часто бывает вида javascript:__doPostBack('ctl00$ContentPlaceHolder1$GridView1$ctl10$DeleteLinkButton',''), где вы тут видите url, который можно распарсить? Вместо этого нужно выполнить этот javascript, получить новый HTML, после чего можно продолжать парсить. Это не легче, чем распарсить _еще одну страницу_ по шаблону.
Нужный url часто бывает вида javascript:__doPostBack('ctl00$ContentPlaceHolder1$GridView1$ctl10$DeleteLinkButton',''), где вы тут видите url, который можно распарсить? Вместо этого нужно выполнить этот javascript, получить новый HTML, после чего можно продолжать парсить. Это не легче, чем распарсить _еще одну страницу_ по шаблону.
Use FIREBUG, Luke!
Не все используют файрбаг и не знают где смотреть.
Если речь идет об автоматизированном сборе информации (натравливаете робота на корень сайта и парсите все что есть и не один раз), то даже файрбаг вам не поможет. Другое дело анализировать URL, а потом писать робота-сборщика. Частенько разработчики сайтов делают хитрые URL и защиту, анализируют user_agent чтобы не скачивали. Да и при изменении верстки, все система ляжет на раз, из-за одного тэга. Тут нужен комплексный подход, к каждому сайту свой…
Если речь идет об автоматизированном сборе информации (натравливаете робота на корень сайта и парсите все что есть и не один раз), то даже файрбаг вам не поможет. Другое дело анализировать URL, а потом писать робота-сборщика. Частенько разработчики сайтов делают хитрые URL и защиту, анализируют user_agent чтобы не скачивали. Да и при изменении верстки, все система ляжет на раз, из-за одного тэга. Тут нужен комплексный подход, к каждому сайту свой…
*анализировать URL — имелось ввиду выяснить какие вызовы идут асинхронно, через ajax
Вам правильно говорят — у любого браузера есть инструмент, с помощью которого можно отследить посылаемые запросы. Тот же Fiddler, на пример.
Не нужно анализировать url на странице — нажимаете кнопку на сайте и смотрите какой запрос посылается на сервер.
Не нужно анализировать url на странице — нажимаете кнопку на сайте и смотрите какой запрос посылается на сервер.
Использую и fiddler и firefox. Знаю как это посмотреть. Попробуйте распарсить и построить такую же структуру данных как на yell.ru/. Знать что и откуда качать, решает увы не всю проблему.
А в чем собственно проблема? Сайт парситься на ура. он же сео-френдли — в нем по определению нет проблем с доступом к информации.
Для примера вот дерево рубрик c yell.ru
http://pastebin.com/BmVXNeiC
Время написания скрипта — минут 8 с просмотром исходника сайта, регулярок нет, dom, xpath не используется.
Размер скрипта 50 строк, 40 из которых сохраняют атрибуты для xml вывода, можно и меньше — но бессмысленно.
Время работы скрипта — 27054ms = 27 секунд.
Итого — 2157 рубрик (учитывая промежуточные разделы)
Так в чем проблема? Посмотрел остальные страницы с информацией по компаниям — абсолютно не вижу проблем при наличии правильных рук.
Для примера вот дерево рубрик c yell.ru
http://pastebin.com/BmVXNeiC
Время написания скрипта — минут 8 с просмотром исходника сайта, регулярок нет, dom, xpath не используется.
Размер скрипта 50 строк, 40 из которых сохраняют атрибуты для xml вывода, можно и меньше — но бессмысленно.
Время работы скрипта — 27054ms = 27 секунд.
Итого — 2157 рубрик (учитывая промежуточные разделы)
Так в чем проблема? Посмотрел остальные страницы с информацией по компаниям — абсолютно не вижу проблем при наличии правильных рук.
Предупреждая замечания, да — там есть еще некоторые скрытые подрубрики — которые также можно было бы распарсить, но не было желания проверять на себе наличие ограничений по скорости доступа, и прокси подключать к этому тоже бессмысленно — скрипт накидал просто так — потому как спарсить можно всё и при чем вполне себе простенько ;)
+1. Я про это и говорил… Невыполнимого ничего нет, но наличие одного FireBugа проблемы не решает… ))
на чем Вы написали? Как я понимаю, топикстартер программист ASP.Net
Я написал на Java, но библиотеки которые использовал (по сути одну махонькую) — можно портировать на любой язык, ибо она очень лаконичная. для своих проектов делал портации под Php, Javascript, Actionscript
в данном случае — я могу запустить где угодно граббер, а вот писать парсеры-грабберы на дот.нете — вполне себе достаточное невежество) я скорее буду писать граббер на пыхе, нежели на дотнете — и более того, по скорости выиграю — ибо ресурсов у меня будет несравненно больше и дешевле)
в данном случае — я могу запустить где угодно граббер, а вот писать парсеры-грабберы на дот.нете — вполне себе достаточное невежество) я скорее буду писать граббер на пыхе, нежели на дотнете — и более того, по скорости выиграю — ибо ресурсов у меня будет несравненно больше и дешевле)
Позвольте не согласиться с Вами )) имхо можно писать на чем угодно. Например консольное приложение на C#.
По скорости — не согласен, а вот по прожорливости — да, наверно Вы правы. Не хочу холиварить )), .Net тоже не плох, в свое время успешно парсил некоторые сайты на нем. Было привычнее, так сказать рука набита.
Другое дело — использование таких грабберов на разных платформах, да несомненно на Java или даже PHP использовать оптимальнее.
По скорости — не согласен, а вот по прожорливости — да, наверно Вы правы. Не хочу холиварить )), .Net тоже не плох, в свое время успешно парсил некоторые сайты на нем. Было привычнее, так сказать рука набита.
Другое дело — использование таких грабберов на разных платформах, да несомненно на Java или даже PHP использовать оптимальнее.
>> а вот писать парсеры-грабберы на дот.нете — вполне себе достаточное невежество
После этой фразы говорить с вами нет смысла.
После этой фразы говорить с вами нет смысла.
Когда потребуется увеличить скорость выдачи результата, то почему-то .net становится узким местом в обработке данных… и считанные мегабайты в секунду на простых регулярках становятся непроходимым лимитом. Как ни странно, но практически одна и та же логика ощутимо быстрее работает на php (возможно на perl будет чуть чуть быстрее, но сложнее писать, а уж на c++ как можно с оптимизировать) чем даже на python, а уж .net с java плетутся совсем позади, так как выигрывают они зачастую от/при (я больше про java) наличием готовых оптимизированных решений.
По поводу явы вы как-то уж совсем не правы, скорость работы явы по определению в десяток раз выше чем у пыха, питона и т.д.
При правильном подходе ява по скорости не уступает си++, а по скорости разработки превосходит.
Обработка 300мб за ~20 секунд с не самой простой выборке нужной информации — пожалуй говорит о достаточном быстродействии, ни пых, ни перл, ни питон, ни любой другой скриптовый язык — рядом не стоят.
При правильном подходе ява по скорости не уступает си++, а по скорости разработки превосходит.
Обработка 300мб за ~20 секунд с не самой простой выборке нужной информации — пожалуй говорит о достаточном быстродействии, ни пых, ни перл, ни питон, ни любой другой скриптовый язык — рядом не стоят.
Пожалуй с вами не о чем говорить, вы видимо не заметили — я не против языка, мне все равно что зы язык используется — я говорил о платформе языка. если ваш язык не работает на никсах — вы никогда не то что не догоните — даже близко не приблизитесь по скорости получения и обработке информации, а также кол-ву обрабатываемых данных.
Невежество? Интересно… у меня все на .Net, и работает ведь :)
Я все время использую анализ DOM дерева, благо для PERL есть волшебный модуль из CPAN. HTML::TreeBuilder. Так же к нему есть дополнение реализующее поддержку XPath
полагаю не всё так однозначно.
Если взять сроку — то да, а если нужно взять таблицы разных структур и вложенности — могут возникнуть затруднения.
Если взять сроку — то да, а если нужно взять таблицы разных структур и вложенности — могут возникнуть затруднения.
Поддерживаю. Очень часто использую регулярки, намного быстрее идёт разработка и меньше проблем чем с остальными подходами. И меньше зависит от структуры исходного документа.
А в чем задача? Извлечь основное содержимое (без мусора в видел меню, copyrights и прочего)?
Если это, то просто ищутся куски HTML с наименьшим количеством тэгов
Если это, то просто ищутся куски HTML с наименьшим количеством тэгов
Как-то раз использовал PHPQuery (не знаю, что внутри, а снаружи — использование селекторов jQuery). Сработало. )
В .Net обычно работаю с XPath как раз.
В .Net обычно работаю с XPath как раз.
Как это не странно, но основные усилия при разработке Web Mining приложений уходят не на анализ данных а на 'исполнительную обертку' вокруг парсеров — отслеживание и корректное реагирование на ошибки (смена дизайна, проблемы с интернетом или с сайтами..), сокрытие робота от владельцев (в т.ч. борьба с теми кто борется против роботов — паузы, имитация браузеров, каптчи), много потоковая работа (загрузка с 1 сайта происходит значительно медленнее канала на сервере) и подстановка разных интерфейсов (IP адрес загрузчика), сбор статистики и оптимизация параметров работы (очень большой и важный раздел при написании веб-сканеров) и банальные проблемы с имеющимися БД (медленные они) — прикручивание различных key-value БД, memory-БД и т.п.
Почему бы не помянуть сервисы, которые делают всю работу за нас — приводят документ к валидному виду, парсят, дают возможность далее использовать простые запросы для возвращения данных, например YQL — Yahoo Query Language
Не нашел в статье про два важных аспекта извлечения данных: устойчивость к изменениям html-исходников и использование похожести однотипных страниц (например все страницы данного сайта про ноутбуки). Про них планируется написать позже? :)
Пожалуй, из самых прикольных для PERL это модуль Web::Scraper. Но, опять же, из-за xpath не все данные в невалидном HTML можно адресовать, хотя модуль не вываливается. С css-селекторами иногда еще проще получаются выражения.
Немного примеров www.sql.ru/forum/actualthread.aspx?tid=773396.
И там есть отсылки к какому-то аналогу на ruby. Что там у них популярно?
Немного примеров www.sql.ru/forum/actualthread.aspx?tid=773396.
И там есть отсылки к какому-то аналогу на ruby. Что там у них популярно?
Не хочу показаться занудой, но при чем тут Data Mining (интеллектуальный анализ данных)?
Да и к Web Mining (или статья на хабре) описанное в данной статье имеет весьма отдаленное отношение.
А все описанное — это очень даже Web Scraping, которое, скорее, в «Алгоритмы».
Да и к Web Mining (или статья на хабре) описанное в данной статье имеет весьма отдаленное отношение.
А все описанное — это очень даже Web Scraping, которое, скорее, в «Алгоритмы».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подходы к извлечению данных из веб-ресурсов