XPath बनाम CSS चयनकर्ता: वेब स्क्रैपिंग के लिए किसका उपयोग करें

TL;DR:

• CSS और XPath सामान्य निष्कासन के लिए समान परिणाम लौटाते हैं: article.product_pod h3 a::attr(title) और //article[@class='product_pod']/h3/a/@title से समान बीस पुस्तक शीर्षक उसी पृष्ठ में लौटे।
• XPath दोनों में से एकमात्र है जो पेड़ को ऊपर चलाता है। parent::, ancestor::, preceding-sibling::, और following-sibling:: ने उस पृष्ठ पर 20 नोड्स से मेल खाया; CSS के पास इनमें से किसी के लिए भी समान नहीं है।
• "CSS तेज़ है" एक ब्राउज़र तथ्य है, न कि एक पायथन तथ्य। पार्सल में एक ही निष्कासन CSS द्वारा 487.1 मिलीसेकंड की लागत लगती है जबकि XPath द्वारा 309.1 मिलीसेकंड लागत लगती है, 2,000 पुनरावृत्तियों में, क्योंकि cssselect प्रत्येक CSS प्रश्न को XPath में संग्रहीत करता है इससे पहले कि यह निष्पादित किया जाए।
• a:contains('Sharp') पार्सल में एक मिलान लौटाता है और एक वास्तविक Chrome पृष्ठ के अंदर SyntaxError फेंकता है, यही कारण है कि एक चयनकर्ता एक स्क्रैपर में कार्य कर सकता है और DevTools में विफल हो सकता है।
• כאשר जोड़ी भाषा तब मायने नहीं रखती जब मार्कअप कभी नहीं पहुंचता; एक चयनकर्ता केवल एक DOM को क्वेरी कर सकता है जो वास्तव में निर्मित हुआ हो।
• दोनों भाषाएँ आपके फ़ेच स्तर द्वारा डिकोड किए गए बाइट्स को पढ़ती हैं, इसलिए एक पृष्ठ जो बिना एक charset के परोसा जाता है वह £47.82 वापस ला सकता है जबकि ब्राउज़र £47.82 दिखाता है।
• Scrapeless मुफ्त योजना पर पूर्ण रूप से प्रस्तुत पृष्ठों के खिलाफ कोई भी सिंटैक्स चलाएँ।

किसी भी उत्पाद सूची पर निरीक्षक खोलें, Chrome द्वारा पेश किए गए चयनकर्ता को कॉपी करें, उसे एक पायथन स्क्रैपर में चिपकाएँ, और यह आमतौर पर काम करता है। रोचक मामले वे हैं जहाँ यह काम नहीं करता — जहाँ चयनकर्ता एक इंजन में वैध है और दूसरे में एक सिंटैक्स त्रुटि है, या जहाँ आपके द्वारा लिखी गई सुंदर CSS उस XPath से धीमी साबित होती है जिसे आपने टाला।

दो भाषाएँ भारी ओवरलैप होती हैं, इसलिए उपयोगी तुलना किनारों पर बैठती है: प्रत्येक एक क्या व्यक्त कर सकता है, प्रत्येक की क्या लागत है, और कौन सा इंजन वास्तव में क्वेरी को निष्पादित कर रहा है।

नीचे दिए गए सभी माप एक सार्वजनिक पृष्ठ से आते हैं जो स्क्रैपिंग प्रैक्टिस के लिए बनाए गए थे — books.toscrape.com पर बीस-बुक श्रेणी सूची — lxml 6.0.2, cssselect 1.3.0, और parsel 1.10.0 के साथ पार्स किया गया।

दोनों भाषाओं में वही क्वेरी

सामान्य लक्ष्यों के लिए, दोनों भाषाएँ एक-दूसरे का सीधा अनुवाद हैं। नीचे दी गई तालिका उन क्वेरियों को जोड़ती है जो परीक्षण पृष्ठ पर एक समान नोड सेट का चयन करती हैं।

उस तालिका से तीन जोड़े, लाइव पृष्ठ के खिलाफ चलाए गए, मेल खाते नोड सेट लौटाए:

from parsel import Selector
import requests

