स्क्रैपी क्या है?

स्क्रैपलेस यूनिवर्सल स्क्रैपिंग एपीआई स्क्रैपी वर्कफ़्लो के लिए अधिग्रहण स्रोत के रूप में काम कर सकता है जिसे फ़ेच या रेंडर की गई सामग्री की आवश्यकता होती है।

स्क्रैपी एक क्रॉलिंग फ्रेमवर्क है

स्क्रैपी एक ओपन-सोर्स पाइथन फ्रेमवर्क है जो पृष्ठों को पुनः प्राप्त करने, संरचित क्षेत्रों को निकालने, लिंक का पालन करने, आइटम को संसाधित करने, और परिणामों को निर्यात करने के लिए है। यह एक HTML पार्सर की तुलना में बड़ा है और HTTP क्लाइंट के चारों ओर लूप से अधिक संगठित है। ढाँचा तब उपयोगी हो जाता है जब एक परियोजना में कई पृष्ठों, निरंतरता नियमों, साझा अनुरोध नीति, पुन: प्रयोज्य आइटम तर्क, या निर्धारित रन होते हैं।

द आधिकारिक स्क्रैपी दस्तावेज़ीकरण मकड़ियों, चयनकों, अनुरोधों और प्रतिक्रियाओं, आइटम पाइपलाइनों, फीड निर्यात, मिडलवेयर, एक्सटेंशन, शेड्यूलिंग और तैनाती प्रथाओं का वर्णन करता है। एक परियोजना पहले केवल एक छोटे उपसंपत्ति का उपयोग कर सकती है और जब दोहराए गए तर्क प्रकट होते हैं तो घटकों को जोड़ सकती है।

एक अच्छा स्क्रैपी प्रोजेक्ट स्रोत ज्ञान को मकड़ी में रखता है और पुन: प्रयोज्य नीति को अन्यत्र। मकड़ी जानती है कि किस पृष्ठ से शुरू होना है और उन्हें कैसे समझना है। डाउनलोडर मिडलवेयर क्रॉस-कटिंग अनुरोध और प्रतिक्रिया व्यवहार को संभालता है। आइटम पाइपलाइन आउटपुट को साफ करती है, मान्य करती है, डुप्लिकेट को हटाती है या संग्रहीत करती है।

स्क्रैपी डेटा सिस्टम के माध्यम से कैसे चलता है

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

सीमाएं प्रत्येक मकड़ी को परिवहन, डुप्लिकेट हटाने, और आउटपुट को फिर से आविष्कार करने से रोकती हैं। वे विफलताओं को स्थान पाए जाने में भी आसान बनाते हैं। एक डाउनलोड समस्या मकड़ी कॉलबैक से पहले आती है। एक गायब शीर्षक पार्सिंग या मान्यता में आता है। एक डेटाबेस त्रुटि उस आइटम के बाद आती है जो पहले से ही संरचित है।

स्क्रैपी मकड़ी क्या करती है

एक मकड़ी एक पाइथन वर्ग है जो यह परिभाषित करता है कि कौन से अनुरोध भेजने हैं और उनकी प्रतिक्रियाओं को कैसे संसाधित करना है। आधिकारिक मकड़ी गाइड यह अनुरोध-और-कॉल्बैक चक्र को समझा रहा है: प्रारंभिक अनुरोध डाउनलोड होते हैं, कॉल्बैक प्रतिक्रियाओं को पार्स करते हैं, और कॉल्बैक आइटम या अधिक अनुरोध प्रदान करते हैं।

निम्नलिखित ब्लॉक एक स्थानीय-रनटाइम पूर्वापेक्षा है क्योंकि वर्तमान कार्यक्षेत्र में Scrapy स्थापित नहीं है। इसकी संरचना दस्तावेज़ीकृत स्पाइडर एपीआई का पालन करती है। इसे एक समर्पित वातावरण में चलाएँ और एक सार्वजनिक लक्षित का उपयोग करें जिसके शर्तें संग्रह की अनुमति देती हैं।

import scrapy

class ExampleSpider(scrapy.Spider):
    name = "example_page"
    allowed_domains = ["example.com"]
    start_urls = ["https://example.com/"]

    def parse(self, response):
        title = response.css("h1::text").get()
        href = response.css("a::attr(href)").get()

        if not title or not href:
            raise ValueError("expected page identity is missing")

        yield {
            "title": title.strip(),
            "url": response.urljoin(href),
            "source_url": response.url,
        }

जाल का कीड़ा अपना पहचान क्षेत्र को मान्य करता है इससे पहले कि वह उत्पन्न करे। response.urljoin लिंक को वास्तविक प्रतिक्रिया URL के खिलाफ हल करता है। एक कैटलॉग पर, कॉलबैक को रिकॉर्ड कंटेनरों पर लूप करना चाहिए और प्रत्येक कंटेनर के सापेक्ष चाइल्ड सेलेक्टर्स को चलाना चाहिए।

