यूआरएल पार्सर

यूआरएल पार्सर एक मुफ्त टूल है, जो किसी वेब पते को उसकी स्कीम, पाथ और क्वेरी स्ट्रिंग में अलग करता है।

यूआरएल पार्सर क्या-क्या निकालता है?

यूआरएल पार्सर वेब पते के संरचनात्मक हिस्सों की पहचान करता है, इसलिए आपको टेक्स्ट को खुद अलग नहीं करना पड़ता। यह टूल PHP के parse_url फंक्शन से मिले तीन फ़ील्ड दिखाता है।

• स्कीम प्रोटोकॉल या एड्रेसिंग स्कीम बताती है, जैसे https या http।
• पाथ पाथ वाला हिस्सा बताता है, जैसे /account/orders/42।
• क्वेरी उस प्रश्न चिह्न के बाद का टेक्स्ट रखती है जहां से क्वेरी शुरू होती है और किसी भी अनएन्कोडेड संख्या चिह्न से पहले समाप्त होती है, जैसे page=2&sort=date।

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

मिलने वाले फ़ील्ड में होस्टनेम, पोर्ट या फ़्रैगमेंट अलग से शामिल नहीं होते। अगर आपको इन हिस्सों की भी जरूरत है, तो अपने एप्लिकेशन में अधिक संपूर्ण URL पार्सिंग लाइब्रेरी इस्तेमाल करें।

यूआरएल पार्सर का इस्तेमाल कैसे करें?

पूरा या आंशिक URL दर्ज करें और टूल से मिली स्कीम, पाथ और क्वेरी की वैल्यू देखें। पूरा एब्सोल्यूट URL आम तौर पर सबसे स्पष्ट नतीजा देता है, क्योंकि उसमें स्कीम साफ तौर पर दी होती है।

1. ब्राउज़र, API रिस्पॉन्स, वेबहुक रिकॉर्ड या सर्वर लॉग से URL कॉपी करें।
2. अगर पैरामीटर के नाम या वैल्यू जांचनी हैं, तो क्वेरी स्ट्रिंग भी शामिल करें।
3. मिले हुए पाथ की तुलना उस रूट से करें जिसकी आपके एप्लिकेशन को अपेक्षा है।
4. जांचें कि आपकी इंटीग्रेशन में जहां स्कीम और क्वेरी जरूरी हैं, वहां वे मौजूद हैं या नहीं।

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

उदाहरण और नतीजों को समझने का तरीका

एब्सोल्यूट API URL में पार्सर प्रोटोकॉल को रूट और मूल क्वेरी स्ट्रिंग से अलग कर देता है।

इनपुट https://api.example.co.uk/v1/orders/42?expand=items&currency=GBP

स्कीम https

पाथ /v1/orders/42

क्वेरी expand=items&currency=GBP

क्वेरी एक ही हिस्से के रूप में लौटाई जाती है। आम फॉर्म/क्वेरी-स्ट्रिंग नियम के अनुसार, एम्परसैंड फ़ील्ड को अलग करता है और हर फ़ील्ड में पहला बराबर चिह्न उसके नाम को उसकी वैल्यू से अलग करता है। सिर्फ URL पार्स करने से यह पुष्टि नहीं होती कि expand या currency ऐसा पैरामीटर है जिसे API पहचानता है।

रिलेटिव रेफ़रेंस में स्कीम दिए बिना भी पाथ और क्वेरी हो सकते हैं।

इनपुट /search?q=red%20shoes&page=2

स्कीम no scheme component

पाथ /search

क्वेरी q=red%20shoes&page=2

एक ही वेबसाइट के भीतर बनाए गए लिंक में स्कीम का न होना अक्सर सामान्य है। लेकिन जिस डेटा में एब्सोल्यूट कॉलबैक URL होना चाहिए, वहां यही नतीजा गायब https:// प्रीफ़िक्स का संकेत दे सकता है।

यह पार्सर URL वैलिडेटर नहीं है। यह संदिग्ध संरचना पहचानने में मदद कर सकता है, जैसे स्कीम का गायब होना, अनपेक्षित पाथ या गलत जगह मौजूद क्वेरी टेक्स्ट। लेकिन पार्स किया हुआ नतीजा यह साबित नहीं करता कि पता मौजूद है, DNS में रिज़ॉल्व होता है या सफल HTTP रिस्पॉन्स देता है।

स्पेस, विराम चिह्न और असामान्य इनपुट का क्या होता है?