url = "https://books.toscrape.com/catalogue/category/books/mystery_3/index.html"
response = requests.get(url, timeout=30)
response.raise_for_status()
sel = Selector(text=response.content.decode("utf-8"))

pairs = [
    ("article.product_pod h3 a::attr(href)", "//article[@class='product_pod']/h3/a/@href"),
    ("p.star-rating::attr(class)",           "//p[contains(@class,'star-rating')]/@class"),
    ("div.image_container img::attr(alt)",   "//div[@class='image_container']//img/@alt"),
]
for css_query, xpath_query in pairs:
    css_hits = sel.css(css_query).getall()
    xpath_hits = sel.xpath(xpath_query).getall()
    print(len(css_hits), len(xpath_hits), css_hits == xpath_hits)

प्रत्येक जोड़े ने 20 20 True को प्रिंट किया। जहाँ दोनों भाषाएँ लक्ष्य व्यक्त कर सकती हैं, विकल्प पठनीयता है, क्षमता नहीं।

केवल XPath क्या व्यक्त कर सकता है

CSS नीचे की ओर चयन करता है। यह एक पूर्वज से वंशज की ओर आगे बढ़ता है और कभी पीछे नहीं लौटता, इसलिए एक नियम कह सकता है "इस कार्ड के अंदर की कीमत" लेकिन "इस कीमत को रखने वाला कार्ड" नहीं।

XPath अक्ष ले जाता है, और इनमें से चार का कोई CSS समकक्ष नहीं है। प्रत्येक ने परीक्षण पृष्ठ पर 20 नोड्स से मेल खाया:

axes = [
    ("parent::",            "//p[@class='price_color']/parent::div/@class"),
    ("ancestor::",          "//h3/ancestor::article/@class"),
    ("preceding-sibling::", "//div[@class='product_price']/preceding-sibling::h3/a/@title"),
    ("following-sibling::", "//h3/following-sibling::div[@class='product_price']//p[@class='price_color']/text()"),
]
for label, query in axes:
    hits = sel.xpath(query).getall()
    print(f"{label:20s} {len(hits):2d} hits   {hits[0]!r}")

parent::             20 hits   'product_price'
ancestor::           20 hits   'product_pod'
preceding-sibling::  20 hits   'Sharp Objects'
following-sibling::  20 hits   '£47.82'

अंतिम एक पैटर्न रखने लायक है। "शीर्षक खोजें, फिर इसके बाद की कीमत लें" एक भाई-बहन संबंध है, और इसे CSS में व्यक्त करना यानी कीमत को अलग से चुनना और दोनों सूचियों को अनुक्रमांक द्वारा फिर से जोड़ना — जिसका मौन तरीके से गलत जोड़े उत्पन्न करना है जब एक कार्ड में मूल्य गायब होता है।

W3C चयनकर्ता स्तर 4 विनिर्देशन CSS व्याकरण को परिभाषित करता है, और ऊपर की ओर यात्रा इसे डिज़ाइन द्वारा अनुपस्थित रखता है: यह भाषा स्टाइलिंग के लिए बनाई गई थी, जहाँ एक रेंडर नियमों को शीर्ष से नीचे हल करता है। XPath 1.0 सिफारिश तेरह अक्षों को परिभाषित करता है क्योंकि यह एक दस्तावेज़ पेड़ में मनमाने नोड्स का पता लगाने के लिए बनाया गया था।

:contains विभाजन

पाठ मिलान वह स्थान है जहाँ दोनों भाषाएँ इस तरह से विभाजित होती हैं कि उलझन भरे बग रिपोर्ट उत्पन्न होती हैं।

XPath में हमेशा contains() रहा है। CSS में एक प्रारंभिक ड्राफ्ट में :contains() उप-श्रेणी था और इसे विनिर्देशन स्थिर होने से पहले हटा दिया गया था। जाल यह है कि पायथन का cssselect अभी भी इसे लागू करता है।

print(len(sel.css("a:contains('Sharp')").getall()))       # 1
print(len(sel.xpath("//a[contains(., 'Sharp')]").getall()))  # 1

