Pull to refresh

Comments 36

Тогда уж ScrapingHub (https://scrapinghub.com)

Но ведь на главной странице со списком справа вверху есть "Экспорт реестра", где, в т.ч. можно скачать уже готовый CSV со списком и всей доступной информацией по набору

Можно. Но ещё вчера там были данные за ноябрь 2016, а xls вообще был пустой

Прошло десять лет, и придумали ещё несколько умных слов, чтобы обозвать то, чем я занимался))
Напомнило «редизайн для хипстеров»
как редизайнить упаковки что бы покупали хипстеры
image и т.д.

Есть статья про граббинг, по уровню с трудом дотягивающая даже до гиктаймз, время которой давно ушло еще где-то в 90-тых.
Граббинг переименовываем в веб-скраппинг.
Вместо банального пхп/питона используем с#
Вместо быстрого получения контента по хттп, используем тормозную эмуляцию браузера.
Вместо быстрого доступа к хтмл для начала генерируем х-пути тормозными либами, а потом уже извлекаем нужные данные.
И главное — ни в коем случае не берем готовый CSV с разложенными по полочкам данными.
И вот — уже модная современная статья для хабра готова.
Прикол в том, что you don't need parse [x]html to get desired data
Web scaping — термин используемый в Data Science Courses курса Getting and Cleaning Data Johns Hopkins University.
Использование c# — нормальная практика, если остальные части проекта на c#.
Простите, с чего вы решили, что эмуляция «тормозная»? Здесь проблема в скорости ответа сервера.
Если Вы внимательно читали, то могли обратить внимание, что пути генерируются просто добавлением номера страницы к известному адресу http.
И конечно готовый cvs файл с данными, ориентировочно за ноябрь 2016 (10797 записей, а на портале 12708) меня не устраивает.
1,2) И что это меняет?
3) В конкретной ситуации — может быть узкое горлышко и не тут, однако в подавляющем большинстве случаев эмуляция избыточна.
4) И?

Речь о том, что если взять статью какого-нибудь 9х года на тему граббинга, то она ничем от этой статьи отличаться не будет, кроме замены старого термина «граббинг» на модный «вебскапинг», использованием другого языка (при чем без каких-либо его ценных особенностей, т.е. опять же просто замена) и набором ненужных наворотов (эмуляции браузера, разбора хтмл на х-пути) потому что это «современно».
Ведь разве в статье упомянуты какие-то вещи отличающие веб-скапинг от граббинга? Нет. Эмуляция браузера зачем-то нужна? Нет. Какие-то особенности С# нужные для решения этой задачи есть? Нет. Разбор хтмл на х-пути вместо обычных регов служит какой-то цели? Нет.

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

Что бы быть конструктивными, ответим на незаданный вопрос — в каком виде эта статья могла бы быть интересна.
Эмуляция браузера была бы интересна, если бы сайт был защищен от тупого граббинга и этой эмуляция была бы необходимой и достаточной, при чем с объяснением почему необходима и почему достаточна. В чем и есть суть и применение эмуляции браузера и отличие оной от банального хттп запроса.
Разбор на х-пути был бы интересен, если бы там был поистинне сложный и/или генерящийся на js хтмл код, который невозможно было бы втупую разобрать регами. В чем и есть суть и применение х-путей и их отличия от регов.
Веб-скапинг вместо граббинга был бы уместен, если бы извлекаемая структура данных собиралась бы из разных источников, отчасти структурированных отчасти грязных и имела бы результатом стройную базу данных. В чем и есть суть веб-скапинга и его отличия от граббинга.
C# был бы интересен, опять же, если бы там была какая-нибудь уникальная либа помогающая решать какую-то конкретную проблему.
Ну и так далее. Куча современных и модных наворотов, но бессмысленных в применении к конкретной задаче. (тут должна быть картинка с троллейбусом)

Спасибо за конструктивную критику.
Не вижу смысла спорить по поводу терминологии.
Я понимаю, что Вы профессионал в данном вопросе с большим опытом (я действительно так считаю, без каких либо задних мыслей).
Но предлагаю посмотреть на все немного под другим углом: мне нужны данные, но API и готовый файл мне не подходят. Задача для меня не совсем профильная. В данном случае я занимаюсь анализом данных. В статье я пытаюсь показать простой и наименее затратный путь, максимально используя готовые решения, который помогает решить мою конкретную проблему. И при этом встроить решение в общий проект.

Поддерживаю пользователя edogs. У меня 1-в-1 комментарии по статье возникли. Видимо, это ваш первый парсер, но задача решена, а это главное. В будущем рассмотрите для аналогичных целей PHP/Python с использованием regex (регулярный выражений). Самому недавно пришлось на работе переписывать на C# парсер финансовой аналитики, который я писал неделей ранее на PHP. Переписал на C# с HttpRequest и Regex, но ощущение было, будто из пушки по воробьям стреляю. За ссылку на ScrapySharp спасибо, кстати.
Можно сказать, что первый. И неизвестно когда понадобится еще. Статья — способ капитализации знаний. Комментарии — возможность получить совет профессионального сообщества.
В целом, согласен.

