расчет охвата скрап-веб-паука

Я пишу веб-пауков для удаления некоторых продуктов с веб-сайтов, используя структуру scrapy в python. Мне было интересно, как лучше всего рассчитать покрытие и недостающие элементы написанных пауков.

То, что я использую прямо сейчас, — это регистрация случаев, которые не удалось проанализировать или вызвать исключения. В качестве примера: когда я ожидаю определенного формата для цены продукта или адреса места и обнаруживаю, что мои написанные регулярные выражения не соответствуют вырезанным строкам. или когда мои селекторы xpath для конкретных данных ничего не возвращают.

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


python web-scraping scrapy scrapy-spider
person Hady Elsahar    schedule 14.11.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Общий подход — да, использовать logging для регистрации ошибки. и выйти из обратного вызова, ничего не возвращая.

Пример (необходима цена товара):

loader = ProductLoader(ProductItem(), response=response)
loader.add_xpath('price', '//span[@class="price"]/text()')
if not loader.get_output_value('price'):
    log.msg("Error fetching product price", level=log.ERROR)
    return

Вы также можете использовать сигналы, чтобы перехватывать и регистрировать все возникающие исключения. во время сканирования см.:

Это в основном следует принципу Легче попросить прощения, чем разрешения, когда вы позвольте пауку потерпеть неудачу, поймать и обработать ошибку в одном конкретном месте — обработчике сигнала.

Другие мысли:

  • вы даже можете поместить URL-адреса ответов и трассировку ошибок в базу данных для последующего просмотра — это все еще «логирование», но в структурированном виде, который может быть более удобным для просмотра позже.
  • хорошей идеей может быть создание настраиваемых исключений для представления различных ошибок сканирования, например: MissingRequiredFieldError, InvalidFieldFormatError, которые вы можете вызвать, если поля для обхода не прошли проверку.
person alecxe    schedule 14.11.2014
comment
лично я больше предпочитаю стиль EAFP, так что этот ответ является облегчением, но означает ли это, что если я выкину 20 деталей с 1 веб-страницы, моя функция синтаксического анализа будет заполнена 20 предложениями try и exclude? - person Hady Elsahar; 14.11.2014
comment
@HadyElsahar Нет, если у вас есть обработчик сигналов spider_error, все исключения, возникающие при сканировании, будут доступны в обработчике. Вызов пользовательских исключений должен упростить анализ и обработку ошибок. - person alecxe; 14.11.2014
comment
да, но я предпочитаю обрабатывать каждую деталь только в предложениях try catch, чтобы паук завершил очистку остальных деталей, если ему не удалось получить [необязательный элемент]. , кроме того, для выделенных сообщений журнала о пропущенных случаях, какая часть на самом деле не удалась (например, получение текста цены или его разбор) - person Hady Elsahar; 15.11.2014
comment
Учитывая это, выглядит ли уродливо много попыток, кроме предложений с сообщениями журнала по всему коду? или это распространено в EAFP? - person Hady Elsahar; 15.11.2014
comment
@HadyElsahar Я думаю, что все в порядке, если вы хотите иметь больше контроля внутри обратного вызова, а обработка исключений на более глобальном уровне не вариант. - person alecxe; 15.11.2014