दोनों 1 प्रिंट करते हैं। अब वही दो क्वेरियाँ एक वास्तविक ब्राउज़र पृष्ठ के अंदर, DOM के अपने इंजनों के माध्यम से मूल्यांकित की जाती हैं:

import os
from urllib.parse import urlencode
from playwright.sync_api import sync_playwright

JS = """() => {
  const out = {};
  try { out.css_class = document.querySelectorAll('article.product_pod h3 a').length; }
  catch (e) { out.css_class = 'ERR ' + e.name; }
  try { out.css_contains = document.querySelectorAll("a:contains('Sharp')").length; }
  catch (e) { out.css_contains = 'ERR ' + e.name + ': ' + e.message.slice(0, 60); }
  const xp = (q) => document.evaluate(q, document, null,
    XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null).snapshotLength;
  out.xpath_class    = xp("//article[@class='product_pod']/h3/a");
  out.xpath_contains = xp("//a[contains(., 'Sharp')]");
  out.xpath_parent   = xp("//p[@class='price_color']/parent::div");
  out.xpath_ancestor = xp("//h3/ancestor::article");
  return out;
}"""

url = "https://books.toscrape.com/catalogue/category/books/mystery_3/index.html"
endpoint = "wss://browser.scrapeless.com/api/v2/browser?" + urlencode({
    "token": os.environ["SCRAPELESS_API_KEY"], "sessionTTL": 300, "proxyCountry": "US",
})
with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(endpoint)
    page = browser.new_page()
    page.goto(url, wait_until="domcontentloaded")
    for key, value in page.evaluate(JS).items():
        print(f"{key:16s} {value}")
    browser.close()

css_class        20
css_contains     ERR SyntaxError: Failed to execute 'querySelectorAll' on 'Document': 'a:conta
xpath_class      20
xpath_contains   1
xpath_parent     20
xpath_ancestor   20

CSS पाठ मिलान फेंकता है। XPath पाठ मिलान एक नोड लौटाता है। तो एक चयनकर्ता जो पायथन स्क्रैपर में परीक्षण पास करता है, जब कोई उसे DevTools में चेक करने के लिए चिपकाता है तो एक सिंटैक्स त्रुटि उत्पन्न करता है — और इसके विपरीत भी उन सभी के लिए सत्य है जो कंसोल में चयनकर्ताओं को मान्य करते हैं इससे पहले कि वे उन्हें भेजें।
दो चीजें हैं जो उस रन से निकलती हैं जिन्हें नोट करना है। ब्राउज़र XPath का गिरावट नहीं आया है: parent:: और ancestor:: प्रत्येक 20 नोड्स को DOM के document.evaluate इंटरफ़ेस के माध्यम से हल किया गया। और :contains एक लाइब्रेरी एक्सटेंशन है न कि एक भाषा विशेषता, इसलिए यह केवल उतनी दूर यात्रा करता है जितनी दूर लाइब्रेरी जाती है।

यदि एक चयनकर्ता को दोनों जगह काम करना है, तो //a[contains(., 'Sharp')] पोर्टेबल रूप है।

वास्तव में कौन सा तेज़ है

सामान्य उत्तर है कि CSS तेज़ है। यह एक ब्राउज़र में सही है, जहाँ querySelectorAll एक स्वदेशी तेज़ रास्ता है, और यह पायथन में पीछे है।

lxml में कोई CSS इंजन नहीं है। हर CSS क्वेरी को cssselect द्वारा XPath में अनुवादित किया जाता है और XPath इंजन इसे निष्पादित करता है, जैसा कि Scrapy चयनकर्ताओं की प्रलेखन सीधे बताता है। CSS लिखने से अनुवाद चरण में समय बिता जाता है।

import time

N = 2000
start = time.perf_counter()
for _ in range(N):
    sel.css("article.product_pod h3 a::attr(title)").getall()
css_ms = (time.perf_counter() - start) * 1000

start = time.perf_counter()
for _ in range(N):
    sel.xpath("//article[@class='product_pod']/h3/a/@title").getall()
xpath_ms = (time.perf_counter() - start) * 1000