Вместо быстрого получения контента по хттп, используем тормозную эмуляцию браузера.


для простых сайтов — да, а что делать с динамикой? по хттп вы получите index.html для любого роута и всё.
Динамика с Вашей точки зрения не по хттп ходит?
Я про динамический контент. Динамика ходит, только тот же JS исполнять Вы на чем будете? Просто html, понятно, можно и регулярочкой распарсить или в dom-парсер засунуть( и как белый человек, юзать jquery).
А так, phantomjs и прочие браузерные движки без самого браузера — наше всё.
А так, phantomjs и прочие браузерные движки без самого браузера — наше всё.
Гуглу это расскажите:)
Во-первых, на грамотном сайте будет версия работающая без js, более того, нормальный аяксовый сайт будет адресную строку подменять на актуальную даже работая полностью по аякс.
Во-вторых, браузерные движки на js что делают по правильному? Берут чистые данные по хттп аякс запросом и распихивают их по хтмл слоям, т.е. сэмулировав тот же аякс запрос по хттп граббер получит чистые данные (а не неоднозначный хтмл с кучей мусора). Чуть больше времени на анализ аяксовых хттп запросов в итоге окупается более простым разбором данных.

Безусловно, Вы правы в том, что на некоторых динамических сайтах эмуляция браузера будет нужна, но наличие на сайте динамики автоматически само по себе не требует эмуляции. Напротив, скорее это редкий вариант ввиду двух вышеупомянутых вещей.
Что то мне подсказывает что своих парсеров вы не делали.
Выкиньте это что-то:) У нас больше трети проектов были связаны так или иначе с парсингом или граббингом.
Если контент генерируется при помощи JS работа с браузером имеет смысл.
Насколько вижу, у них API есть:

http://data.gov.ru/pravila-i-rekomendacii
http://data.gov.ru/api-portala-otkrytyh-dannyh-rf-polnoe-rukovodstvo
Да. API есть. Если бы он стабильно работал, то был бы замечательным.
Веб-скрапер? Да это же обыкновенный парсер! :-)
UFO just landed and posted this here
Микроскопом гвозди)))
Сколько людей — столько мнений.
Микроскоп большой удобно в руке лежит — одно удовольствие гвозди забивать (и при этом микроскопы под ногами валяются, а за молотком еще идти надо).
Конкретно здесь важен результат — за пару часов инструмент, позволяющий переодически мониторить изменения и извлекать данные (при этом легко интегрируясь с остальными частями).
Сколько бы заняло времени: поиск программиста, согласование требований, ожидание выполнения работ, приемка? Какова вероятность не «попасть на поддержку»?
Оценивая риски и выбирая вариант купить или сделать самому, я выбрал второй.
И никаких трудностей не испытал. Скорее это оказалось намного легче, можно было предположить.
Я честно напмсал, что вариантов может быть много.
Если Вы знаете как сделать быстрее и лучше — кидайте ссылки.
За это Вам только спасибо скажут
Извините, но какой поиск программиста? Какое согласование требований?
Я очень рад, что Вы справились с этим упражнением. Я иногда пишу парсеры, просто когда мне лень копировать какую-нибудь ужасно свёрстанную информацию со страницы. Но зачем тащить это на хабр? Как инструкцию для новичков? ИМХО, тогда нужна какая-то универсальная, без упоминаний шарпа и хрома.
Можно изобретать велосипеды, а можно взять A-Parser и получить из коробки многопоточность, работу с regex и XPath, сложные парсеры можно целиком писать на JavaScript(ES6)
Спасибо за информацию.
А его можно взять?
По ссылке предлагают его купить.
Однозначно придется покупать :)
не всем сайтам нравиться что у них перелопачивают все страницы подряд, и они выдают капчу…
Спасибо за статью, для меня было очень познавательно.
Возможно вы встречали, сесть ли какое либо ПО / скрипты на питоне, для выборочного копирования статей с одной вики в другую? Pywikibot насколько я понял предназначен только для модификации конкретной вики.
Мир не стоит на месте, домохозяйки обзавелись смартфонами, скрапбукинг уступил место веб-скрапингу
Точно так. А еще домохозяйки на своих смартфонах используют нейронные сети для обработки фотографий…
Как говорилось в одном очень известном кейсе на StackOverflow:

You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. <...>
ну не скажите, регулярками парсить легко, да и работают они в разы быстрее, чем парсинг всей страницы построение DOM
Sign up to leave a comment.

Articles