Веб -сканер , иногда называемый пауком или паукоботом , а часто сокращаемый до краулера , представляет собой интернет-бот , который систематически просматривает Всемирную паутину и обычно используется поисковыми системами для целей веб-индексации ( веб-паукинг ). [1]
Поисковые системы и некоторые другие веб-сайты используют программное обеспечение для веб-краулинга или спайдеринга для обновления своего веб-контента или индексов веб-контента других сайтов. Веб-краулеры копируют страницы для обработки поисковой системой, которая индексирует загруженные страницы, чтобы пользователи могли выполнять поиск более эффективно.
Краулеры потребляют ресурсы на посещаемых системах и часто посещают сайты без приглашения. Проблемы расписания, нагрузки и «вежливости» вступают в игру, когда осуществляется доступ к большим наборам страниц. Существуют механизмы для публичных сайтов, не желающих, чтобы их сканировали, чтобы сообщить об этом сканирующему агенту. Например, включение robots.txt
файла может потребовать от ботов индексировать только части веб-сайта или вообще ничего.
Количество страниц в Интернете чрезвычайно велико; даже самые крупные поисковые роботы не способны создать полный индекс. По этой причине поисковые системы с трудом выдавали релевантные результаты поиска в первые годы существования Всемирной паутины, до 2000 года. Сегодня релевантные результаты выдаются практически мгновенно.
Краулеры могут проверять гиперссылки и HTML- код. Их также можно использовать для веб-скрапинга и программирования на основе данных .
Веб-сканер также известен как паук [2] , муравей , автоматический индексатор [ 3] или (в контексте программного обеспечения FOAF ) веб-скатер [4 ] .
Веб-сканер начинает со списка URL-адресов для посещения. Эти первые URL-адреса называются семенами . Когда сканер посещает эти URL-адреса, связываясь с веб-серверами , которые отвечают на эти URL-адреса, он идентифицирует все гиперссылки на извлеченных веб-страницах и добавляет их в список URL-адресов для посещения, называемый границей сканирования . URL-адреса из границы рекурсивно посещаются в соответствии с набором политик. Если сканер выполняет архивирование веб-сайтов (или веб-архивирование ), он копирует и сохраняет информацию по мере ее поступления. Архивы обычно хранятся таким образом, что их можно просматривать, читать и перемещаться по ним, как если бы они находились в реальном Интернете, но они сохраняются как «моментальные снимки». [5]
Архив известен как репозиторий и предназначен для хранения и управления коллекцией веб-страниц . Репозиторий хранит только HTML- страницы, и эти страницы хранятся как отдельные файлы. Репозиторий похож на любую другую систему, которая хранит данные, например, современную базу данных. Единственное отличие состоит в том, что репозиторию не нужны все функции, предлагаемые системой баз данных. Репозиторий хранит самую последнюю версию веб-страницы, извлеченную сканером. [ необходима цитата ]
Большой объем подразумевает, что краулер может загрузить только ограниченное количество веб-страниц в течение определенного времени, поэтому ему необходимо расставить приоритеты для своих загрузок. Высокая скорость изменений может означать, что страницы могли быть уже обновлены или даже удалены.
Количество возможных URL-адресов, сканируемых серверным программным обеспечением, также затрудняет для веб-сканеров избегание получения дублированного контента . Существуют бесконечные комбинации параметров HTTP GET (на основе URL), из которых только небольшая выборка фактически вернет уникальный контент. Например, простая онлайн-фотогалерея может предлагать пользователям три варианта, как указано с помощью параметров HTTP GET в URL-адресе. Если существует четыре способа сортировки изображений, три варианта размера миниатюры , два формата файлов и возможность отключить предоставленный пользователем контент, то к одному и тому же набору контента можно получить доступ с помощью 48 различных URL-адресов, все из которых могут быть связаны на сайте. Эта математическая комбинация создает проблему для сканеров, поскольку им приходится перебирать бесконечные комбинации относительно небольших изменений скриптов, чтобы получить уникальный контент.
Как отметили Эдвардс и др. , «Учитывая, что пропускная способность для проведения сканирования не является ни бесконечной, ни бесплатной, становится необходимым сканировать Интернет не только масштабируемым, но и эффективным способом, если необходимо поддерживать разумную меру качества или новизны». [6] Сканер должен тщательно выбирать на каждом этапе, какие страницы посетить следующими.
Поведение веб-сканера является результатом комбинации политик: [7]
Учитывая текущий размер Интернета, даже крупные поисковые системы охватывают только часть общедоступной части. Исследование 2009 года показало, что даже крупномасштабные поисковые системы индексируют не более 40–70% индексируемого Интернета; [8] предыдущее исследование Стива Лоуренса и Ли Джайлса показало, что ни одна поисковая система не индексировала более 16% Интернета в 1999 году. [9] Поскольку поисковый робот всегда загружает только часть веб-страниц , крайне желательно, чтобы загруженная часть содержала наиболее релевантные страницы, а не просто случайную выборку из Интернета.
Это требует метрики важности для приоритезации веб-страниц. Важность страницы является функцией ее внутреннего качества, ее популярности с точки зрения ссылок или посещений и даже ее URL (последнее относится к вертикальным поисковым системам, ограниченным одним доменом верхнего уровня , или поисковым системам, ограниченным фиксированным веб-сайтом). Разработка хорошей политики выбора имеет дополнительную сложность: она должна работать с частичной информацией, поскольку полный набор веб-страниц неизвестен во время сканирования.
Junghoo Cho и др. провели первое исследование политик планирования сканирования. Их набор данных представлял собой сканирование 180 000 страниц домена stanford.edu, в котором была выполнена имитация сканирования с использованием различных стратегий. [10] Протестированными метриками упорядочения были расчеты ширины , количества обратных ссылок и частичного PageRank . Одним из выводов было то, что если сканер хочет загрузить страницы с высоким Pagerank на ранней стадии процесса сканирования, то лучше использовать стратегию частичного Pagerank, за которой следуют ширина и количество обратных ссылок. Однако эти результаты относятся только к одному домену. Чо также написал докторскую диссертацию в Стэнфорде по веб-сканированию. [11]
Найорк и Винер провели фактическое сканирование 328 миллионов страниц, используя упорядочение в ширину. [12] Они обнаружили, что сканирование в ширину захватывает страницы с высоким Pagerank в начале сканирования (но они не сравнивали эту стратегию с другими стратегиями). Объяснение, данное авторами этому результату, заключается в том, что «наиболее важные страницы имеют много ссылок на них с многочисленных хостов, и эти ссылки будут найдены на ранней стадии, независимо от того, с какого хоста или страницы начинается сканирование».
Abiteboul разработал стратегию сканирования, основанную на алгоритме OPIC (On-line Page Importance Computation). [13] В OPIC каждой странице дается начальная сумма «наличных», которая равномерно распределяется между страницами, на которые она указывает. Это похоже на вычисление PageRank, но работает быстрее и выполняется только в один шаг. Сканер, управляемый OPIC, сначала загружает страницы на границе сканирования с более высокими суммами «наличных». Эксперименты проводились на синтетическом графике из 100 000 страниц с распределением входящих ссылок по степенному закону. Однако не было никакого сравнения с другими стратегиями или экспериментами в реальном Интернете.
Болди и др. использовали моделирование на подмножествах Интернета из 40 миллионов страниц из .itдомена и 100 миллионов страниц из краулера WebBase, тестируя сначала ширину против сначала глубины, случайный порядок и всеведущую стратегию. Сравнение основывалось на том, насколько хорошо PageRank, вычисленный при частичном краулере, приближается к истинному значению PageRank. Некоторые посещения, которые накапливают PageRank очень быстро (в частности, посещение в ширину и всеведущее посещение), дают очень плохие прогрессивные приближения. [14] [15]
Баеза-Йейтс и др. использовали моделирование на двух подмножествах Интернета из 3 миллионов страниц из домена .grи .cl, тестируя несколько стратегий сканирования. [16] Они показали, что как стратегия OPIC, так и стратегия, которая использует длину очередей для каждого сайта, лучше, чем сканирование в ширину , и что также очень эффективно использовать предыдущее сканирование, когда оно доступно, для руководства текущим.
Данешпаджоу и др. разработали алгоритм на основе сообщества для обнаружения хороших семян. [17] Их метод сканирует веб-страницы с высоким PageRank из разных сообществ за меньшее количество итераций по сравнению со сканированием, начинающимся со случайных семян. С помощью этого нового метода можно извлечь хорошие семена из ранее просканированного веб-графа. Используя эти семена, новый обход может быть очень эффективным.
Сканер может захотеть искать только HTML-страницы и избегать всех других типов MIME . Чтобы запросить только HTML-ресурсы, сканер может сделать запрос HTTP HEAD для определения типа MIME веб-ресурса перед запросом всего ресурса с помощью запроса GET. Чтобы избежать выполнения многочисленных запросов HEAD, сканер может проверить URL-адрес и запросить ресурс только в том случае, если URL-адрес заканчивается определенными символами, такими как .html, .htm, .asp, .aspx, .php, .jsp, .jspx или косой чертой. Эта стратегия может привести к непреднамеренному пропуску многочисленных HTML-ресурсов.
Некоторые сканеры также могут избегать запроса любых ресурсов, которые содержат "?" в них (создаются динамически), чтобы избежать ловушек паука , которые могут заставить сканер загрузить бесконечное количество URL с веб-сайта. Эта стратегия ненадежна, если сайт использует переписывание URL для упрощения своих URL.
Краулеры обычно выполняют некоторый тип нормализации URL , чтобы избежать сканирования одного и того же ресурса более одного раза. Термин нормализация URL , также называемый канонизацией URL , относится к процессу изменения и стандартизации URL последовательным образом. Существует несколько типов нормализации, которые могут быть выполнены, включая преобразование URL в нижний регистр, удаление сегментов "." и ".." и добавление конечных слешей к непустому компоненту пути. [18]
Некоторые краулеры намереваются загрузить/выгрузить как можно больше ресурсов с определенного веб-сайта. Поэтому был введен краулер с восходящим путем , который будет подниматься к каждому пути в каждом URL, который он намеревается сканировать. [19] Например, если задан исходный URL http://llama.org/hamster/monkey/page.html, он попытается сканировать /hamster/monkey/, /hamster/ и /. Коти обнаружил, что краулер с восходящим путем был очень эффективен в поиске изолированных ресурсов или ресурсов, для которых не было бы найдено входящей ссылки при обычном сканировании.
Важность страницы для краулера также может быть выражена как функция сходства страницы с заданным запросом. Веб-краулеры, которые пытаются загрузить страницы, похожие друг на друга, называются сфокусированными краулерами или тематическими краулерами . Концепции тематического и сфокусированного сканирования были впервые введены Филиппо Менцером [20] [21] и Соуменом Чакрабарти и др. [22]
Основная проблема при целенаправленном сканировании заключается в том, что в контексте веб-краулера мы хотели бы иметь возможность предсказать сходство текста заданной страницы с запросом до фактической загрузки страницы. Возможным предиктором является якорный текст ссылок; этот подход был использован Пинкертоном [23] в первом веб-краулере на заре Интернета. Дилигенти и др. [24] предлагают использовать полное содержимое уже посещенных страниц, чтобы сделать вывод о сходстве между ведущим запросом и страницами, которые еще не посещались. Производительность целенаправленного сканирования в основном зависит от богатства ссылок в конкретной теме поиска, и целенаправленное сканирование обычно полагается на общую поисковую систему в Интернете для предоставления отправных точек.
Примером целевых краулеров являются академические краулеры, которые сканируют академические документы свободного доступа, такие как citeseerxbot , который является краулером поисковой системы CiteSeer X. Другие академические поисковые системы - Google Scholar и Microsoft Academic Search и т. д. Поскольку большинство академических статей публикуются в форматах PDF , такой тип краулера особенно заинтересован в сканировании файлов PDF, PostScript , Microsoft Word , включая их сжатые форматы. Из-за этого общие краулеры с открытым исходным кодом, такие как Heretrix , должны быть настроены для фильтрации других типов MIME , или промежуточное программное обеспечение используется для извлечения этих документов и импорта их в базу данных и репозиторий целевого сканирования. [25] Определение того, являются ли эти документы академическими или нет, является сложной задачей и может добавить значительные накладные расходы к процессу сканирования, поэтому это выполняется как процесс последующего сканирования с использованием алгоритмов машинного обучения или регулярных выражений . Эти академические документы обычно получают с домашних страниц факультетов и студентов или со страниц публикаций научно-исследовательских институтов. Поскольку академические документы составляют лишь малую часть всех веб-страниц, хороший выбор начальных данных важен для повышения эффективности этих веб-краулеров. [26] Другие академические краулеры могут загружать простые текстовые и HTML- файлы, которые содержат метаданные академических статей, такие как заголовки, статьи и аннотации. Это увеличивает общее количество статей, но значительная часть может не предоставлять бесплатные загрузки PDF.
Другой тип целевых краулеров — это семантически-целевой краулер, который использует онтологии доменов для представления тематических карт и связывает веб-страницы с соответствующими онтологическими концепциями для целей выбора и категоризации. [27] Кроме того, онтологии могут автоматически обновляться в процессе сканирования. Донг и др. [28] представили такой краулер на основе обучения онтологиям, использующий машину опорных векторов для обновления содержимого онтологических концепций при сканировании веб-страниц.
Веб имеет очень динамичную природу, и сканирование части Веба может занять недели или месяцы. К тому времени, как веб-сканер закончит сканирование, может произойти много событий, включая создания, обновления и удаления.
С точки зрения поисковой системы, существуют затраты, связанные с необнаружением события, и, таким образом, с устаревшей копией ресурса. Наиболее используемые функции затрат — свежесть и возраст. [29]
Свежесть : Это бинарная мера, которая указывает, является ли локальная копия точной или нет. Свежесть страницы p в репозитории в момент времени t определяется как:
Возраст : Это мера, которая показывает, насколько устарела локальная копия. Возраст страницы p в репозитории в момент времени t определяется как:
Коффман и др. работали с определением цели веб-краулера, которое эквивалентно свежести, но используют другую формулировку: они предлагают, чтобы краулер минимизировал долю времени, в течение которого страницы остаются устаревшими. Они также отметили, что проблема веб-краулера может быть смоделирована как многоочередная односерверная система опроса, в которой веб-краулер является сервером, а веб-сайты — очередями. Изменения страниц — это прибытие клиентов, а время переключения — это интервал между доступами к страницам на одном веб-сайте. В рамках этой модели среднее время ожидания клиента в системе опроса эквивалентно среднему возрасту веб-краулера. [30]
Цель краулера — поддерживать среднюю свежесть страниц в своей коллекции как можно выше или поддерживать средний возраст страниц как можно ниже. Эти цели не эквивалентны: в первом случае краулер просто интересуется тем, сколько страниц устарело, а во втором случае краулер интересуется тем, насколько стары локальные копии страниц.
Чо и Гарсия-Молина изучили две простые политики повторного посещения: [31]
В обоих случаях повторный порядок сканирования страниц может осуществляться как в случайном, так и в фиксированном порядке.
Чо и Гарсия-Молина доказали удивительный результат, что с точки зрения средней свежести единая политика превосходит пропорциональную политику как в смоделированной сети, так и в реальном веб-сканировании. Интуитивно, рассуждение заключается в том, что, поскольку веб-сканеры имеют ограничение на то, сколько страниц они могут сканировать за определенный промежуток времени, (1) они будут выделять слишком много новых сканирований для быстро меняющихся страниц за счет менее частого обновления страниц, и (2) свежесть быстро меняющихся страниц сохраняется в течение более короткого периода, чем у менее часто меняющихся страниц. Другими словами, пропорциональная политика выделяет больше ресурсов для сканирования часто обновляющихся страниц, но испытывает меньшее общее время свежести от них.
Чтобы улучшить свежесть, краулер должен штрафовать элементы, которые меняются слишком часто. [32] Оптимальная политика повторного посещения не является ни единой политикой, ни пропорциональной политикой. Оптимальный метод для поддержания высокой средней свежести включает игнорирование страниц, которые меняются слишком часто, а оптимальный метод для поддержания низкого среднего возраста — использовать частоты доступа, которые монотонно (и сублинейно) увеличиваются со скоростью изменения каждой страницы. В обоих случаях оптимум ближе к единой политике, чем к пропорциональной политике: как отмечают Коффман и др. , «чтобы минимизировать ожидаемое время устаревания, доступы к любой конкретной странице должны быть максимально равномерно распределены». [30] Явные формулы для политики повторного посещения в общем случае недостижимы, но они получены численно, поскольку зависят от распределения изменений страниц. Чо и Гарсия-Молина показывают, что экспоненциальное распределение хорошо подходит для описания изменений страниц, [32] в то время как Ипейротис и др. показать, как использовать статистические инструменты для обнаружения параметров, которые влияют на это распределение. [33] Рассмотренные здесь политики повторного посещения считают все страницы однородными с точки зрения качества («все страницы в Интернете имеют одинаковую ценность»), что не является реалистичным сценарием, поэтому для достижения лучшей политики сканирования следует включить дополнительную информацию о качестве веб-страницы.
Краулеры могут извлекать данные гораздо быстрее и глубже, чем люди, выполняющие поиск, поэтому они могут оказывать разрушительное воздействие на производительность сайта. Если один краулер выполняет несколько запросов в секунду и/или загружает большие файлы, серверу может быть трудно справляться с запросами от нескольких краулеров.
Как отметил Костер, использование веб-краулеров полезно для ряда задач, но имеет свою цену для всего сообщества. [34] Расходы на использование веб-краулеров включают в себя:
Частичным решением этих проблем является протокол исключения роботов , также известный как протокол robots.txt, который является стандартом для администраторов, указывающим, к каким частям их веб-серверов не должны иметь доступ сканеры. [35] Этот стандарт не включает предложение по интервалу посещений одного и того же сервера, хотя этот интервал является наиболее эффективным способом избежать перегрузки сервера. Недавно коммерческие поисковые системы, такие как Google , Ask Jeeves , MSN и Yahoo! Search, смогли использовать дополнительный параметр «Crawl-delay:» в файле robots.txt для указания количества секунд задержки между запросами.
Первый предложенный интервал между последовательными загрузками страниц составлял 60 секунд. [36] Однако, если бы страницы загружались с такой скоростью с веб-сайта, содержащего более 100 000 страниц, через идеальное соединение с нулевой задержкой и бесконечной пропускной способностью, то потребовалось бы более 2 месяцев, чтобы загрузить только этот веб-сайт целиком; кроме того, была бы использована только часть ресурсов этого веб-сервера.
Cho использует 10 секунд в качестве интервала для доступа, [31] а WIRE crawler использует 15 секунд по умолчанию. [37] MercatorWeb crawler следует адаптивной политике вежливости: если загрузка документа с данного сервера заняла t секунд, то краулер ждет 10 t секунд перед загрузкой следующей страницы. [38] Dill et al. используют 1 секунду. [39]
Для тех, кто использует веб-краулеры в исследовательских целях, необходим более подробный анализ затрат и выгод, а также следует учитывать этические соображения при принятии решения о том, где и как быстро сканировать. [40]
Неподтвержденные данные из журналов доступа показывают, что интервалы доступа известных краулеров варьируются от 20 секунд до 3–4 минут. Стоит отметить, что даже при очень вежливом обращении и принятии всех мер предосторожности для предотвращения перегрузки веб-серверов администраторы веб-серверов все равно получают некоторые жалобы. Сергей Брин и Ларри Пейдж отметили в 1998 году: «... запуск краулера, который подключается к более чем полумиллиону серверов... генерирует изрядное количество электронных писем и телефонных звонков. Из-за огромного количества людей, выходящих в сеть, всегда есть те, кто не знает, что такое краулер, потому что это первый краулер, который они видят». [41]
Параллельный краулер — это краулер , который запускает несколько процессов параллельно. Цель — максимизировать скорость загрузки, минимизируя накладные расходы от параллелизации и избегать повторных загрузок одной и той же страницы. Чтобы избежать загрузки одной и той же страницы более одного раза, система сканирования требует политики для назначения новых URL-адресов, обнаруженных в процессе сканирования, поскольку один и тот же URL-адрес может быть найден двумя различными процессами сканирования.
Сканер должен не только иметь хорошую стратегию сканирования, как отмечалось в предыдущих разделах, но и иметь высокооптимизированную архитектуру.
Шкапенюк и Суэль отметили, что: [42]
В то время как создать медленный сканер, который загружает несколько страниц в секунду в течение короткого периода времени, довольно просто, создание высокопроизводительной системы, способной загружать сотни миллионов страниц в течение нескольких недель, представляет собой ряд проблем с точки зрения проектирования системы, эффективности ввода-вывода и сети, а также надежности и управляемости.
Веб-краулеры являются центральной частью поисковых систем, и подробности об их алгоритмах и архитектуре хранятся как коммерческая тайна. Когда публикуются проекты краулеров, часто наблюдается существенный недостаток деталей, который не позволяет другим воспроизводить работу. Также возникают опасения по поводу « спама поисковых систем », что не позволяет основным поисковым системам публиковать свои алгоритмы ранжирования.
Хотя большинство владельцев веб-сайтов стремятся как можно шире индексировать свои страницы, чтобы обеспечить себе высокие позиции в поисковых системах , сканирование веб-страниц может также иметь непреднамеренные последствия и привести к компрометации или утечке данных , если поисковая система индексирует ресурсы, которые не должны быть общедоступными, или страницы, раскрывающие потенциально уязвимые версии программного обеспечения.
Помимо стандартных рекомендаций по безопасности веб-приложений владельцы веб-сайтов могут снизить свою уязвимость для случайных взломов, разрешив поисковым системам индексировать только общедоступные части своих веб-сайтов (с помощью robots.txt ) и явно заблокировав им индексацию транзакционных частей (страниц входа, личных страниц и т. д.).
Веб-сканеры обычно идентифицируют себя на веб-сервере, используя поле User-agent HTTP- запроса. Администраторы веб-сайтов обычно проверяют журнал своих веб-серверов и используют поле user-agent, чтобы определить, какие сканеры посещали веб-сервер и как часто. Поле user-agent может включать URL , по которому администратор веб-сайта может узнать больше информации о сканере. Проверка журнала веб-сервера — утомительная задача, и поэтому некоторые администраторы используют инструменты для идентификации, отслеживания и проверки веб-сканеров. Спам-боты и другие вредоносные веб-сканеры вряд ли будут размещать идентификационную информацию в поле user-agent, или они могут маскировать свою личность как браузер или другой известный сканер.
Администраторы веб-сайтов предпочитают, чтобы веб-краулеры идентифицировали себя, чтобы при необходимости иметь возможность связаться с владельцем. В некоторых случаях краулеры могут случайно попасть в ловушку краулера или перегрузить веб-сервер запросами, и владельцу необходимо остановить краулера. Идентификация также полезна для администраторов, которые хотят знать, когда они могут ожидать, что их веб-страницы будут проиндексированы определенной поисковой системой .
Огромное количество веб-страниц находится в глубокой или невидимой паутине . [43] Эти страницы обычно доступны только путем отправки запросов в базу данных, и обычные сканеры не могут найти эти страницы, если нет ссылок, указывающих на них. Протокол Sitemaps и mod oai компании Google [44] предназначены для обнаружения этих ресурсов глубокой паутины .
Глубокий веб-краулинг также увеличивает количество веб-ссылок для сканирования. Некоторые краулеры принимают только некоторые URL-адреса в <a href="URL">
форме. В некоторых случаях, например, Googlebot , веб-краулинг выполняется по всему тексту, содержащемуся внутри гипертекстового контента, тегов или текста.
Стратегические подходы могут быть использованы для нацеливания на контент Deep Web. С помощью техники, называемой Screen Scraping , специализированное программное обеспечение может быть настроено для автоматического и многократного запроса заданной веб-формы с целью агрегации полученных данных. Такое программное обеспечение может использоваться для охвата нескольких веб-форм на нескольких веб-сайтах. Данные, извлеченные из результатов отправки одной веб-формы, могут быть взяты и применены в качестве входных данных для другой веб-формы, таким образом устанавливая непрерывность в Deep Web способом, невозможным с помощью традиционных веб-сканеров. [45]
Страницы, созданные на основе AJAX, относятся к тем, которые вызывают проблемы у веб-сканеров. Google предложил формат вызовов AJAX, который их бот может распознавать и индексировать. [46]
В сети доступно множество продуктов "визуальных веб-скрейперов/краулеров", которые сканируют страницы и структурируют данные в столбцы и строки в соответствии с требованиями пользователей. Одно из главных различий между классическим и визуальным краулером заключается в уровне навыков программирования, необходимых для настройки краулера. Последнее поколение "визуальных скрейперов" устраняет большую часть навыков программирования, необходимых для программирования и запуска сканирования для сбора веб-данных.
Метод визуального скрапинга/сканирования основан на том, что пользователь «обучает» часть технологии краулера, которая затем следует шаблонам в полуструктурированных источниках данных. Доминирующий метод обучения визуального краулера заключается в выделении данных в браузере и обучении столбцов и строк. Хотя эта технология не нова, например, она была основой Needlebase, которую купила Google (как часть более крупного приобретения ITA Labs [47] ), наблюдается постоянный рост и инвестиции в эту область со стороны инвесторов и конечных пользователей. [ необходима цитата ]
Ниже приведен список опубликованных архитектур поисковых роботов общего назначения (за исключением специализированных веб-роботов) с кратким описанием, включающим названия различных компонентов и выдающиеся функции:
Следующие веб-краулеры доступны по цене:
{{cite book}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: Цитировать журнал требует |journal=
( помощь ){{cite journal}}
: Цитировать журнал требует |journal=
( помощь )