BeautifulSoup and lxml are libraries for parsing HTML and XML. Scrapy is an application framework for writing web spiders that crawl web sites and extract data from them.
Scrapy provides a built-in mechanism for extracting data (called selectors <topics-selectors>
) but you can easily use BeautifulSoup (or lxml) instead, if you feel more comfortable working with them. After all, they're just parsing libraries which can be imported and used from any Python code.
In other words, comparing BeautifulSoup (or lxml) to Scrapy is like comparing jinja2 to Django.
Yes, you can. As mentioned above <faq-scrapy-bs-cmp>
, BeautifulSoup can be used for parsing HTML responses in Scrapy callbacks. You just have to feed the response's body into a BeautifulSoup
object and extract whatever data you need from it.
Here's an example spider using BeautifulSoup API, with lxml
as the HTML parser:
from bs4 import BeautifulSoup
import scrapy
class ExampleSpider(scrapy.Spider):
name = "example"
allowed_domains = ["example.com"]
start_urls = (
'http://www.example.com/',
)
def parse(self, response):
# use lxml to get decent HTML parsing speed
soup = BeautifulSoup(response.text, 'lxml')
yield {
"url": response.url,
"title": soup.h1.string
}
Note
BeautifulSoup
supports several HTML/XML parsers. See BeautifulSoup's official documentation on which ones are available.
Probably, but we don't like that word. We think Django is a great open source project and an example to follow, so we've used it as an inspiration for Scrapy.
We believe that, if something is already done well, there's no need to reinvent it. This concept, besides being one of the foundations for open source and free software, not only applies to software but also to documentation, procedures, policies, etc. So, instead of going through each problem ourselves, we choose to copy ideas from those projects that have already solved them properly, and focus on the real problems we need to solve.
We'd be proud if Scrapy serves as an inspiration for other projects. Feel free to steal from us!
Yes. Support for HTTP proxies is provided (since Scrapy 0.8) through the HTTP Proxy downloader middleware. See ~scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware
.
See topics-request-response-ref-request-callback-arguments
.
You need to install pywin32 because of this Twisted bug.
See topics-request-response-ref-request-userlogin
.
By default, Scrapy uses a LIFO queue for storing pending requests, which basically means that it crawls in DFO order. This order is more convenient in most cases.
If you do want to crawl in true BFO order, you can do it by setting the following settings:
DEPTH_PRIORITY = 1
SCHEDULER_DISK_QUEUE = 'scrapy.squeues.PickleFifoDiskQueue'
SCHEDULER_MEMORY_QUEUE = 'scrapy.squeues.FifoMemoryQueue'
While pending requests are below the configured values of CONCURRENT_REQUESTS
, CONCURRENT_REQUESTS_PER_DOMAIN
or CONCURRENT_REQUESTS_PER_IP
, those requests are sent concurrently. As a result, the first few requests of a crawl rarely follow the desired order. Lowering those settings to 1
enforces the desired order, but it significantly slows down the crawl as a whole.
See topics-leaks
.
Also, Python has a builtin memory leak issue which is described in topics-leaks-without-leaks
.
See previous question.
Yes, see ~scrapy.downloadermiddlewares.httpauth.HttpAuthMiddleware
.
Try changing the default Accept-Language request header by overriding the DEFAULT_REQUEST_HEADERS
setting.
See intro-examples
.
Yes. You can use the runspider
command. For example, if you have a spider written in a my_spider.py
file you can run it with:
scrapy runspider my_spider.py
See runspider
command for more info.
Those messages (logged with DEBUG
level) don't necessarily mean there is a problem, so you may not need to fix them.
Those messages are thrown by the Offsite Spider Middleware, which is a spider middleware (enabled by default) whose purpose is to filter out requests to domains outside the ones covered by the spider.
For more info see: ~scrapy.spidermiddlewares.offsite.OffsiteMiddleware
.
See topics-deploy
.
It'll depend on how large your output is. See this warning
<json-with-large-data>
in ~scrapy.exporters.JsonItemExporter
documentation.
Some signals support returning deferreds from their handlers, others don't. See the topics-signals-ref
to know which ones.
999 is a custom response status code used by Yahoo sites to throttle requests. Try slowing down the crawling speed by using a download delay of 2
(or higher) in your spider:
class MySpider(CrawlSpider):
name = 'myspider'
download_delay = 2
# [ ... rest of the spider code ... ]
Or by setting a global download delay in your project with the DOWNLOAD_DELAY
setting.
Yes, but you can also use the Scrapy shell which allows you to quickly analyze (and even modify) the response being processed by your spider, which is, quite often, more useful than plain old pdb.set_trace()
.
For more info see topics-shell-inspect-response
.
To dump into a JSON file:
scrapy crawl myspider -O items.json
To dump into a CSV file:
scrapy crawl myspider -O items.csv
To dump into a XML file:
scrapy crawl myspider -O items.xml
For more information see topics-feed-exports
The __VIEWSTATE
parameter is used in sites built with ASP.NET/VB.NET. For more info on how it works see this page. Also, here's an example spider which scrapes one of these sites.
Parsing big feeds with XPath selectors can be problematic since they need to build the DOM of the entire feed in memory, and this can be quite slow and consume a lot of memory.
In order to avoid parsing all the entire feed at once in memory, you can use the functions xmliter
and csviter
from scrapy.utils.iterators
module. In fact, this is what the feed spiders (see topics-spiders
) use under the cover.
Yes, Scrapy receives and keeps track of cookies sent by servers, and sends them back on subsequent requests, like any regular web browser does.
For more info see topics-request-response
and cookies-mw
.
Enable the COOKIES_DEBUG
setting.
Raise the ~scrapy.exceptions.CloseSpider
exception from a callback. For more info see: ~scrapy.exceptions.CloseSpider
.
See bans
.
Both spider arguments <spiderargs>
and settings <topics-settings>
can be used to configure your spider. There is no strict rule that mandates to use one or the other, but settings are more suited for parameters that, once set, don't change much, while spider arguments are meant to change more often, even on each spider run and sometimes are required for the spider to run at all (for example, to set the start url of a spider).
To illustrate with an example, assuming you have a spider that needs to log into a site to scrape data, and you only want to scrape data from a certain section of the site (which varies each time). In that case, the credentials to log in would be settings, while the url of the section to scrape would be a spider argument.
You may need to remove namespaces. See removing-namespaces
.
Item pipelines <topics-item-pipeline>
cannot yield multiple items per input item. Create a spider middleware <custom-spider-middleware>
instead, and use its ~scrapy.spidermiddlewares.SpiderMiddleware.process_spider_output
method for this purpose. For example:
from copy import deepcopy
from itemadapter import is_item, ItemAdapter
class MultiplyItemsMiddleware:
def process_spider_output(self, response, result, spider):
for item in result:
if is_item(item):
adapter = ItemAdapter(item)
for _ in range(adapter['multiply_by']):
yield deepcopy(item)
Yes, by setting DNS_RESOLVER
to scrapy.resolver.CachingHostnameResolver
. Note that by doing so, you lose the ability to set a specific timeout for DNS requests (the value of the DNS_TIMEOUT
setting is ignored).
This issue has been reported to appear when running broad crawls in macOS, where the default Twisted reactor is twisted.internet.selectreactor.SelectReactor
. Switching to a different reactor is possible by using the TWISTED_REACTOR
setting.
In some situations, it might be useful to stop the download of a certain response. For instance, sometimes you can determine whether or not you need the full contents of a response by inspecting its headers or the first bytes of its body. In that case, you could save resources by attaching a handler to the ~scrapy.signals.bytes_received
or ~scrapy.signals.headers_received
signals and raising a ~scrapy.exceptions.StopDownload
exception. Please refer to the topics-stop-response-download
topic for additional information and examples.