रिज़र्व्ड कैरेक्टर यह तय करने में भूमिका निभाते हैं कि URL कैसे अलग होगा, जबकि एन्कोडेड कैरेक्टर आम तौर पर उसी हिस्से में बने रहते हैं जिसमें वे मौजूद हैं। पार्सर हिस्सों को अलग करता है, उनकी सामग्री को डीकोड या नॉर्मलाइज़ नहीं करता।

• अनएन्कोडेड प्रश्न चिह्न से क्वेरी वाला हिस्सा शुरू होता है। अगर मौजूदा क्वेरी से बाहर कोई वास्तविक प्रश्न चिह्न डेटा के रूप में चाहिए और वह अन्यथा क्वेरी डिलिमिटर बन जाएगा, तो उसे प्रतिशत-एन्कोड करना चाहिए।
• एम्परसैंड आम तौर पर क्वेरी पैरामीटर अलग करता है, लेकिन यह टूल हर पैरामीटर की अलग व्याख्या करने के बजाय पूरी क्वेरी स्ट्रिंग लौटाता है।
• मानक URL सिंटैक्स में अनएन्कोडेड संख्या चिह्न (#) फ़्रैगमेंट डिलिमिटर होता है। फ़्रैगमेंट डेटा यहां लौटाए जाने वाले फ़ील्ड में शामिल नहीं है।
• स्पेस को आम तौर पर एन्कोड करना चाहिए, प्रायः %20 के रूप में। फॉर्म-एन्कोडेड क्वेरी डेटा में प्लस चिह्न स्पेस दर्शा सकता है, लेकिन यह व्याख्या URL पार्सिंग के बजाय क्वेरी डीकोडिंग से संबंधित है।
• उच्चारण चिह्न वाले और गैर-लैटिन पाथ या क्वेरी टेक्स्ट के लिए, प्राप्त करने वाले सिस्टम की जरूरत के अनुसार UTF-8 प्रतिशत-एन्कोडिंग इस्तेमाल करनी चाहिए। व्यापक प्रोटोकॉल अनुकूलता के लिए अंतरराष्ट्रीयकृत डोमेन नाम अपने ASCII-संगत रूप का इस्तेमाल करते हैं।
• संख्याओं के लिए पार्सिंग का कोई विशेष व्यवहार नहीं होता। वे पाथ या क्वेरी वैल्यू में सामान्य कैरेक्टर के रूप में बनी रहती हैं।

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

URL को पार्स करना कब उपयोगी है?

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

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

बार-बार किए जाने वाले या स्वचालित काम के लिए अपने एनवायरनमेंट में उपलब्ध मूल URL सुविधाओं का इस्तेमाल करें। PHP में parse_url, ब्राउज़र JavaScript में URL इंटरफ़ेस, Node.js में URL क्लास और Python में urllib.parse उपलब्ध है। हजारों पतों वाली लॉग फ़ाइल को प्रोसेस करते समय मैन्युअल पार्सिंग के बजाय छोटी कमांड-लाइन स्क्रिप्ट अधिक उपयुक्त है।

किसी ऐसे URL को सिर्फ दोबारा फ़ॉर्मैट करने के लिए पार्स न करें, जो पहले से ठीक उसी रूप में है जिसकी प्राप्त करने वाले सिस्टम को जरूरत है। स्पष्ट वजह के बिना पतों को दोबारा एन्कोड या तैयार करने से क्वेरी सिग्नेचर, दोहराए गए पैरामीटर या रिज़र्व्ड कैरेक्टर बदल सकते हैं।

अक्सर पूछे जाने वाले सवाल

क्या http या https के बिना URL पार्स किया जा सकता है?

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

क्या बार-बार आने वाले क्वेरी पैरामीटर सुरक्षित रहेंगे?

क्वेरी मूल हिस्से के रूप में लौटाई जाती है, इसलिए दोहराए गए नाम अपने मूल क्रम में बने रह सकते हैं। tag=red&tag=blue जैसी वैल्यू को ऐरे या अलग-अलग वैल्यू में कैसे बदला जाएगा, यह बाद में इस्तेमाल किए जाने वाले क्वेरी-स्ट्रिंग पार्सर पर निर्भर करता है।

क्या साइन किया हुआ URL यहां पेस्ट करना सुरक्षित है?

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

सही दिखने वाला URL मेरे एप्लिकेशन में अलग तरह से काम क्यों करता है?

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