नया हब "क्रोम एक्सटेंशन" (अक्टूबर 2014 से - "ब्राउज़र के लिए एक्सटेंशन")

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

लगातार लेकिन संदिग्ध विकास: विज्ञापन कटर

सबसे पहले, कई साल पहले, 2000-2005 के वर्षों में, उस रूप में कोई ब्राउज़र एक्सटेंशन नहीं थे, जिसमें हम उन्हें अब देखते हैं। ब्राउज़र में लिपियों को साइट के लेखकों और ब्राउज़र में देखे गए पृष्ठ द्वारा स्पष्ट रूप से लिखा गया था। ऐसा लगता है कि इसमें कुछ भी अजीब नहीं है - साइट के लेखकों को ब्राउज़र संसाधनों का उपयोग करने का पूर्ण और अविभाजित अधिकार है ... रोक। एक पत्थर पर एक स्कैथ मिला। पृष्ठ के लेखकों को मेरे ब्राउज़र के संसाधनों का उपयोग क्यों करना चाहिए? अपनी स्वयं की मनमानी स्क्रिप्ट लिखने के लिए जो आपके स्वयं के पृष्ठ की सामग्री को दिखाने की अनुमति नहीं देते हैं? अपने पृष्ठ की सामग्री से खराब शैलियों को विचलित करें? और उस पर विज्ञापन?

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

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

इसके अलावा, यह आवश्यक नहीं है कि जिस भाषा में विज्ञापन आवेषण का पार्सर लिखा गया था वह जावास्क्रिप्ट थी। विज्ञापन अवरोधक भाषा थी और घोषणात्मक और विशिष्ट थी, यह सबसे प्रसिद्ध AdBlock Plus में बनी रही - एक अवरोधक जो ब्राउज़र जावास्क्रिप्ट एक्सटेंशन के युग में पहले से ही बनाई गई थी। उसी समय, अवरोधक प्रोग्राम उदाहरण के लिए, पायथन में एक प्रॉक्सी सर्वर में इनपुट पृष्ठों को पार्स कर सकता है। ब्लॉकर्स का मुख्य उद्देश्य पृष्ठ के हिस्सों में कटौती करना है, सबसे प्रभावी रूप से पृष्ठ के फ्रेम (लेआउट) का उल्लंघन किए बिना, अनावश्यक रूप से तलाश करना।

ब्लॉकर्स और विज्ञापनदाताओं के बीच वर्तमान संबंधों के बारे में अधिक जानकारी के लिए, www.computerworld.com/s/article/9245190/Ad_blockers_A_solution_or_a_problem_ देखें।

कस्टम शैली