print(f"CSS   {css_ms:8.1f} ms  ({css_ms / N * 1000:6.1f} us/call)")
print(f"XPath {xpath_ms:8.1f} ms  ({xpath_ms / N * 1000:6.1f} us/call)")

CSS      487.1 ms  ( 243.5 us/call)
XPath    309.1 ms  ( 154.5 us/call)

CSS लागत 1.58 गुना XPath समय के लिए समान आउटपुट के लिए। अनुवाद को छापने से दिखाता है कि यह कहाँ जाता है:

from cssselect import GenericTranslator
print(GenericTranslator().css_to_xpath("article.product_pod h3 a"))

descendant-or-self::article[@class and contains(concat(' ', normalize-space(@class), ' '), ' product_pod ')]/descendant-or-self::*/h3/descendant-or-self::*/a

हाथ से लिखित //article[@class='product_pod']/h3/a एक गुण की तुलना करता है। उत्पन्न रूप सफेद स्थान को सामान्य करता है और प्रत्येक उम्मीदवार नोड पर वर्ग सूची को भरता है, क्योंकि इसे कई वर्गों को ले जाने वाले तत्वों के लिए सही होना चाहिए। वह रक्षात्मक पूर्वधारणा 1.58x है।

इसे अनुकूलित करने से पहले अनुपात में डालें: अंतर लगभग 89 माइक्रोसेकंड प्रति कॉल पर 50 केबी पृष्ठ पर है। एकल HTTP अनुरोध हजारों बार अधिक लागत पर है। चयनकर्ता भाषा वह जगह नहीं है जहाँ एक स्क्रैपर का समय जाता है, और पठनीयता आमतौर पर बेहतर व्यापार है — संख्या केवल एक गर्म पार्स लूप में कैश किए गए HTML पर मायने रखती है।

दोनों भाषाओं का जाल

एक चयनकर्ता जो कुछ भी आपके फ़ेच लेयर ने डिकोड किया है उसे लौटाता है। जब एक सर्वर text/html भेजता है जिसमें कोई charset नहीं है, तो अनुरोध ISO-8859-1 पर वापस लौटता है HTTP अर्थशास्त्र विनिर्देशन के मीडिया-प्रकार नियमों के अंतर्गत, जबकि तार पर बाइट्स UTF-8 हैं:

import requests
from parsel import Selector

url = "https://books.toscrape.com/catalogue/category/books/mystery_3/index.html"
response = requests.get(url, timeout=30)
response.raise_for_status()

print(response.headers.get("content-type"))
print(response.encoding)
print(response.apparent_encoding)
print(Selector(text=response.text).css("p.price_color::text").get())
print(Selector(text=response.content.decode("utf-8")).css("p.price_color::text").get())

text/html
ISO-8859-1
utf-8
'£47.82'
'£47.82'

चयनकर्ता दोनों बार सही था। response.content को स्पष्ट रूप से डिकोड करना, बजाय response.text पर भरोसा करने के, वह है जो निकाली गई कीमत को प्रयोग करने योग्य बनाता है — और कोई चयनकर्ता भाषा परिवर्तन इसे ठीक नहीं करता है।

किसी पृष्ठ के खिलाफ चयनकर्ता का परीक्षण करना जो क्लाइंट-साइड पर रेंडर होता है, एक असली ब्राउज़र की आवश्यकता होती है। Scrapeless मुफ्त योजना लाइव DOM के खिलाफ दोनों सिंटैक्स का प्रयास करने के लिए पर्याप्त सत्रों को कवर करती है।

जहाँ नहीं कोई भाषा मदद करती है

दोनों भाषाएँ DOM को क्वेरी करती हैं। न तो एक बनाती है।

जब एक लिस्टिंग क्लाइंट-साइड पर रेंडर होती है, तो एक साधारण HTTP क्लाइंट को जो HTML प्राप्त होता है उसमें शेल होती है और रिकॉर्ड नहीं, इसलिए एक सही चयनकर्ता शून्य नोड्स लौटाता है और ऐसा दिखता है जैसे चयनकर्ता बग है। समाधान चयनकर्ता के अपस्ट्रीम है: पहले पृष्ठ को रेंडर करें, फिर इसे क्वेरी करें। Scrapeless स्क्रैपिंग ब्राउज़र CDP पर एक क्लाउड ब्राउज़र को उजागर करता है, इसलिए वही पृष्ठ जो ब्राउज़र ने इकट्ठा किया है वह है जिस पर आपका चयनकर्ता चलता है — जो ठीक वैसा ही है जैसे ऊपर ब्राउज़र में की गई संख्या कैप्चर की गई थी।

