एस्केप यूरीस्ट्रिंग और एस्केपडैटस्ट्रिंग में क्या अंतर है?

193

यदि केवल url एन्कोडिंग के साथ सौदा किया जाता है, तो मुझे EscapeUriString का उपयोग करना चाहिए ?

.net urlencode

10

जैसा कि @ Livven के उत्तर में बताया गया है, हमेशा प्रत्येक व्यक्तिगत मूल्य का उपयोग करके बच Uri.EscapeDataString()जाएं। अन्य दृष्टिकोणों के साथ, सिस्टम में हर संभव इनपुट के लिए इच्छित परिणाम का उत्पादन करने के लिए पर्याप्त जानकारी नहीं होती है।

— तिमो

112

EscapeDataStringहमेशा उपयोग करें (क्यों के बारे में अधिक जानकारी के लिए, Livven का जवाब नीचे देखें)

संपादित करें : दोनों को एन्कोडिंग पर अलग करने के लिए मृत लिंक को हटा दिया गया

— JCL
स्रोत

3

मुझे यकीन नहीं है कि लिंक वास्तव में अधिक जानकारी प्रदान करता है, क्योंकि यह फिर से भागने के बारे में है।

— स्टीवन

1

यह मूल रूप से एक ही अंतर है। यदि आप वास्तव में लेख पढ़ते हैं, तो बीच के चारों ओर एक मेज होती है जो वास्तव में अंतर दिखाने के लिए बच जाती है (अंतर URLEncodeनहीं) भी (तुलना करने के लिए)।

— 15 अक्टूबर को Jcl

2

यह अभी भी मेरे लिए स्पष्ट नहीं है - क्या होगा यदि मैं एक पूरे यूआरआई से बच नहीं रहा हूं, लेकिन इसका केवल एक हिस्सा है - (यानी एक क्वेरी पैरामीटर के लिए डेटा )? क्या मैं यूआरआई के लिए डेटा से बच रहा हूं, या एस्केपडाटास्ट्रिंग का मतलब पूरी तरह से अलग है?

— BrainSlugs83

4

... क्या कुछ परीक्षण ऐसा लग रहा है कि मैं एक URI पैरामीटर के लिए एस्केपडैटस्ट्रिंग चाहता हूं। मैंने "I heart C ++" स्ट्रिंग के साथ परीक्षण किया और EscapeUriString ने "+" वर्णों को एनकोड नहीं किया, यह सिर्फ उन्हें छोड़ दिया है, इस तरह से, EscapeDataString ने उन्हें "% 2B" में सही रूप से परिवर्तित कर दिया।

— ब्रेनस्ल्गस83

7

यह एक बुरा जवाब है। आपको कभी भी UseUriString का उपयोग नहीं करना चाहिए, इसका कोई मतलब नहीं है। नीचे लिवेने का उत्तर देखें (और इसे अपवोट करें)।

— ब्रैंडन पैडॉक

242

मुझे मौजूदा उत्तर संतोषजनक नहीं लगे इसलिए मैंने इस मुद्दे को हल करने के लिए थोड़ा गहरा खुदाई करने का फैसला किया। हैरानी की बात है, जवाब बहुत आसान है:

वहाँ (लगभग *) कोई वैध कारण कभी उपयोग करने के लिए है Uri.EscapeUriString। यदि आपको किसी स्ट्रिंग को प्रतिशत-एनकोड करने की आवश्यकता है, तो हमेशा उपयोग करें Uri.EscapeDataString।

* वैध उपयोग के मामले के लिए अंतिम पैराग्राफ देखें।

ऐसा क्यों है? प्रलेखन के अनुसार :

Unricaped URI स्ट्रिंग को Uri कंस्ट्रक्टर के पैरामीटर के रूप में तैयार करने के लिए EscapeUriString विधि का उपयोग करें।

यह वास्तव में मतलब नहीं है। RFC 2396 के अनुसार :

एक यूआरआई हमेशा "बच गए" रूप में होता है, क्योंकि एक पूर्ण किए गए यूआरआई से बचने या बाहर निकलने से उसका शब्दार्थ बदल सकता है।

जबकि RFC 3986 द्वारा उद्धृत RFC को मान लिया गया है , बिंदु अभी भी खड़ा है। आइए कुछ ठोस उदाहरणों को देखकर इसे सत्यापित करें:

