मीडियाविकि पार्सर कैसे काम करता है

मीडियाविकि पार्सर का अनुवाद , खुला ।

   2009   , , -,        ,  -,      ,     Mediawiki,      . 

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

संक्षिप्त इतिहास

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

क्या करें?

इस समस्या को हल करने के बारे में बहुत चर्चा हुई। किसी ने सी में पार्सर को फिर से लिखने का सुझाव दिया, जो पार्सर को तेज कर देगा, जो पार्सर को पाठ को एक पास में नहीं करने की अनुमति देगा, लेकिन लूप में - यह विकिपीडिया पृष्ठों में शामिल किए गए टेम्प्लेट और सबपैटर्न की बढ़ती संख्या की आवश्यकता थी। मीडियाविकि के वाक्य-विन्यास को बदलने के प्रस्ताव भी थे ताकि कुछ निर्माणों के विश्लेषण में अस्पष्टता को समाप्त किया जा सके (उदाहरण के लिए, `` '' '' बोल्ड या इटैलिक? '' बोल्ड या इटैलिक? '' '' '' या ट्रिपल और डबल घुंघराले ब्रेसिज़ के बीच संबंध? टेम्पलेट्स)।
अंत में, यह तय किया गया था, और मैं इसे एक शानदार विचार मानता हूं, PHP में पार्सर को छोड़ने के लिए (क्योंकि सी में इसे फिर से लिखना Mediawiki डेवलपर्स को 2 वर्गों में विभाजित करेगा) और पार्सिंग को दो चरणों में विभाजित करता है, प्रीप्रोसेसिंग और पार्सिंग । प्रीप्रोसेसर की नौकरी एक XML डोम के रूप में विकिटेक्स का प्रतिनिधित्व करने के लिए थी। अपने आप को पार्स करने के चरण में, DOM ट्री को वैध स्टेटिक HTML प्राप्त करने के लिए आवश्यक (उदाहरण के लिए, टेम्प्लेट करने के लिए टेम्प्लेट) के रूप में कई पुनरावृत्तियों के एक चक्र में संसाधित किया गया था। DOM के माध्यम से लूपिंग अविश्वसनीय रूप से तेज़ है, और यह XHTML के दृष्टिकोण से बहुत स्वाभाविक भी है। और PHP में, इस तरह के प्रसंस्करण भी बहुत अच्छी तरह से समर्थित है।

पूर्वप्रक्रमक

Mediawiki स्रोत फ़ोल्डर में आपको प्रीप्रोसेसर के दो संस्करण मिलेंगे, Hash और DOM का एक संस्करण, जो क्रमशः /includes/parser/Preprocessor_Hash.php और /includes_parser/Preprocessor_DOM.php पर पाया जा सकता है।
हम DOM संस्करण पर ध्यान केंद्रित करेंगे, क्योंकि यह हैश संस्करण के लगभग समान है, लेकिन यह तेजी से काम करता है क्योंकि यह PHP XML समर्थन, एक वैकल्पिक PHP घटक का उपयोग करता है। प्रीप्रोसेसर क्लास में सबसे महत्वपूर्ण फ़ंक्शन को प्रीप्रोसेसटॉबज () कहा जाता है। Preprocessor_DOM.php फ़ाइल के अंदर, कई अन्य महत्वपूर्ण वर्ग हैं जो प्रीप्रोसेसर उपयोग करता है: PPDStack, PPDStackElement, PPDPart, PPFrame_DOM, और PPNodexDOM।

प्रीप्रोसेसर आपके विचार से कम करता है

तो क्या Mediawiki XML पसंद है? यहाँ एक उदाहरण है कि कैसे wikitext "{{MySpattern}} यह [[परीक्षण]]" XML में दिखता है:

 <root> <template> <title>mytemplate</title> </template> this is a [[test]] </root> 

नोट। आंतरिक लिंक को संसाधित नहीं किया गया है। प्रीप्रोसेसर कोड उस कार्य से बच जाता है जो बाद के चरण में किया जा सकता है (और इसका एक कारण है), इसलिए प्रीप्रोसेसर का एकमात्र वास्तविक कार्य टेम्पलेट के लिए XML तत्व और कुछ अन्य चीजों को बनाना है। ये चीजें, यानी। आधार नोड्स (पूरी सूची): टेम्पलेट, tplarg, टिप्पणी, ext, अनदेखा, ज।

यदि आपने कभी विकिटेक्स के साथ काम किया है, तो आप पहले से ही जानते हैं कि कौन सा मार्कअप इन मूल नोड्स से मेल खाता है। बस मामले में, यहाँ यह है:

• टेम्पलेट = डबल घुंघराले ब्रेसिज़ {{...}}
• tplarg = ट्रिपल कर्ली ब्रेसेस {{{...}}}
• टिप्पणी = HTML किसी भी प्रकार की टिप्पणी
• ext = वह सब कुछ जिसे एक अलग विस्तार में समझने की आवश्यकता है
• अनदेखा करना = नोंक-झोंक टैग, साथ ही उनके अंदर समाहित टैग और सामग्री
• ज = खंड

