बारह साल लंबी एक छोटी सी परियोजना की कहानी (पहली बार और स्पष्ट रूप से प्रत्यक्ष तौर पर BIRMA.NET के बारे में)

इस परियोजना के जन्म को एक छोटा सा विचार माना जा सकता है जो 2007 के अंत में मेरे पास आया था, जिसका अंतिम रूप केवल 12 साल बाद (इस समय - निश्चित रूप से, हालांकि वर्तमान कार्यान्वयन के अनुसार) मिलना तय था। लेखक के लिए, बहुत संतोषजनक है)।

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

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

उसी समय, मैंने, शायद, पेशेवर सॉफ़्टवेयर डेवलपर्स को प्रशिक्षित करने के लिए पाठ्यक्रम लेने का निर्णय लिया। मुझे नहीं पता कि शुरुआत से "प्रोग्रामर बनना" सीखना वास्तव में संभव है या नहीं, लेकिन उस समय मेरे पास पहले से मौजूद कौशल को ध्यान में रखते हुए, मैं कुछ हद तक उन तकनीकों में महारत हासिल करने में कामयाब रहा जो उस समय पहले से ही अधिक प्रासंगिक थीं, जैसे C# के रूप में, .NET के अंतर्गत विकास के लिए विज़ुअल स्टूडियो, साथ ही जावा, HTML और SQL से संबंधित कुछ प्रौद्योगिकियाँ। पूरे प्रशिक्षण में कुल दो साल लगे, और यह मेरे एक अन्य प्रोजेक्ट के लिए शुरुआती बिंदु के रूप में काम किया, जो अंततः कई वर्षों तक चला - लेकिन यह एक अलग प्रकाशन का विषय है। यहां केवल यह नोट करना उचित होगा कि मैंने C# और WinForms में एक पूर्ण विंडो एप्लिकेशन बनाने के लिए वर्णित प्रोजेक्ट पर पहले से मौजूद विकास को अनुकूलित करने का प्रयास किया है जो आवश्यक कार्यक्षमता को कार्यान्वित करता है, और इसे आधार के रूप में उपयोग करता है आगामी डिप्लोमा परियोजना.
समय के साथ, यह विचार मुझे "LIBKOM" और "CRIMEA" जैसे विभिन्न पुस्तकालयों के प्रतिनिधियों की भागीदारी के साथ ऐसे वार्षिक सम्मेलनों में आवाज उठाने के योग्य लगने लगा। विचार, हाँ, लेकिन उस समय मेरा कार्यान्वयन नहीं। तब मुझे यह भी आशा थी कि कोई अधिक सक्षम दृष्टिकोण का उपयोग करके इसे फिर से लिखेगा। किसी न किसी तरह, 2013 तक मैंने अपने प्रारंभिक कार्य पर एक रिपोर्ट लिखने और सम्मेलन में भाग लेने के लिए अनुदान के आवेदन के साथ इसे सम्मेलन आयोजन समिति को भेजने का निर्णय लिया। मुझे कुछ हद तक आश्चर्य हुआ, जब मेरा आवेदन स्वीकृत हो गया, और मैंने सम्मेलन में प्रस्तुति के लिए इसे तैयार करने के लिए परियोजना में कुछ सुधार करना शुरू कर दिया।

उस समय तक, परियोजना को पहले से ही एक नया नाम BIRMA प्राप्त हो चुका था, विभिन्न अतिरिक्त (पूरी तरह से कार्यान्वित नहीं, बल्कि अनुमानित) क्षमताओं का अधिग्रहण किया गया था - सभी विवरण मेरी रिपोर्ट में पाए जा सकते हैं.

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

सामान्य तौर पर, अपने स्वयं के पार्सर के साथ संघर्ष करने के अलावा, मेरे पास इस संस्करण के कोड के संबंध में कहने के लिए और कुछ नहीं है - .NET कोड की कुछ विशिष्ट विशेषताओं को संरक्षित करते हुए मौजूदा स्रोतों को C++ में रिवर्स रूपांतरण के अलावा (ईमानदारी से कहूं तो, यह है) समझना मुश्किल है, आख़िर किस चीज़ ने मुझे सब कुछ वापस ले जाने के लिए प्रेरित किया - शायद मेरे स्रोत कोड को गुप्त रखने का कोई मूर्खतापूर्ण डर, जैसे कि यह कोका-कोला की गुप्त रेसिपी के बराबर कुछ हो)।