पृष्ठ प्रभाव विचारों का एक अन्य वर्ग पृष्ठ संशोधन है। चूंकि सीएसएस नियम प्रदर्शन को काफी हद तक प्रभावित करते हैं, इसलिए अगला विचार आया - अपने उपयोगकर्ता नियमों को कई सीएसएस नियमों में मिलाने के लिए। वैसे, वे आंशिक रूप से अनावश्यक ब्लॉकों को छिपाने पर कार्य कर सकते हैं, हालांकि HTML कटर के रूप में कुशलता से नहीं। लेकिन उनके पास इस तथ्य में एक प्लस है कि 2008-2009 की सीमाओं के आसपास शुरू होने वाले हाल के वर्षों में DOM (पृष्ठ तत्वों की संरचना) को गतिशील रूप से संशोधित करने पर भी शैली के नियम पृष्ठ को प्रभावित करते रहते हैं। इसके अलावा, शैली संशोधक न केवल एक विनाशकारी प्रदर्शन करते हैं, बल्कि एक डिजाइन भूमिका भी निभाते हैं, पृष्ठों की मूल शैली को परिष्कृत या बस बदल सकते हैं। कस्टम शैलियों को सेट करने की क्षमता IE6 ("एक्सेसिबिलिटी - सेटिंग्स में मेरी शैली शीट का उपयोग करके स्वरूपित करें) और विंडोज मोबाइल 2003 (रजिस्ट्री के माध्यम से) में भी पेश की गई थी।

शैली मिश्रण को प्रॉक्सी सर्वर का उपयोग करके HTML में सीएसएस नियमों के समावेश के माध्यम से करना आसान है।

कस्टम स्क्रिप्ट

आप प्रॉक्सी सर्वर को जावास्क्रिप्ट स्क्रिप्ट को साइट पेज में प्रस्तुत करने से रोक सकते हैं, लेकिन आप बाद के परिवर्तनों को DOM (साइट स्क्रिप्ट के अलावा या इसके अलावा हाथ से लिखी गई स्क्रिप्ट की शुरूआत के मामले को छोड़कर) में संशोधित नहीं कर सकते। ब्राउज़रों के विकास के दौरान पृष्ठ स्थान पर स्क्रिप्ट की पहुंच को सुविधाजनक बनाने के लिए, उपयोगकर्ता स्क्रिप्ट का आविष्कार किया गया था। फ़ायरफ़ॉक्स ब्राउज़र Greasemonkey ऐड-ऑन का पहला संस्करण मार्च 2005 में दिखाई दिया और आपको लघु और सरल उपयोगकर्ता स्क्रिप्ट लिखने की अनुमति दी। अधिक सटीक रूप से, ब्राउज़र (इंटरनेट एक्सप्लोरर प्लग-इन, ऐड-ऑन और फ़ायरफ़ॉक्स प्लगइन्स) के व्यवहार को संशोधित करना संभव था, लेकिन संपूर्ण प्रश्न हस्तक्षेप की जटिलता, ब्राउज़रों के नए संस्करणों की उपस्थिति और अन्य के साथ उपयोगकर्ता प्लग-इन की संगतता के साथ हस्तक्षेप विधि का समर्थन था। प्रौद्योगिकियों की सीमा और प्रवेश की सीमा को विधिपूर्वक कम किया गया था ताकि इसकी स्क्रिप्ट की सहायता से साइट पर एक छोटा प्रभाव सरल हो और यह कि ब्राउज़र की विकास प्रक्रिया के साथ, यदि संभव हो तो संघर्ष न करें।

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

उपयोगकर्ता स्क्रिप्ट के खिलाफ परदे के पीछे सहित एक और तर्क विभिन्न ब्राउज़रों के लिए सार्वभौमिकता है। प्रॉक्सी सर्वर के साथ काम करने के लिए किसी भी ब्राउज़र को प्रशिक्षित करना आसान है, लेकिन पहले सभी ब्राउज़रों के पास अपने शस्त्रागार में उपयोगकर्ता स्क्रिप्ट को लागू करने के लिए एक तंत्र नहीं था। दिलचस्प बात यह है कि बहुत जल्द सभी नए ब्राउज़रों ने इसे लागू करने के तंत्र के समान अपना कर्तव्य माना और Greasemonkey फ़ंक्शंस का समर्थन किया, जो IE परिवार के ब्राउज़र को छोड़कर, वास्तविक मानक बन गया, लेकिन उनके पास तृतीय-पक्ष कार्यक्रमों का उपयोग करके उपयोगकर्ता स्क्रिप्ट को लागू करने के तरीके भी थे। यह सच है, IE के लिए एक लंबे समय के लिए IE9 से पहले, जावास्क्रिप्ट स्तर पर DOM के साथ काम करने का एक बहुत अलग तरीका था, जिसने ब्राउज़रों के मुख्यधारा के विकास से इसका अलगाव निर्धारित किया था। IE11 में, ब्राउज़र डेवलपर्स ने इन अंतरों को कम करने की कोशिश की है। लेकिन समस्या प्लेटफार्म (ऑपरेटिंग सिस्टम) तक उपयोगकर्ताओं तक पहुंचने में बनी हुई है। IE11 केवल विंडोज 8 (जून 2013 से) और विंडोज 7 (नवंबर 2013 से) के साथ शुरू या स्थापित किया जा सकता है। वर्चुअल मशीन के उपयोग को छोड़कर अन्य ऑपरेटिंग सिस्टम के उपयोगकर्ता भी इस ब्राउज़र को स्थापित नहीं कर सकते हैं। इसलिए, वितरण नीति द्वारा ब्राउज़र और उपयोगकर्ता स्क्रिप्ट के संभावित उपयोगकर्ताओं की संख्या बहुत सीमित है।

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

अप्रैल 2005 में ओपेरा 8.0 में , फ़ायरफ़ॉक्स के साथ , उपयोगकर्ता स्क्रिप्ट के लिए समर्थन भी दिखाई दिया। इसके विपरीत, ओपेरा में लंबे समय तक कोई ऐड-ऑन नहीं था, और आपको मैन्युअल रूप से स्क्रिप्ट स्थापित करना होगा (एक स्क्रिप्ट के साथ एक फ़ाइल बनाएं) और ब्राउज़र सेटिंग्स के माध्यम से।

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

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

यहां तक ​​कि नीचे चर्चा किए गए ऐड-ऑन भी, जो इंस्टॉलेशन दूरी को 2 क्लिक तक कम करने में सक्षम थे, एक्स्ट्रसियस ऐड-ऑन में उपयोगकर्ता विश्वास की समस्या को हल करने में सक्षम नहीं होंगे और नहीं कर पाएंगे। जब तक कोई भरोसेमंद साइट का मालिक नहीं है, तब तक सभी ऐड-ऑन सीमांत रहेंगे। और अगर कोई भरोसा नहीं है, तो एक अलग मालिक के साथ एक और साइट, जिससे आत्मविश्वास पैदा होता है, इंटरनेट पर किसी को सामूहिक रूप से दान की गई साइट के आधार पर पूरी तरह से "बचत" करने के बजाय दिखाई देगा।

ब्राउज़र ऐडऑन

पृष्ठ स्क्रिप्ट चलाने के बाद चलने वाली उपयोगकर्ता स्क्रिप्ट हमेशा (उनमें से कुछ) उपयोगकर्ताओं को सूट नहीं करती हैं। पेज स्क्रिप्ट कुछ अनावश्यक करने में कामयाब रही, लुक को खराब करती है, एक बैनर के साथ झिलमिलाहट और आमतौर पर इसके निष्पादन पर प्रोसेसर का समय बिताती है। इसलिए, फ़ायरफ़ॉक्स, संस्करण 0.X के साथ शुरू, प्लगइन्स की एक प्रणाली के निर्माण के विचार के लिए एक प्रारंभिक दृष्टिकोण था जो IE प्लगइन्स से लिखना आसान है और फ़ायरफ़ॉक्स के प्लगइन्स की तुलना में स्वयं गायब हो गए हैं। यदि कार्य हमें ब्राउज़र की संपूर्ण संरचना को जानने की तुलना में प्रौद्योगिकियों की एक छोटी श्रृंखला तक सीमित करने की अनुमति देता है, तो इसे XUL तकनीक (XML उपयोगकर्ता इंटरफ़ेस भाषा) पर आधारित ऐड-ऑन (ऐड-ऑन) के निर्माण के ढांचे के भीतर हल किया गया था, विशेष रूप से फ़ायरफ़ॉक्स, जेको इंजन और इसके आधार पर काम करने के लिए बनाया गया था। उत्पादों।

समय के साथ, इस दृष्टिकोण को संशोधित किया गया था, और क्रोम ऐड-ऑन के लिए, जिन्हें "एक्सटेंशन" कहा जाता था, उन्होंने अब एक नई भाषा और तकनीक (सफारी एक्सटेंशन के समान) का आविष्कार नहीं किया। सब कुछ HTML और जावास्क्रिप्ट एपीआई पर बनाया गया है। समय के साथ, क्रोम ऐप्स, क्रोम ओएस में कई समान ऐड-ऑन, एपीआई को आंशिक रूप से ओवरलैप करना आवश्यक था, लेकिन दृष्टिकोण धीमा नहीं दिखता है और एक विशिष्ट प्रवेश सीमा नहीं बनाता है। एक सीमा है, लेकिन यह चौखटे के रूप में अनुप्रयोगों की संरचना द्वारा निर्धारित किया जाता है (उदाहरण के लिए, आपको मैनिफ़ेस्ट का उद्देश्य पता होना चाहिए। फ़ाइल के तत्व) और एपीआई फ़ंक्शन की संख्या।

अंत में

नतीजतन, ब्राउज़रों के चिड़ियाघर को बहुत अधिक विविधता नहीं मिली, जो पहले से ही अच्छा है, ऐड-ऑन, एक्सटेंशन और स्क्रिप्ट का चिड़ियाघर।

* Greasemonkey और Scriptish फ़ायरफ़ॉक्स में - addons.mozilla.org/en-US/firefox
* फ़ायरफ़ॉक्स, क्रोम, ओपेरा और सफारी (NinjaKit के साथ) में उपयोगकर्ता स्क्रिप्ट - userscripts.org
* पुराने ओपेरा के एक्सटेंशन; नया ओपेरा - addons.opera.com/en/extensions
* क्रोम एक्सटेंशन - chrome.google.com/webstore/category/extensions
* क्रोम ऐप्स - chrome.google.com/webstore/category/apps
* सफ़ारी एक्सटेंशन - Extension.apple.com

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

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

उदाहरण के लिए, कई एक्सटेंशन हैं, जिनमें से कुछ विशेष रूप से हब्राह वेबसाइट के लिए बनाए गए थे और पिछले 2 वर्षों में क्रोम पर मुख्य रूप से ध्यान केंद्रित किया गया था।

सिद्धांत:

• Chrome एक्सटेंशन को Rev_version 2 , utf , 21 अगस्त 2012 में अनुवादित करें
  
• Userscripts। हम Chrome , @ MrMig, 14 अक्टूबर, 2011 के लिए एक उपयोगकर्ता स्क्रिप्ट पैक करते हैं
  
• Chrome , ह्यूस्टन , 16 जुलाई, 2013 के विस्तार से जावास्क्रिप्ट वेब पृष्ठों तक पहुँचें
  
• Google Chrome के लिए एक एक्सटेंशन लिखना (और इसे प्रकाशित करना) , paththeir , 26 फरवरी, 2013

हबर के विषय पर:

• Chrome HabraMail एक्सटेंशन (और फ़ेविकॉन विधि) , donnerjack13589 , 24 फरवरी, 2010
  
• Google Chrome Extension Habrahabr.ru-Tools-PATCHED , Goder , 13 अक्टूबर, 2011 (और दो और, लेकिन लेखक केवल-पढ़ने के लिए है)
  
• Google क्रोम एक्सटेंशन: हैम्ब्रैब, बुकिन, 5 मार्च, 2012 से लेख प्रिंट करें
  
• Google Chrome के लिए कर्म एक्सटेंशन , 404 फीट , 23 सितंबर, 2012

अन्य:

• सप्ताहांत में क्रोम विस्तार , ब्रुकवा , 10 जनवरी 2014
  
• Google Chrome के लिए एक्सटेंशन से VKontakte API के साथ काम करना , crea7or , 27 फरवरी, 2013
  
• Google Chrome एक्सटेंशन: हॉट कीज़ बनाना , UZER2006 , 5 मार्च 2013
  
• एक Google Chrome एक्सटेंशन की कहानी , मैमचेस , 26 अक्टूबर, 2013

UPD 10/18/2014: हब का नाम बदलकर "ब्राउज़रों के लिए एक्सटेंशन" कर दिया गया, जैसा कि शुरू में लगभग सुझाया गया था । कुछ महीने एक अच्छी प्रतिक्रिया अवधि है, इसे लगातार कम किया जा रहा है।