वह सब है। बाकी सब कुछ नजरअंदाज कर दिया जाता है और मूल वाइकरटेक्स के रूप में पार्सर के पास लौट जाता है।

प्रीप्रोसेसर काम कैसे करता है?

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

खुद को पार्स कर रहा है

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

यहाँ पृष्ठ के वर्तमान संस्करण के लिए एक सामान्य पार्सर कॉल ट्री है, जो आर्टिकल ऑब्जेक्ट से शुरू होता है।

01. अनुच्छेद-> दृश्य

02. - आर्टिकल-> getContent

03. ---- लेख-> लोडकंटेंट

04. ------ अनुच्छेद-> fetContent-> रिटर्न डेटाबेस से पुनर्प्राप्त विकिटेक्स

05. - आर्टिकल-> outputWikiText-> पार्स के लिए तैयार करें

06. ---- पार्सर-> पार्स

07. ------ पार्सर-> आंतरिकपार्ष

08. -------- पार्सर-> प्रतिस्थापन

09. ---------- पार्सर-> preprocessToDom

10. ------------ Preprocessor-> preprocessToObj

11. ---------- फ़्रेम-> विस्तार

12. -------- पार्सर-> doTableStuff

13. -------- पार्सर-> प्रतिस्थापनइंटरलिंक

14.------ पार्सर-> प्रतिस्थापन बाह्यलिंक

15. ------ पार्सर-> doBlockLevels

16. ------ पार्सर-> प्रतिस्थापनलिंकर्स

आइए एक नजर डालते हैं इन फीचर्स पर। फिर, ये मुख्य कार्य हैं, और इस उदाहरण में नहीं कहा जाता है। आइटम 2-4 डेटाबेस से लेख के विकिटेक्स को पुनः प्राप्त और वापस करते हैं। यह पाठ आउटपुटविकीटैक्स्ट ऑब्जेक्ट को दिया जाता है, जो इसे पार्सर :: पार्स () फ़ंक्शन को पास करने के लिए तैयार करता है।
फिर 8-11 अंक पर फिर से दिलचस्प हो जाता है। रिप्लेवेरिएबल्स फ़ंक्शन के अंदर, टेक्स्ट डोम प्रतिनिधित्व में बदल जाता है, लेख में प्रत्येक वर्ण के लिए एक लूप में, टेम्प्लेट, सबपैटर्न और अन्य नोड्स की शुरुआत और अंत लेबल के लिए खोज की जाती है।

बिंदु संख्या 11 एक दिलचस्प कदम है जिसे मैं अभी छोड़ दूंगा क्योंकि इसके लिए Preprocessor_DOM.php फ़ाइल (ऊपर वर्णित) से अन्य वर्गों के कुछ ज्ञान की आवश्यकता है। विस्तार एक बहुत ही महत्वपूर्ण कार्य है, यह चीजों का एक गुच्छा (इसकी पुनरावर्ती कॉल सहित) करता है, लेकिन यह कहने के लिए पर्याप्त है कि यह वास्तव में DOM नोड्स से पाठ निकालने का काम करता है (हमें याद है कि टेम्पलेट्स को नेस्ट किया जा सकता है - इसलिए आपको हमेशा पूर्ण पाठ नहीं मिलेगा प्रत्येक शामिल लेख से) और उलटा वैध HTML पाठ, जो तीन प्रकारों के अपवादों के साथ सभी विकि टैग्स को प्रकट करता है: टेबल, लिंक और सूचियाँ। तो, ऊपर दिए गए उदाहरण में, "{{MyTemplate}} यह [[परीक्षण]]" विस्तार () फॉर्म का पाठ लौटा देगा:

"मैंने अपने खाके से [[पाठ]] शामिल किया है, यह [[परीक्षण]]" है

जैसा कि आप इस सरल उदाहरण से देख सकते हैं, टेबल, लिंक और सूचियों के अपवाद के साथ, इस चरण में सब कुछ हल हो गया है।

लिंक एक विशेष मामला है

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

"मैंने अपने टेम्पलेट से <! - लिंक 0 -> को शामिल किया है, यह <! - लिंक 1 -> है।"

जैसा कि आप कल्पना कर सकते हैं, एक ऐसा सरणी भी है जो लिंक के पाठ से मेल खाता है लिंक #ID के आईडी के रूप में, यह Parser वर्ग का एक चर है जिसका नाम mLinkHolders है। मिलान के अलावा, यह चर प्रत्येक लिंक के लिए शीर्षक ऑब्जेक्ट भी संग्रहीत करता है।

तो पार्सिंग लिंक के दूसरे चरण में, हम इस सरणी का उपयोग आसान खोज और प्रतिस्थापन के लिए करते हैं। अब सब कुछ! हम तैयार पाठ को दरवाजे से बाहर भेजते हैं!

अगला चरण

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