वेबड्राइवर बायडी क्या है? द्विदिशात्मक ब्राउज़र स्वचालन

स्क्रेपलेस स्क्रेपिंग ब्राउज़र स्वचालन ग्राहकों के लिए प्रबंधित ब्राउज़र अवसंरचना प्रदान करता है जिनके प्रोटोकॉल और घटना आवश्यकताओं की सेवा के खिलाफ सत्यापन किया गया है।

संक्षेप में

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

वेबड्राइवर बायडी ब्राउज़र नियंत्रण में एक लाइव इवेंट चैनल जोड़ता है

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

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

आदेश, परिणाम, त्रुटियाँ, और घटनाएँ एक वेबSocket साझा करती हैं।

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

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

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

बायडी वेबड्राइवर सत्र या बायडी-केवल पथ के माध्यम से शुरू हो सकता है।

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

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

वेबड्राइवर क्लासिक, वेबड्राइवर बायडी, और सीडीपी विभिन्न लक्ष्यों की सेवा करते हैं।

प्रोटोकॉल ओवरलैप होते हैं, लेकिन उनका परिवहन, घटना मॉडल, मानकीकरण दायरा, और कार्यान्वयन परिपक्वता भिन्न होती है।

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

जहाँ द्विदिशीय घटनाएँ स्वचालन डिज़ाइन को बदलती हैं

BiDi तब महत्वपूर्ण होता है जब ब्राउज़र-उत्पन्न गतिविधि परिणाम या समकालन मॉडल का हिस्सा होती है, न कि आकस्मिक डिबगिंग डेटा।

कांसोल और लॉग अवलोकन

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

नेटवर्क-सचेत स्वचालन

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

संदर्भ जीवनचक्र ट्रैकिंग

ईवेंट टैब, विंडो और फ़्रेम की रिपोर्ट कर सकते हैं क्योंकि ब्राउज़िंग संदर्भ बनाए जाते हैं, नेविगेट होते हैं या नष्ट होते हैं।

स्क्रिप्ट निष्पादन और क्षेत्र

BiDi निर्धारित स्क्रिप्ट क्षेत्रों में कार्यों का मूल्यांकन या कॉल कर सकता है और स्पष्ट निष्पादन दायरे के साथ मान या दूरस्थ संदर्भ लौटा सकता है।

विशिष्टता और कार्यान्वयन अभी भी विकसित हो रहे हैं

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

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

एक WebDriver BiDi अपनाने की चेकलिस्ट

आवश्यक क्षमता के अनुसार BiDi को प्रोटोकॉल लेबल द्वारा अपनाएँ। परीक्षण को अंत से अंत तक परिवहन, आदेश, घटना, संदर्भ और सफाई व्यवहार को साबित करना चाहिए।