import os
from urllib.parse import urlencode
from playwright.sync_api import sync_playwright

url = "https://books.toscrape.com/catalogue/category/books/mystery_3/index.html"
cdp_endpoint = "wss://browser.scrapeless.com/api/v2/browser?" + urlencode({
    "token": os.environ["SCRAPELESS_API_KEY"],
    "sessionTTL": 300,
    "proxyCountry": "US",
})

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(cdp_endpoint)
    page = browser.new_page()
    page.goto(url, wait_until="domcontentloaded")
    titles = page.eval_on_selector_all(
        "article.product_pod h3 a", "els => els.map(e => e.title)"
    )
    print(len(titles), titles[0])
    browser.close()

20 Sharp Objects

एक बार जब DOM मौजूद हो, तो चयनकर्ता प्रश्न फिर से एक शैली प्रश्न बन जाता है। चयन स्तर के वाकथन के लिए, हमारा पार्सल गाइड एक lxml-बैक्ड पेड़ के ऊपर दोनों बोलियों को कवर करता है, और मूल्य निर्धारण एक रेंडरिंग सत्र की लागत को सूचीबद्ध करता है।

कब CSS चुनें, कब XPath चुनें

CSS चुनें जब लक्ष्य नीचे की ओर पता लगाने योग्य हो और क्वेरी उन लोगों द्वारा पढ़ी जाएगी जो स्टाइलशीट लिखते हैं। यह छोटा है, और परीक्षण पृष्ठ पर इसने बिना किसी हानि के हर सामान्य क्षेत्र को चुना।

XPath चुनें जब जिन रिश्तों की आपको आवश्यकता है वे संरचनात्मक हैं न कि श्रेणीबद्ध — पेड़ में ऊपर, भाई-बहनों के बीच, या पाठ पर कुंजीबद्ध। यह lxml और पार्सल के भीतर ईमानदार डिफ़ॉल्ट भी है, जहाँ यही है जो वास्तव में निष्पादित होता है।
अधिकांश कार्यशील स्क्रेपर्स फ़ील्ड के अनुसार दोनों को मिलाते हैं बजाय इसके कि एक पक्ष चुनें, और पार्सेल दोनों को एक ही पेड़ के खिलाफ स्वीकार करता है, इसलिए निर्णय प्रति-चयनक होता है न कि प्रति-प्रोजेक्ट।

निष्कर्ष

CSS और XPath सामान्य मामलों के लिए समान प्रश्न का उत्तर देते हैं, और दोनों से लौटे बीस शीर्षक समान थे। जो भिन्नताएँ महत्वपूर्ण हैं वे सामान्य रूप से दर्शाए गए ढांचे से संकीर्ण हैं: XPath ऊपर की ओर जाकर और पाठ से मेल खा सकता है, CSS नहीं कर सकता; CSS ब्राउज़र में तेज़ है और lxml में धीमा है, जहाँ यह पहले XPath में संकलित होता है; और :contains एक इंजन में काम करता है जबकि दूसरे में फेंकता है, जो अधिकांश "मेरे स्क्रैपर में काम करता है, कंसोल में नहीं" भ्रम का स्रोत है।

चयनक के अनुसार चुनें, जब एक क्वेरी दोनों स्थानों में चलानी हो तो पोर्टेबल फ़ॉर्म बनाए रखें, और किसी भी भाषा को विकृत वर्ण के लिए दोषी ठहराने से पहले प्रतिक्रिया को डिकोड करें।

क्या आप उन पृष्ठों के खिलाफ चयनकों का परीक्षण करने के लिए तैयार हैं जो आपकी क्वेरी करने से पहले रेंडर करते हैं? Scrapeless नि:शुल्क योजना से शुरू करें और किसी भी सिंटैक्स को एक लाइव DOM पर इंगित करें।

