लिंक डेटा क्यों खोता है: पैरामीटर और फ़्रैगमेंट सुधारें

खुलने वाला पेज हमेशा अपेक्षित डेटा नहीं पाता

आपने कॉफ़ी और चाय की खोज का लिंक बनाया है। पेज खुलता है, लेकिन नतीजे आपकी मंशा से मेल नहीं खाते। सर्वर या शॉर्टनर को दोष देने से पहले साझा किया गया सटीक पता देखें। काल्पनिक उदाहरण में q=cafe&te, फ़ॉर्म पैरामीटर की सामान्य व्याख्या में एक ही cafe&te मान नहीं है: & प्रविष्टियाँ अलग करता है। साथ ही #precios फ़्रैगमेंट बताता है। असली पता जाँचने से पहले example.invalid की जगह अपनी ऐसी वेबसाइट लगाएँ जो यह क्वेरी स्वीकार करती हो।

निदान को तीन प्रश्नों में बाँटें: कौन सा पेज खोलना है, उसे कौन सा डेटा मिलना चाहिए और उसके बाद कौन सा भाग दिखाना है? बटन का दिखने वाला लेबल ही नहीं, लिंक का URL कॉपी करें। बदलने से पहले संदर्भ संस्करण सहेजें। यह गाइड हिस्सों की समीक्षा और फिर WikiURL से परिणाम जाँचने का सुझाव देती है; यह वादा नहीं करती कि हर साइट q समझती है या सफल प्रतिक्रिया सही खोज परिणाम साबित करती है।

https://example.invalid/buscar?q=cafe&te#precios

एम्परसैंड पाठ का हिस्सा हो तो उसे विभाजक न बनाएँ

शाब्दिक रूप से cafe & te खोजने के लिए एम्परसैंड q के मान में होना चाहिए। URLSearchParams से पैरामीटर बनाते समय बिना एन्कोड किया पाठ दें; सीरियलाइज़ेशन इस चिह्न को %26 बनाएगा। MDN बताता है कि यह इंटरफ़ेस पैरामीटर को पाठ में बदलते समय फ़ॉर्म एन्कोडिंग करता है और स्पेस को + से दर्शाता है। इसका अर्थ URL के सभी एम्परसैंड बदलना नहीं है: कुछ जानबूझकर पैरामीटर अलग करते हैं।

JavaScript उदाहरण आधार पते से URL बनाता है, खोज मान तय करता है और फ़्रैगमेंट अलग जोड़ता है। इसे स्थानीय JavaScript वातावरण में चला सकते हैं, बिना काल्पनिक डोमेन को खोज भेजे। यदि प्रोग्रामिंग नहीं करते, तो पाठ हाथ से जोड़ने के बजाय अपने खोज पेज का बनाया लिंक इस्तेमाल करें। अपेक्षित मान और साइट के नतीजे तुलना करें; लिंक में %26 दिखना किसी विशेष एप्लिकेशन की डेटा व्याख्या साबित नहीं करता।

const url = new URL("https://example.invalid/buscar");
url.searchParams.set("q", "cafe & te");
url.hash = "precios";
console.log(url.href);
// https://example.invalid/buscar?q=cafe+%26+te#precios

फ़्रैगमेंट सर्वर को मिलने वाला पैरामीटर नहीं है

MDN के अनुसार # के बाद वाला फ़्रैगमेंट क्लाइंट में संसाधित होता है और संसाधन माँगने पर सर्वर को नहीं भेजा जाता। पेज इसका उपयोग precios जैसे अनुभाग तक जाने या एप्लिकेशन के दूसरे व्यवहार में कर सकता है। इसलिए q=cafe#te में te उस अनुरोध में सर्वर को मिले मान को पूरा नहीं करता। यदि # खोज पाठ का हिस्सा होना चाहिए, तो मान के भीतर उसका रूप %23 होगा, जैसा तीसरे पते में है।

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

https://example.invalid/buscar?q=cafe%23te#precios

मान को एक बार एन्कोड करें, पूरे पते को नहीं

RFC 3986 घटकों को अलग करने वाले चिह्नों और डेटा में अंतर करता है तथा एक ही स्ट्रिंग को बार-बार एन्कोड या डिकोड करने से मना करता है। यदि बिना एन्कोड किया मान चाहने वाले फ़ंक्शन को cafe%26te जैसा पहले से एन्कोड किया पाठ दें, तो प्रतिशत चिह्न %25 बन सकता है और %2526 दिखाई देगा। आपने एक परत जोड़ी है, इच्छित खोज अपने आप सुरक्षित नहीं की। उदाहरण की दो पंक्तियाँ बदलाव पहचानने में मदद करती हैं।

सुधार डेटा के स्रोत पर निर्भर करता है। मानव पाठ से शुरू हो तो पैरामीटर बनाने वाले इंटरफ़ेस को बिना एन्कोड किए दें। पहले से सही पूरा URL हो तो पूरे पते को एक मान समझकर दोबारा एन्कोड न करें। हर फ़ंक्शन या फ़ॉर्म को मिलने वाले डेटा का रिकॉर्ड रखें। %, & या # पर वैश्विक खोज-प्रतिस्थापन से बचें; इससे सही विभाजक, जरूरी पैरामीटर या अनचाहे रास्ते बदल सकते हैं।

q=cafe%26te
q=cafe%2526te

प्रतिक्रिया के लिए WikiURL और सामग्री के लिए ब्राउज़र इस्तेमाल करें

जब असली सार्वजनिक पता हो, उसे WikiURL के URL जाँच उपकरण में पेस्ट करें। मिले HTTP स्टेटस और अंतिम गंतव्य की समीक्षा करें। कार्यान्वयन सर्वर से अनुरोध करता है और रीडायरेक्ट का अनुसरण करता है; इससे अप्रत्याशित गंतव्य ढूँढ़ने में मदद मिलती है। प्रबंधन लिंक, पासवर्ड या निजी डेटा वाले पते न पेस्ट करें। उदाहरण का example.invalid न जाँचें; यहाँ वह काल्पनिक गंतव्य है।

असली संस्करण ब्राउज़र में भी खोलकर खोज और अनुभाग देखें। सफल प्रतिक्रिया अपेक्षित फ़िल्टर लागू किए बिना पेज लोड कर सकती है। रीडायरेक्ट हो तो उसके पैरामीटर संदर्भ से तुलना करें और ब्राउज़र में फ़्रैगमेंट देखें। जाँच उपकरण एप्लिकेशन का तर्क आपके लिए नहीं समझता, सुरक्षा प्रमाणित नहीं करता और खाते को सामग्री देखने की अनुमति साबित नहीं करता। उद्देश्य प्रतिक्रिया के प्रमाण को कार्यात्मक समीक्षा से जोड़ना है।

वही कॉपी जाँचें जो दूसरे व्यक्ति को मिलेगी

अंतिम लिंक साझा करने वाले चैनल में पेस्ट करें और व्यापक वितरण से पहले वह कॉपी खोलें। देखें कि वाक्य का अंतिम पूर्णविराम न जुड़ा हो, कॉपी करते समय हिस्सा न खोया हो और दिखने वाले पाठ को गंतव्य न समझा हो। सार्वजनिक सामग्री के लिए अपनी व्यवस्थापक सेशन पर निर्भर हुए बिना जाँचें। QR में बदलें तो मूल फ़ाइल के साथ स्कैन में दिखने वाला पता भी देखें।

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