शायद यह मूर्खतापूर्ण निर्णय इलेक्ट्रॉनिक कैटलॉग में डेटा दर्ज करने के लिए घर-निर्मित वर्कस्टेशन के मौजूदा इंटरफ़ेस के साथ परिणामी डीएलएल लाइब्रेरी को जोड़ने में कठिनाइयों का कारण भी है (हां, मैंने एक और महत्वपूर्ण तथ्य का उल्लेख नहीं किया है: अब से, सभी) BIRMA "इंजन" का कोड अपेक्षा के अनुरूप था, इसे इंटरफ़ेस भाग से अलग किया गया है और उपयुक्त DLL में पैक किया गया है)। इन उद्देश्यों के लिए एक अलग वर्कस्टेशन लिखना क्यों आवश्यक था, जो वैसे भी, अपनी उपस्थिति और उपयोगकर्ता के साथ बातचीत के तरीके में, बेशर्मी से IRBIS 64 सिस्टम के उसी वर्कस्टेशन "कैटलॉगाइज़र" की नकल करता था - यह एक अलग प्रश्न है। संक्षेप में: इसने मेरे स्नातक प्रोजेक्ट के लिए मेरे तत्कालीन विकास को आवश्यक दृढ़ता प्रदान की (अन्यथा अकेले अपचनीय पार्सर इंजन किसी तरह पर्याप्त नहीं था)। इसके अलावा, मुझे C++ और C# दोनों में लागू अपने स्वयं के मॉड्यूल के साथ कैटलॉग वर्कस्टेशन के इंटरफ़ेस को लागू करने और सीधे अपने इंजन तक पहुंचने में कुछ कठिनाइयों का सामना करना पड़ा।

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

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

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

एक और समस्या यह थी कि परियोजना स्वयं जावा में लागू की गई थी, और अगर मैंने भविष्य में मौजूदा डेटाबेस (जैसे इरबिस के "कैटलॉगर") में डेटा दर्ज करने के लिए परिचित अनुप्रयोगों के साथ इस तकनीक को इंटरफेस करने के कुछ माध्यमों को लागू करने की योजना बनाई है, तो कम से कम इसे C# और .NET में करें। ऐसा नहीं है कि जावा स्वयं एक खराब भाषा है - मैंने एक बार इसका उपयोग एक दिलचस्प विंडो एप्लिकेशन को लागू करने के लिए भी किया था जिसने घरेलू प्रोग्रामयोग्य कैलकुलेटर की कार्यक्षमता को लागू किया था (एक कोर्स प्रोजेक्ट के हिस्से के रूप में)। और वाक्यविन्यास के संदर्भ में यह उसी सी-शार्प के समान है। खैर, यह केवल एक प्लस है: मेरे लिए किसी मौजूदा प्रोजेक्ट को अंतिम रूप देना उतना ही आसान होगा। हालाँकि, मैं विंडो (या बल्कि, डेस्कटॉप) जावा प्रौद्योगिकियों की इस असामान्य दुनिया में फिर से उतरना नहीं चाहता था - आखिरकार, भाषा स्वयं इस तरह के उपयोग के लिए "अनुरूप" नहीं थी, और मुझे इसकी पुनरावृत्ति की बिल्कुल भी इच्छा नहीं थी पिछला अनुभव. शायद यह ठीक इसलिए है क्योंकि WinForms के साथ संयोजन में C# डेल्फ़ी के बहुत करीब है, जिसके साथ हम में से कई लोगों ने एक बार शुरुआत की थी। सौभाग्य से, आवश्यक समाधान बहुत जल्दी मिल गया - परियोजना के रूप में आईकेवीएम.नेट, जो मौजूदा जावा प्रोग्राम को प्रबंधित .NET कोड में अनुवाद करना आसान बनाता है। सच है, उस समय तक इस परियोजना को लेखकों द्वारा पहले ही छोड़ दिया गया था, लेकिन इसके नवीनतम कार्यान्वयन ने मुझे स्रोत ग्रंथों के लिए आवश्यक कार्यों को सफलतापूर्वक पूरा करने की अनुमति दी। गोर्पो.

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

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

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

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

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

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

वैसे, इस गर्मी में मुझे पहले से ही एक कंपनी से ईमेल द्वारा निमंत्रण मिला है जो सेल्सफोर्स प्रौद्योगिकियों (मूल के डेवलपर) का उपयोग करती है गोर्पो), रीगा में बाद के काम के लिए एक साक्षात्कार पास करें। दुर्भाग्य से, फिलहाल मैं ऐसी पुनर्तैनाती के लिए तैयार नहीं हूं।

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

स्रोत: www.habr.com