आवश्यक मॉड्यूल नाम। सटीक सत्र, ब्राउज़र, ब्राउज़िंग संदर्भ, नेटवर्क, स्क्रिप्ट, लॉग, संग्रहण, इनपुट, या अन्य कमांड और घटनाओं की सूची बनाएं जो कार्यप्रवाह को आवश्यकता है।
स्टार्टअप पथ की पुष्टि करें। क्लाइंट द्वारा वेबSocketUrl का अनुरोध क्लासिक सत्र के माध्यम से किया गया है या एक BiDi-केवल एंडपॉइंट से जुड़ता है, या एक ढांचे को वार्ता प्रबंधित करने देता है यह सत्यापित करें।
परीक्षा सदस्यताएँ। आपके इच्छित आयोजनों की सदस्यता लें और सदस्यता समाप्त करें, उन्हें संबंधित संदर्भों में सीमित करें, और पुष्टि करें कि अप्रासंगिक सत्र हैंडलर में घटनाओं को रिसाव नहीं करते हैं।
नियम: 1. केवल अनुवादित पाठ प्रदान करें - कोई व्याख्या नहीं, कोई अतिरिक्त wrapping कोड बाड़े नहीं। 2. मार्क़डाउन/एचटीएमएल संरचना को बिल्कुल वैसा ही बनाए रखें (शीर्षक, सूचियाँ, लिंक, तालिकाएँ)। 3. किसी भी प्लेसहोल्डर टोकन को जैसे @@CODEBLOCK_0@@ या @@INLINECODE_0@@ को EXACTLY वैसा ही बनाए रखें; कभी भी अनुवाद, पुनर्व्यवस्था, विलय या पुनः प्रारूपित न करें। 4. कोई ``` कोड बाड़े न जोड़ें या न हटाएँ, और सामान्य पाठ को कोड ब्लॉक में लपेटें नहीं। समानांतरता संभालें। मैच परिणामों को कमांड पहचानकर्ताओं से मिलाएं, आदेश पूर्णता की अनुमति दें, और परिभाषित करें कि संदेश डिस्पैच लंबी चलने वाली कमांड के दौरान घटनाओं केarrival पर कैसे व्यवहार करता है।
मॉडल संदर्भ जीवनकाल। टैब, फ़्रेम, उपयोगकर्ता संदर्भ और स्क्रिप्ट क्षेत्र को स्पष्ट रूप से ट्रैक करें ताकि घटनाएँ और दूरस्थ संदर्भ उनके संदर्भ के नष्ट होने के बाद लागू न हों।
बाउंड इवेंट वॉल्यूम। केवल आवश्यक घटना प्रकारों का चयन करें, जल्दी ही फ़िल्टर करें, बफ़रिंग और बैकप्रेशर को परिभाषित करें, और ऐसे पेलोड्स को बनाए रखने से बचें जिनमें असंबंधित व्यक्तिगत या गुप्त डेटा शामिल हो।
नियम: 1. केवल अनुवादित पाठ का आउटपुट करें — कोई व्याख्या नहीं, कोई अतिरिक्त कोड फ़ेंस नहीं। 2. मार्कडाउन/HTML संरचना (शीर्षक, सूची, लिंक, तालिकाएँ) को बिल्कुल सुरक्षित रखें। 3. किसी भी प्लेसहोल्डर टोकन जैसे @@CODEBLOCK_0@@ या @@INLINECODE_0@@ को EXACTLY जैसा है वैसा ही बनाए रखें; कभी भी अनुवाद न करें, न ही पुनर्व्यवस्थित करें, न ही सम्‍मिलित करें, न ही पुनः स्वरूपित करें। 4. कोई ``` कोड फ़ेंस न जोड़ें या न हटाएँ, और सामान्य पाठ को कोड ब्लॉक में लपेटें नहीं। एक समर्थित पथ बनाए रखें। चुनिंदा ब्राउज़र और क्लाइंट से गायब लोड-बेयरिंग फीचर्स के लिए क्लासिक WebDriver या CDP एडेप्टर्स को बनाए रखें, जिनके साथ ऐसे परीक्षण हों जो सीमाओं को दिखाई दे।
पुन: मान्यकरण उन्नयन। जब ब्राउज़र, ड्राइवर, क्लाइंट लाइब्रेरी, दूरस्थ सेवा, या स्पेसिफिकेशन कार्यान्वयन में परिवर्तन होते हैं, तो प्रोटोकॉल स्मोक परीक्षण चलाएं।

WebDriver BiDi और प्रबंधित ब्राउज़र बुनियादी ढांचा

एक प्रबंधित ब्राउज़र सेवा दूरस्थ अंत को होस्ट कर सकती है जबकि ग्राहक एप्लिकेशन कहीं और चल रहा है, लेकिन अंत बिंदु प्रोटोकॉल और समर्थित मॉड्यूल को स्पष्ट रूप से सत्यापित किया जाना चाहिए। Scrapeless Scraping Browser समर्थित स्वचालन ग्राहकों के लिए दूरस्थ ब्राउज़र बुनियादी ढाँचा प्रदान करता है; इसे एक BiDi अंत बिंदु के रूप में वर्णित नहीं किया जाना चाहिए जब तक कि वर्तमान दस्तावेज़ और एक जीवित संगतता परीक्षण उस पथ की पुष्टि नहीं करता।

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

निष्कर्ष: BiDi ब्राउज़र घटनाओं को मानकों के पथ में लाता है

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

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

क्या आप एक दूरस्थ स्वचालन प्रोटोकॉल का परीक्षण करने के लिए तैयार हैं?

एक स्क्रेपलेस खाता बनाएं और इसे स्केल करने से पहले सीमाबद्ध ब्राउज़र कार्यप्रवाह पर समर्थित क्लाइंट कनेक्शन और घटना आवश्यकताओं की पुष्टि करें।

नि:शुल्क आरंभ करें →

पूछे जाने वाले प्रश्न

WebDriver BiDi में BiDi का क्या अर्थ है?

BiDi का अर्थ द्विदिश है। क्लाइंट ब्राउज़र को असिंक्रोनस आदेश भेज सकता है, और ब्राउज़र समान वेब सॉकेट कनेक्शन पर वापस सदस्यता प्राप्त घटनाएँ भेज सकता है। यह क्लासिक WebDriver के मुख्य रूप से क्लाइंट-प्रेरित HTTP आदेश-प्रतिक्रिया मॉडल से भिन्न है।

क्या WebDriver BiDi पूरा हो गया है?

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

क्या WebDriver BiDi क्लासिक WebDriver को बदलता है?

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

क्या WebDriver BiDi और Chrome DevTools प्रोटोकॉल समान हैं?

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

कौन से उपकरण WebDriver BiDi का समर्थन करते हैं?

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