चुनने वाले, वस्तुएं, और पाइपलाइनों के अलग-अलग कार्य हैं

Selectors एक प्रतिक्रिया से फ़ील्ड पढ़ते हैं। आइटम या साधारण शब्दकोश निकाले गए डेटा का प्रतिनिधित्व करते हैं। पाइपलाइनों का संचालन निकासी के बाद होता है। उन कार्यों को अलग रखना एक प्रोजेक्ट को संग्रहित प्रतिक्रियाओं के खिलाफ सेलेक्टर्स का परीक्षण करने और साधारण पायथन मूल्यों के साथ नॉर्मलाइजेशन का परीक्षण करने की अनुमति देता है।

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

• मकड़ियाँ पृष्ठ-विशिष्ट ज्ञान रखती हैं। नियम: 1. केवल अनूदित पाठ आउटपुट करें - कोई व्याख्या नहीं, कोई अतिरिक्त रैपिंग कोड फेंस नहीं। 2. मार्कडाउन/एचटीएमएल संरचना (शीर्षक, सूचियाँ, लिंक, तालिकाएँ) को सटीकता से बनाए रखें। 3. किसी भी प्लेसहोल्डर टोकन जैसे @@CODEBLOCK_0@@ या @@INLINECODE_0@@ को बिलकुल वैसा ही रखें; कभी भी अनुवादित, पुनर्व्यवस्थित, विलय या फॉर्मेट न करें। 4. कोई भी ``` कोड फेंस जोड़ें या हटा न करें, और सामान्य पाठ को कोड ब्लॉक में लपेटें नहीं।
• मिडलवेयर पुनरावृत्त परिवहन व्यवहार का मालिक है। सच्चे तरीके से साझा की गई नीति के तहत केवल उन मकड़ियों पर लागू करें।
• पाइपलाइनों का अपना रेकॉर्ड नीति। निष्कर्ष निकालें, सामान्य करें, डुप्लिकेट हटाएं, और निकासी के बाद बनाए रखें।
• फीड निर्यात साधारण भंडारण को कवर करते हैं। बिना स्पष्ट आवश्यकता के कस्टम स्थायी परत लिखने से पहले अंतर्निर्मित JSON या CSV आउटपुट का उपयोग करें।

जानें कब स्क्रैपी सही आकार में है

जब नौकरी में कई पृष्ठ, कई मकड़ियाँ, साझा नीति, पाइपलाइन, अवलोकन, या पुनरावृत्त निष्पादन होते हैं, तो Scrapy अपनी संरचना अर्जित करता है। एक-पृष्ठ निष्कर्षण को Requests और एक पार्सर के रूप में स्पष्ट रूप से देखा जा सकता है। छोटे से शुरू करना कोई असफलता नहीं है; जब समन्वय प्रबल समस्या बन जाता है तो ढांचे में जाना उपयोगी होता है।

Scrapy डिफ़ॉल्ट रूप से एक ब्राउज़र नहीं है। यदि आवश्यक मान प्रतिक्रिया के शरीर से गायब हैं और केवल पृष्ठ स्क्रिप्ट चलने के बाद प्रकट होते हैं, तो चयनकर्ता उनका पुनः प्राप्त नहीं कर सकते। एक डाउनलोडर एकीकरण का उपयोग करें जो प्रतिष्ठित HTML लौटाता है, एक अधिकृत संरचित स्रोत, या एक ब्राउज़र कार्यप्रवाह जब बातचीत कार्य का हिस्सा हो।

क्रॉल स्कोप और निरंतरता नियंत्रित करें

allowed_domains एक उपयोगी गार्ड है, लेकिन परियोजना के दायरे को अनुमत योजनाओं, पथ पैटर्न, प्रश्न व्यवहार, और पृष्ठ बजट को भी परिभाषित करना चाहिए। डेटुप्लिकेशन से पहले URL को सामान्यीकृत करें ताकि ट्रैकिंग पैरामीटर और वैकल्पिक रूपों से कतार में वृद्धि न हो।

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

निर्यात और क्रॉल का अवलोकन

फीड निर्यात मानक प्रारूपों में आइटम आउटपुट लिखने का सबसे सरल तरीका है। एक पाइपलाइन उपयुक्त है जब रिकॉर्ड को मान्यकरण, डिडुप्लिकेशन, डेटाबेस लेखन, या स्रोत-विशिष्ट रूपांतरण की आवश्यकता होती है। अस्वीकार किए गए आइटम के कारण और नेटवर्क डायग्नोस्टिक्स को व्यावसायिक रिकॉर्ड से अलग रखें।

अनुरोधों, प्रतिक्रिया कक्षाओं, पृष्ठ पहचान विफलों, चयनकर्ता चूक, उत्पन्न किए गए आइटम, अस्वीकृत आइटम और कतार की गहराई को ट्रैक करें। HTTP अर्थशास्त्र विनिर्देशन प्रतिक्रिया स्थिति को स्पष्ट करता है, लेकिन पृष्ठ पहचान जांच आवश्यक रहती है क्योंकि एक सफल प्रतिक्रिया अभी भी एक अप्रासंगिक दस्तावेज़ हो सकती है।

साझा नीति के लिए केवल मिडलवेयर और एक्सटेंशन्स जोड़ें

Downloader मिडलवेयर तब उपयुक्त होता है जब कई मकड़ियों को समान अनुरोध या प्रतिक्रिया व्यवहार की आवश्यकता होती है। मकड़ी मिडलवेयर मकड़ी के इनपुट और आउटपुट के चारों ओर होता है। एक्सटेंशन ढांचे के संकेतों की निगरानी करते हैं और मेट्रिक्स या संचालन सीमाओं जैसे क्रॉस-प्रोजेक्ट व्यवहार को लागू करते हैं। एक बार का चयनकर्ता सुधार इन वैश्विक परतों में से किसी में भी नहीं होता है।

स्पाइडर के छोटे से घटक के साथ शुरू करें जो नियम का स्वामित्व रखते हैं। यदि एक स्पाइडर को एक शीर्षक या एक पार्स शाखा की आवश्यकता है, तो उसे वहीं रखें जब तक कि व्यवहार दोहराया न जाए और दूसरे स्थान पर समान अर्थ न हो। पूर्व-निर्धारण वैश्विक हुक एक प्रोजेक्ट को समझने में और कठिन बनाते हैं क्योंकि अनुरोध उस स्पाइडर से दूर बदल सकता है जिसने इसे बनाया था।

डॉक्यूमेंट ऑर्डरिंग जब कई मिडलवेयर क्लासेस सक्षम होती हैं। प्रत्येक हुक को एक जिम्मेदारी होनी चाहिए और अगले चरण की उम्मीद करने वाले फ्रेमवर्क प्रकार को वापस करना चाहिए। परीक्षणों को घटक सीमा पर अनुरोध या प्रतिक्रिया का आश्वासन देना चाहिए, केवल अंतिम निर्यातित पंक्ति नहीं।

वस्तु प्रसंस्करण के माध्यम से उत्पत्ति को बनाए रखें

एक आइटम को पाइपलाइन में प्रवेश करने से पहले इसके कैननिकल स्रोत यूआरएल और एक स्थिर स्रोत पहचानकर्ता को ले जाना चाहिए। पाइपलाइन अधिग्रहण समय, पार्सर संशोधन और बैच पहचान को जोड़ सकती है, फिर विशिष्टता या भंडारण नीति को लागू करती है। उन फ़ील्ड्स से आगे के उपयोगकर्ताओं को एक वास्तविक स्रोत परिवर्तन को एक स्पाइडर तैनाती से अलग करने की अनुमति मिलती है।

नियम: 1. केवल अनुवादित पाठ आउटपुट करें - कोई व्याख्या नहीं, कोई अतिरिक्त रैपिंग कोड फ़ेंस नहीं। 2. Markdown/HTML संरचना को ठीक से बनाए रखें (शीर्षक, सूचियाँ, लिंक, तालिकाएँ) बिल्कुल वैसे ही। 3. किसी भी स्थान धारक टोकन जैसे @@CODEBLOCK_0@@ या @@INLINECODE_0@@ को बिल्कुल वैसा ही बनाए रखें; कभी भी अनुवादित, पुनर्व्यवस्थित, मर्ज या फ़ॉर्मेट न करें। 4. सामान्यीकरण करने पर अर्थ खोने पर कच्चे मान बनाए रखें। मुद्रा, स्थानीयकृत संख्या, मानव दिनांक और उपलब्धता लेबल के लिए संदर्भ-सचेत रूपांतरण की आवश्यकता है। सामान्यीकृत मान को पर्याप्त मूल संदर्भ के बगल में संग्रहीत करें ताकि निर्णय का ऑडिट किया जा सके, और ऐसे संयोजनों को अस्वीकृत करें जो घोषित स्कीमा का उल्लंघन करते हैं।

निष्कर्ष

Scrapy एक ढांचा है जो एक क्रॉलर का समन्वय करने के लिए है, न कि केवल एक पार्सर। इसका इंजन, शेड्यूलर, डाउनलोडर, मिडलवेयर, मकड़ियाँ, पाइपलाइंस, और निर्यात प्रत्येक चिंता को एक स्पष्ट घर देते हैं। जब कतार बनाने और पुनरावृत्ति महत्वपूर्ण हो, तो उस संरचना का उपयोग करें, पृष्ठ-विशिष्ट चयनकर्ताओं को मकड़ियों में रखें, आइटम प्रदान करने से पहले पहचान को मान्य करें, और केवल तभी प्रकट अधिग्रहण जोड़ें जब स्रोत की आवश्यकता हो।