नियमित अभिव्यक्ति खोज

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



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



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







उसी समय, एक संपादक की कल्पना करना मुश्किल है जो पाठ खोज प्रदान नहीं करता है। बेशक, प्रत्येक संपादक नियमित अभिव्यक्तियों द्वारा सबस्ट्रिंग की खोज करने का अवसर प्रदान नहीं करता है, लेकिन "सामान्य व्यक्ति जो सामान्य बनने का सपना नहीं देखता है, वह बुरा है", इसलिए हमने एमएस वर्ड जैसे अधिक "उन्नत" उत्पादों पर ध्यान केंद्रित किया।



एक नियमित अभिव्यक्ति खोज एल्गोरिथ्म को लागू करने में डिबगिंग और परीक्षण सहित बहुत समय लगेगा। पहिया को सुदृढ़ नहीं करने के लिए, हमने .NET फ्रेमवर्क में उपलब्ध कार्यान्वयन का लाभ उठाने का निर्णय लिया।



उसी समय, मुख्य कठिनाई यह थी कि XtraRichEdit (साथ ही अधिकांश पाठ संपादकों) में दस्तावेज़ की सामग्री को न केवल एक स्ट्रिंग द्वारा दर्शाया जाता है, बल्कि एक एकल स्वरूपण के साथ पाठ के टुकड़ों का प्रतिनिधित्व करने वाली वस्तुओं के संग्रह द्वारा भी।



और .NET RegEx एक स्ट्रिंग और केवल एक स्ट्रिंग इनपुट के रूप में स्वीकार करता है (जो मुझे मेरे लिए IEnumerable <char> जैसा कुछ करने से रोकता है, यह अभी भी एक रहस्य है। नतीजतन, स्ट्रीम में नियमित अभिव्यक्ति द्वारा खोज करना भी सिरदर्द बन जाता है)।



लेकिन दस्तावेज़ की सामग्री को एक स्ट्रिंग के रूप में प्राप्त करने के बाद भी (जो कि बहुत मुश्किल नहीं है), परिणामी खोज परिणाम को दस्तावेज़ मॉडल की स्थिति में बदलना मुश्किल है। यह छिपे हुए पात्रों और पाठ के दस्तावेज़ में मौजूद होने के कारण है जो प्रदर्शित नहीं हो सकते हैं, लेकिन दस्तावेज़ की सामान्य संरचना में प्रतिनिधित्व किया जा सकता है।



हालाँकि, हमें एक रास्ता मिल गया। मुख्य विचार निम्नानुसार था: दस्तावेज़ का एक टुकड़ा बफर में निकाला जाता है और एक स्ट्रिंग (छवि 1) के रूप में संग्रहीत किया जाता है। जब एक दस्तावेज़ के एक छोटे से टुकड़े से निपटना और निरपेक्ष मूल्य में खोज की शुरुआत के सापेक्ष बफर के ऑफसेट को जानना (छिपे हुए पाठ को ध्यान में रखना), तो पाया गया विकल्प की स्थिति निर्धारित करना मुश्किल नहीं है।



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





अंजीर। 1।





अंजीर। 2।



बफर और ऑफसेट का आकार खोज परिणाम की संभावित लंबाई पर निर्भर करता है, यानी, सबसे बड़े परिणाम की अधिकतम लंबाई बफर की लंबाई से अधिक नहीं होनी चाहिए। पाया गया मैच निम्नलिखित मामलों में मांगा गया है:

1. परिणाम बफर की शुरुआत में निहित है, बशर्ते कि खोज की शुरुआत के सापेक्ष बफर स्थिति की ऑफसेट शून्य है
2. परिणाम बफर के बीच में है।

एक नॉनज़रो ऑफ़सेट इंगित करता है कि परिणाम बफर की पिछली स्थिति में नहीं मिला था, इसलिए, बफर की शुरुआत में परिणाम ऑफसेट (छवि 3) पर खोज स्ट्रिंग को ट्रिम करके प्राप्त किया गया था।





अंजीर। 3।



बफर के अंत में परिणाम एक ही कारण के लिए छोड़ दिया जाता है: खोज स्ट्रिंग बफर के आकार तक सीमित है और वास्तविक परिणाम बफर की सीमा को पार कर सकता है।



हम एक उदाहरण देते हैं। एक लाइन है - “DevExpress एक बेहतरीन कंपनी है!” । फिलहाल बफर की सामग्री "प्रेस एक gre है" (छवि 4)।





अंजीर। 4।



उन सभी शब्दों को खोजने की आवश्यकता है जिनकी लंबाई तीन वर्णों से अधिक या बराबर है। इस मामले में नियमित अभिव्यक्ति इस तरह होनी चाहिए: "\ b \ w {3,} \ b" । खोज के बाद, हमें पहला मैच मिलता है - "प्रेस" । यह वांछित अभिव्यक्ति को पूरी तरह से संतुष्ट करता है, लेकिन परिणाम नहीं है। अगला मैच खोजने से हमें "जीआरई" मिलता है , जो भी परिणाम नहीं है। यदि बफ़र ऑफ़सेट मान चार वर्ण है, तो अगला बफ़र मान "s एक महान c" है विकल्प के अनुरूप है। खोज परिणाम "महान" बफर के बीच में है और पूरी तरह से नियमित अभिव्यक्ति से मेल खाता है और इसलिए इसे वांछित परिणाम माना जा सकता है।



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



खोज एल्गोरिदम का ब्लॉक आरेख नीचे प्रस्तुत किया गया है।



इनपुट पैरामीटर:

• पैटर्न - नियमित अभिव्यक्ति;
• शिफ्टऑफसेट - प्रत्येक चरण, लागत पर बफर ऑफसेट की मात्रा;
• बफरऑफ़सेट - खोज की शुरुआत के सापेक्ष बफर ऑफसेट;
• दस्तावेज़ - दस्तावेज़ का प्रतिनिधित्व करने वाली एक वस्तु;
• startIndex, endIndex - खोज की सीमाएँ;

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