डेभलपरहरूका लागि URL इन्कोडिङ र डिकोडिङ बुझ्नुहोस्
URL मा एउटा खाली ठाउँ, वा कुनै सिरिलिक शब्द, वा ठेगानाको सट्टा तपाईंको डेटासँग सम्बन्धित एम्परसेन्ड टाइप गर्नुहोस्, र केही न केही समस्या आउँछ। वेबले ASCII क्यारेक्टरको सानो, अनुमानयोग्य सेटका लागि मात्र सुरक्षित यातायातको ग्यारेन्टी दिन्छ। बाँकी सबैलाई राउटर, सर्भर र ब्राउजर सबैले सहमत हुने फर्म्याटमा बेर्नैपर्छ। त्यो फर्म्याट प्रतिशत-इन्कोडिङ हो, जसलाई सामान्यतया URL इन्कोडिङ भनिन्छ, र यो पेजले तपाईंलाई सिधै तपाईंको ब्राउजरमै दुवै दिशामा टेक्स्ट रूपान्तरण गर्न दिन्छ।
प्रतिशत-इन्कोडिङ वास्तवमा के हो
नियम यान्त्रिक र पछ्याउन सजिलो छ। शाब्दिक रूपमा नआउने कुनै पनि क्यारेक्टरलाई % चिन्ह र त्यसपछि त्यो क्यारेक्टरको बाइट मान बताउने दुई हेक्साडेसिमल अंकले प्रतिस्थापन गरिन्छ। खाली ठाउँ %20 बन्छ। प्लस चिन्ह %2B बन्छ। ह्यास चिन्ह %23 बन्छ। कुनै क्यारेक्टर धेरै बाइटमा म्याप हुन्छ भने, जस्तै UTF-8 अन्तर्गत धेरैजसो नन-ASCII टेक्स्टको हुन्छ, तपाईंले लगातार धेरै त्रिपुल पाउनुहुन्छ: युरो चिन्ह %E2%82%AC बन्छ। डिकोडिङले प्रक्रिया उल्टाउँछ, हरेक त्रिपुललाई फेरि यसको मूल बाइटमा पढ्दै।
यो परम्परा URI विशिष्टिकरण (RFC 3986) मा परिभाषित छ र यो जानाजान सामान्य राखिएको छ। सामान्य नै मुख्य कुरा हो। पृथ्वीको हरेक राम्रोसँग व्यवहार गर्ने HTTP क्लाइन्ट र सर्भरले उही नियम लागू गर्छन्, त्यसैले एक ठाउँमा सही तरिकाले इन्कोड गरिएको लिङ्क अन्य सबैतिर बिग्रिनुको सट्टा अक्षुण्ण रूपमा पुग्छ।
यो किन आवश्यक छ
URL ले धेरै फरक भूमिका भएका दुई किसिमका क्यारेक्टर बोक्छ। रिजर्भ गरिएका क्यारेक्टर जस्तै /, ?, #, &, = र : संरचनात्मक हुन्। तिनले पार्सरलाई पथ कहाँ सकिन्छ र क्वेरी स्ट्रिङ कहाँ सुरु हुन्छ, वा एउटा परामिटर कहाँ रोकिन्छ र अर्को कहाँ सुरु हुन्छ भनी बताउँछन्। तपाईंको वास्तविक डेटामा ती चिन्हमध्ये एउटा भएमा, यसलाई इन्कोड गर्नुपर्छ ताकि पार्सरले यसलाई विराम चिन्ह ठान्दैन। A&B/2024 जस्तो अर्डर सन्दर्भ क्वेरी स्ट्रिङमा कच्चा राखिएमा दुई परामिटर र एउटा पथ खण्ड भनी गलत पढिनेछ।
त्यसपछि असुरक्षित र नन-ASCII क्यारेक्टर पनि छन्: खाली ठाउँ, उद्धरण चिन्ह, कोण कोष्ठक, स्वरचिन्ह भएका अक्षर, इमोजी, प्लेन ASCII दायराभन्दा बाहिरका जुनसुकै कुरा। यिनको URL मा शाब्दिक रूपमा देखा पर्नुको कुनै काम छैन, या त तिनी यात्राको क्रममा बिग्रिन्छन् वा तिनको कुनै परिभाषित प्रतिनिधित्व छैन। तिनलाई इन्कोड गर्नाले परिणाम संयोगमा छाड्नुको सट्टा लिङ्क सफा र अनुमानयोग्य राख्छ।
यो वास्तविक कामकाजमा कहाँ देखा पर्छ
क्वेरी स्ट्रिङ क्लासिक उदाहरण हो। तपाईंले ?key=... मा थप्ने हरेक मान इन्कोड गरिनुपर्छ ताकि प्रयोगकर्ताको इनपुटले संरचना नबिगारोस्। यही कुरा application/x-www-form-urlencoded का रूपमा पठाइने HTML फर्म सबमिसनमा पनि लागू हुन्छ, जहाँ ब्राउजरले फिल्ड मानहरू स्वतः इन्कोड गर्छ (र, ऐतिहासिक परम्पराअनुसार, खाली ठाउँलाई %20 को सट्टा + बनाउँछ)। तपाईं यसलाई नन-ल्याटिन शीर्षक भएका पेजहरूतिर देखाउने लिङ्क बनाउँदा, API अनुरोध हातैले बनाउँदा, रिडाइरेक्ट लक्ष्यलाई परामिटरका रूपमा पास गर्दा, र ठेगाना बारमा राम्रो देखिने अनुरोध सर्भरमा किन बिग्रिएर आउँछ भनी डिबग गर्दा पनि भेट्टाउनुहुनेछ।
encodeURI बनाम encodeURIComponent
JavaScript ले दुईवटा इन्कोडर दिन्छ, र गलत छनोट गर्नु सामान्य बग हो। फरक दायराको बारेमा हो। encodeURIComponent एउटा एकल डेटाका लागि हो, जस्तै एउटा क्वेरी मान। यसले लगभग सबै कुरा इन्कोड गर्छ, रिजर्भ गरिएका क्यारेक्टर /, ?, :, @, &, =, + र # सहित। डेटाले ती चिन्हलाई सामान्य टेक्स्टका रूपमा राख्न मिल्छ भने यही ठ्याक्कै तपाईंलाई चाहिने कुरा हो।
encodeURI तपाईंले काम गरिरहने राख्न चाहनुभएको सम्पूर्ण ठेगानाका लागि हो। यसले संरचनात्मक क्यारेक्टरलाई छोइदैन, त्यसैले URL लाई एकसाथ बाँध्ने स्ल्यास, कोलन र प्रश्न चिन्ह जीवित रहन्छन्। तपाईंसँग पूर्ण URL छ र केवल खाली ठाउँ वा नन-ASCII क्यारेक्टर सफा गर्न चाहनुहुन्छ भने यसलाई प्रयोग गर्नुहोस्; तपाईं ठूलो URL मा मान घुसाउँदै हुनुहुन्छ भने जहिले पनि encodeURIComponent तर्फ जानुहोस्। सरल नियम: सम्पूर्ण लिङ्क लाई encodeURI ले इन्कोड गर्नुहोस्, घुसाउने भागहरू लाई encodeURIComponent ले इन्कोड गर्नुहोस्।
सबै कुरा तपाईंकै मेसिनमा रहन्छ
यो टुल पूर्णतया तपाईंको ब्राउजरभित्रै चल्छ। तपाईंले पेस्ट गर्ने टेक्स्ट उही मानक रुटिनहरू प्रयोग गरी स्थानीय रूपमा इन्कोड वा डिकोड गरिन्छ र कहिल्यै सर्भरमा यात्रा गर्दैन, जसले यसलाई टोकन, हस्ताक्षरित परामिटर, वा तपाईंले तारमार्फत नपठाउन चाहेको अन्य कुनै पनि कुराका लागि सुरक्षित बनाउँछ। तपाईं अन्य टेक्स्ट रूपान्तरणसँग काम गर्नुहुन्छ भने, Base64 रूपान्तरक ठ्याक्कै छेउमै छ, र तपाईं दैनिक कामका थप सहयोगीहरूका लागि हाम्रो सम्पूर्ण डेभलपर टुलहरू को सेट ब्राउज गर्न सक्नुहुन्छ।
बारम्बार सोधिने प्रश्नहरू
URL मा %20 को अर्थ के हो?
यो इन्कोड गरिएको खाली ठाउँ हो। खाली ठाउँ क्यारेक्टर URL मा शाब्दिक रूपमा अनुमति छैन, त्यसैले यसलाई प्रतिशत चिन्ह र हेक्साडेसिमल मान 20, जुन खाली ठाउँको बाइट मान हो, ले प्रतिस्थापन गरिन्छ।
कहिलेकाहीँ %20 को सट्टा प्लस चिन्ह किन देखिन्छ?
application/x-www-form-urlencoded प्रकारको HTML फर्म डेटाले खाली ठाउँलाई ऐतिहासिक परम्पराअनुसार प्लस चिन्हका रूपमा इन्कोड गर्छ। सामान्य पथ वा क्वेरीमा, खाली ठाउँ %20 का रूपमा इन्कोड हुन्छ। दुवैले आआफ्नो सही सन्दर्भमा फेरि खाली ठाउँमा डिकोड हुन्छन्।
मैले कहिले encodeURI को सट्टा encodeURIComponent प्रयोग गर्नुपर्छ?
तपाईं URL मा घुसाउँदै गरेको एकल मान, जस्तै क्वेरी परामिटरका लागि encodeURIComponent प्रयोग गर्नुहोस्, किनभने यसले रिजर्भ गरिएका क्यारेक्टर पनि इन्कोड गर्छ। यसलाई एकसाथ बाँध्ने स्ल्यास, कोलन र प्रश्न चिन्ह जोगाउन चाहनुहुन्छ भने पूर्ण ठेगानाका लागि encodeURI प्रयोग गर्नुहोस्।
URL इन्कोडिङले मेरो डेटाको अर्थ बदल्छ?
होइन। इन्कोडिङ पूर्णतया उल्टाउन योग्य छ। परिणाम डिकोड गर्दा ठ्याक्कै मूल टेक्स्ट, बाइट-बाइट, दुवैतिर उही क्यारेक्टर सेट प्रयोग गरिएसम्म फर्किन्छ।
स्वरचिन्ह वा इमोजी जस्ता नन-ASCII क्यारेक्टर कसरी ह्यान्डल गरिन्छन्?
तिनलाई पहिले UTF-8 बाइटमा बदलिन्छ, त्यसपछि हरेक बाइट आफ्नै प्रतिशत त्रिपुल बन्छ। त्यसैले एउटै स्वरचिन्ह भएको अक्षर वा इमोजी इन्कोड गरिएको आउटपुटमा धेरै त्रिपुलमा विस्तार हुन सक्छ।
यो टुल प्रयोग गर्दा मेरो टेक्स्ट सर्भरमा पठाइन्छ?
होइन। इन्कोडिङ र डिकोडिङ पूर्णतया तपाईंको ब्राउजरभित्रै हुन्छ। तपाईंले पेस्ट गर्ने कुनै पनि कुरा अपलोड हुँदैन, त्यसैले यो निजी वा संवेदनशील स्ट्रिङसँग प्रयोग गर्न सुरक्षित छ।