आपके पास एक सरल URI है, जैसे:
```
http://example.org/
```
Uri.EscapeUriString इसे बदल नहीं सकते।
आप भागने के संबंध में क्वेरी स्ट्रिंग को मैन्युअल रूप से संपादित करने का निर्णय लेते हैं:
```
http://example.org/?key=two words
```
Uri.EscapeUriString (सही ढंग से) आप के लिए जगह से बच जाएगा:
```
http://example.org/?key=two%20words
```
आप आगे भी क्वेरी स्ट्रिंग को मैन्युअल रूप से संपादित करने का निर्णय लेते हैं:
```
http://example.org/?parameter=father&son
```
हालाँकि, यह स्ट्रिंग द्वारा परिवर्तित नहीं किया गया है Uri.EscapeUriString, क्योंकि यह मानता है कि एम्परसैंड एक अन्य कुंजी-मूल्य जोड़ी की शुरुआत का प्रतीक है। यह हो सकता है या आप का इरादा नहीं हो सकता है।
आप तय करते हैं कि आप वास्तव में keyपैरामीटर चाहते हैं father&son, इसलिए आप एम्परसेंड से बचकर पिछले URL को मैन्युअल रूप से ठीक करते हैं:
```
http://example.org/?parameter=father%26son
```
हालांकि, Uri.EscapeUriStringप्रतिशत चरित्र से भी बच जाएगा, एक दोहरे एन्कोडिंग के लिए अग्रणी:
```
http://example.org/?parameter=father%2526son
```

जैसा कि आप देख सकते हैं, Uri.EscapeUriStringअपने इच्छित उद्देश्य के लिए उपयोग करना &कई कुंजी-मूल्य जोड़े के बीच विभाजक के रूप में क्वेरी स्ट्रिंग में कुंजी या मान के भाग के रूप में उपयोग करना असंभव बनाता है ।

ऐसा इसलिए है, क्योंकि यह पूर्ण यूआरआई से बचने के लिए उपयुक्त बनाने के प्रयास में, यह आरक्षित वर्णों की उपेक्षा करता है और केवल उन वर्णों से बचता है जो न तो आरक्षित हैं और न ही अनारक्षित हैं, जो कि, BTW, प्रलेखन के विपरीत है । इस तरह आप कुछ के साथ समाप्त नहीं करते हैं http%3A%2F%2Fexample.org%2F, लेकिन आप ऊपर वर्णित मुद्दों के साथ समाप्त करते हैं।

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

आपको हमेशा कुंजी-मूल्य जोड़े और प्रतिशत-एन्कोडिंग को इकट्ठा करके और फिर आवश्यक विभाजकों के साथ उन्हें सम्मिलित करके अपने URL और क्वेरी स्ट्रिंग का निर्माण करना चाहिए। आप Uri.EscapeDataStringइस उद्देश्य के लिए उपयोग कर सकते हैं , लेकिन नहीं Uri.EscapeUriString, क्योंकि यह आरक्षित वर्णों से नहीं बचता है, जैसा कि ऊपर बताया गया है।

केवल अगर आप ऐसा नहीं कर सकते हैं, उदाहरण के लिए जब उपयोगकर्ता द्वारा प्रदान किए गए यूआरआई के साथ काम करते हैं, तो क्या यह Uri.EscapeUriStringअंतिम उपाय के रूप में उपयोग करने के लिए समझ में आता है । लेकिन पहले उल्लिखित कैविएट लागू होते हैं - यदि उपयोगकर्ता द्वारा प्रदान किया गया यूआरआई अस्पष्ट है, तो परिणाम वांछनीय नहीं हो सकते हैं।

— Livven
स्रोत

4

वाह, आखिरकार इस मुद्दे को स्पष्ट करने के लिए धन्यवाद। पिछले दो उत्तर बहुत मददगार नहीं थे।

— EverPresent 20

3

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

— ब्रैंडन पैडॉक

4

अच्छी तरह से समझाया +1 यह केवल उत्तर से स्वीकृत लिंक से बेहतर है

— एहसान सज्जाद

1

इस उत्तर पर अधिक ध्यान देने की आवश्यकता है। इसे करने का सही तरीका है। अन्य उत्तरों में परिदृश्य होते हैं जहां वे इच्छित परिणाम नहीं देते हैं।

— तिमो

1

... ज़रूर encodeURI/ Uri.EscapeUriStringकी जरूरत नहीं है जितनी बार encodeURIComponent/ Uri.EscapeDataString(जब से आप अंधे उर के साथ बहरे हो रहे हैं जो कि उरई संदर्भ में उपयोग किया जाना चाहिए), लेकिन इसका मतलब यह नहीं है कि इसका स्थान नहीं है।

— वर्धमान ताजा

56

प्लस (+) वर्ण इन विधियों के बीच अंतर के बारे में बहुत कुछ बता सकते हैं। एक साधारण यूआरआई में, प्लस वर्ण का अर्थ "स्पेस" है। "खुश बिल्ली" के लिए Google को क्वेरी करने पर विचार करें:

https://www.google.com/?q=happy+cat

यह एक वैध यूआरआई है (इसे आज़माएं), और EscapeUriStringइसे संशोधित नहीं करेंगे।

अब "खुश c ++" के लिए Google पर विचार करें:

https://www.google.com/?q=happy+c++

यह एक वैध यूआरआई है (इसे आज़माएं), लेकिन यह "खुश ग" के लिए एक खोज का उत्पादन करता है, क्योंकि दो प्लसस को रिक्त स्थान के रूप में व्याख्या की जाती है। इसे ठीक करने के लिए, हम "happy c ++" को EscapeDataStringवॉयस ^* पास कर सकते हैं :

https://www.google.com/?q=happy+c%2B%2B

^*) एन्कोडेड डेटा स्ट्रिंग वास्तव में "खुश% 20c% 2B% 2B" है; अंतरिक्ष वर्ण के लिए% 20 हेक्स है, और प्लस वर्ण के लिए% 2B हेक्स है।

यदि आप उपयोग कर रहे हैं UriBuilderजैसा कि आपको होना चाहिए, तो आपको केवल EscapeDataStringअपने संपूर्ण यूआरआई के कुछ घटकों को ठीक से बचाना होगा। @ इस सवाल का लिवेन का जवाब आगे साबित करता है कि वास्तव में उपयोग करने का कोई कारण नहीं है EscapeUriString।

— सेठ
स्रोत

धन्यवाद। जब आपके पास एक पूर्ण यूआरआई स्ट्रिंग होती है, जिसके बारे में आपको सांकेतिक शब्दों में बदलना चाहिए, उदाहरण के लिए "https://www.google.com/?q=happy c++"। ऐसा लगता है कि मुझे मैन्युअल रूप से "?" पर विभाजित होने की आवश्यकता है, या क्या कोई बेहतर तरीका है?

— wensveen

यदि आप पूरे URL को दूसरे URL के पैरामीटर के रूप में पास कर रहे हैं, तो उपयोग करें EscapeDataString। यदि आपके द्वारा प्रदान किया गया URL वास्तविक URL है, तो हाँ आप बस विभाजित करना चाहते हैं ?।

— सेठ

7

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

EscapeUriString:

यह विधि किसी भी वर्ण से बच जाएगी जो कि प्रतिशत संकेत सहित आरक्षित या अनारक्षित चरित्र नहीं है। ध्यान दें कि EscapeUriString भी '#' चिन्ह से बच नहीं पाएगा।

EscapeDataString:

यह विधि किसी भी वर्ण से बच जाएगी जो कि एक अनारक्षित चरित्र नहीं है, जिसमें प्रतिशत संकेत शामिल हैं।

इसलिए अंतर यह है कि वे आरक्षित वर्णों को कैसे संभालते हैं । EscapeDataStringउनसे बच जाता है; EscapeUriStringनहीं करता।

RFC के अनुसार , आरक्षित वर्ण हैं::/?#[]@!$&'()*+,;=

पूर्णता के लिए, अनारक्षित वर्ण अल्फ़ान्यूमेरिक हैं और -._~

दोनों विधियां ऐसे पात्रों से बचती हैं जो न तो आरक्षित हैं और न ही अनारक्षित।

मैं सामान्य धारणा से असहमत हूं जो EscapeUriStringबुराई है। मुझे लगता है कि एक विधि जो केवल अवैध पात्रों (जैसे रिक्त स्थान) से बचती है और आरक्षित वर्ण उपयोगी नहीं है। लेकिन इसमें एक विचित्रता है कि यह %चरित्र को कैसे संभालता है । प्रतिशत-एन्कोडेड वर्ण ( %उसके बाद 2 हेक्स अंक) एक URI में कानूनी हैं । मुझे लगता है कि EscapeUriStringअगर यह इस पैटर्न का पता लगाता और %इसे 2 हेक्स अंकों से तुरंत आगे ले जाता तो एन्कोडिंग से बचने के लिए यह कहीं अधिक उपयोगी होता ।

— टोड मेनियर
स्रोत

1

एक सरल उदाहरण

var data = "example.com/abc?DEF=あいう\x20えお";

Console.WriteLine(Uri.EscapeUriString(data));
Console.WriteLine(Uri.EscapeDataString(data));
Console.WriteLine(System.Net.WebUtility.UrlEncode(data));
Console.WriteLine(System.Web.HttpUtility.UrlEncode(data));

/*
=>
example.com/abc?DEF=%E3%81%82%E3%81%84%E3%81%86%20%E3%81%88%E3%81%8A
example.com%2Fabc%3FDEF%3D%E3%81%82%E3%81%84%E3%81%86%20%E3%81%88%E3%81%8A
example.com%2Fabc%3FDEF%3D%E3%81%82%E3%81%84%E3%81%86+%E3%81%88%E3%81%8A
example.com%2fabc%3fDEF%3d%e3%81%82%e3%81%84%e3%81%86+%e3%81%88%e3%81%8a
*/

— सीख रहा हूँ
स्रोत