सामान्य प्रश्न

प्रश्न: क्या XPath CSS चयनकर्ताओं से तेज़ है?

यह इंजन पर निर्भर करता है। lxml और पार्सेल में, XPath तेज़ है क्योंकि CSS को निष्पादन से पहले XPath में संकलित किया जाता है - यहाँ मापा गया अंतर 309.1 मि.से. के खिलाफ 487.1 मि.से. था, जो समान निष्कर्ष के 2,000 पुनरावृत्तियों पर है। एक ब्राउज़र में, querySelectorAll एक स्थानीय तेज़ मार्ग है और CSS जीतता है। किसी भी तरह से अंतर प्रत्येक कॉल पर माइक्रोसेकंड है, HTTP अनुरोध की लागत से बहुत कम।

प्रश्न: क्या CSS चयनकर्ता तत्व पाठ से मेल खा सकते हैं?

ब्राउज़र में नहीं। document.querySelectorAll("a:contains('x')") एक SyntaxError फेंकता है, क्योंकि :contains() को चयनकर्ताओं की विशिष्टता स्थापित होने से पहले हटा दिया गया था। पाइथन का cssselect अभी भी इसे लागू करता है, इसलिए समान क्वेरी पार्सेल में काम करती है। दोनों में समान व्यवहार करने वाले चयनक के लिए, //a[contains(., 'x')] का उपयोग करें।

प्रश्न: क्या CSS चयनकर्ता एक माता-पिता तत्व को चुन सकते हैं?

नहीं। CSS केवल नीचे की ओर चयन करता है, इसलिए कोई parent:: या ancestor:: समकक्ष नहीं है। XPath दोनों को संभालता है, और परीक्षण पृष्ठ पर //h3/ancestor::article ने सभी 20 कार्ड से मेल खाया। :has() उप-क्लास आपको फ़िल्टर करने देती है एक तत्व को इसके वंशजों द्वारा, जो कुछ समान इरादे को कवर करता है, लेकिन यह अभी भी बाहरी तत्व को लौटाती है बजाय इसके कि आंतरिक तत्व से ऊपर चढ़े।

प्रश्न: मेरा चयनक DevTools में क्यों काम करता है लेकिन पायथन में कुछ नहीं लौटाता?

दो सामान्य कारण। पृष्ठ अपनी सामग्री को JavaScript के साथ रेंडर करता है, इसलिए HTML जो आपके HTTP क्लाइंट ने प्राप्त किया उस में कभी भी वे नोड्स नहीं थे जो ब्राउज़र बाद में बनाता है - चयनक सही है और DOM वहाँ नहीं है। या चयनक एक ब्राउज़र-केवल या लाइब्रेरी-केवल विस्तार का उपयोग करता है। चयनक को बदलने से पहले कच्चे प्रतिक्रिया शरीर की तुलना निरीक्षक द्वारा दिखाए गए से करें।

प्रश्न: क्या मुझे Scrapy में CSS या XPath का उपयोग करना चाहिए?

दोनों, प्रति फ़ील्ड। Scrapy response.css() और response.xpath() को समान पार्सेल चयनक पर उजागर करता है, और इन्हें एक साथ चेन किया जा सकता है। सरल वर्ग और विशेषता मेल के लिए CSS का उपयोग करें, और पाठ मिलान या ऊपर की ओर यात्रा के लिए XPath पर स्विच करें बजाय इसके कि एक CSS नियम को फिट करने के लिए मोड़ें।

प्रश्न: क्या XPath चयनकर्ता सभी ब्राउज़रों में काम करते हैं?

हां, document.evaluate के माध्यम से बजाय querySelectorAll के। यह एक अलग DOM इंटरफेस है, और अक्ष पूरी तरह से समर्थित हैं - parent:: और ancestor:: ने ऊपर चलाए गए में प्रत्येक 20 नोड लौटाए। Chrome DevTools में $x() सहायक समान इंटरफेस को कंसोल उपयोग के लिए लपेटता है।