2015-06-19 11 views
6

http://www.w3schools.com/tags/ref_urlencode.asp के अनुसार जब अनुरोध सबमिट किए जाते हैं तो वे यूआरएल एन्कोड किए जाते हैं, इसलिए उदाहरण के लिए स्थान% 20 में बदल जाता है। अब तक सब ठीक है।.NET UrlEncode काम नहीं कर रहा है?

मुझे कोई समस्या है! इसे फ़ॉर्म में सबमिट करने से इसे 21% तक बदल दिया जाना चाहिए। हालांकि HttpUtility.UrlEncode (या इसके WebUtility साथी) या Uri.EscapeDataString सभी वापस आ जाएंगे! क्या यह एक अपेक्षित व्यवहार है? मुझे अपने इनपुट को सी # से कैसे एन्कोड करना चाहिए ताकि यह उचित मानों को परिवर्तित कर सके?

+0

मैं आपको तकनीकी स्पष्टीकरण नहीं दे सकता लेकिन मैं पुष्टि कर सकता हूं कि विचलन। इसके अलावा मुझे कई अलग-अलग लागू यूआरएल एन्कोड भी मिले। –

+0

ध्यान दें कि जावास्क्रिप्ट 'encodeURIComponent' वही करता है। [उस कार्य के बारे में मोज़िला सहायता] में एक एनोटेशन है (https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) जो कहता है: * आरएफसी 3986 के पालन में अधिक कठोर होने के लिए (जो आरक्षित करता है!, ', (,), और *), भले ही इन पात्रों में यूआरआई डिलीमिटिंग उपयोगों को औपचारिक रूप से उपयोग नहीं किया गया हो, फिर भी निम्नलिखित का सुरक्षित रूप से उपयोग किया जा सकता है: * – xanatos

+0

यह बहुत ही रोचक/अजीब है। तो हमारे पास कुछ अक्षर हैं जो 'ग्रे' जोन में हैं और हो सकता है कि उन्हें –

उत्तर

6

एक विस्मयादिबोधक चिह्न को यूआरएल-सुरक्षित ASCII चरित्र माना जाता है और इसलिए प्रतिशत एनकोड नहीं किया जाता है।

MSDN

से UrlEncode विधि यूआरएल-एन्कोड किसी भी चरित्र है कि सेट में नहीं है ASCII वर्ण कि यूआरएल के लिए सुरक्षित माना जाता है की । स्पेस ASCII "+" वर्ण के रूप में एन्कोड किए गए हैं। यूआरएल-सुरक्षित ASCII वर्णों में एएससीआई वर्ण (ए से ज़ेड और ए से ज़ेड), अंक (0 से 9), और कुछ विराम चिह्न शामिल हैं। निम्न तालिका में विराम चिह्न चिह्न सूचीबद्ध हैं जिन्हें यूआरएल-सुरक्षित ASCII वर्ण माना जाता है।

तालिका - _ . ! * ()

अद्यतन

this answer के अनुसार, Uri.EscapeDataString! सांकेतिक शब्दों में बदलना चाहिए जब .NET 4.5 परियोजनाओं लक्ष्यीकरण लेकिन मैं अपने वर्तमान मशीन पर उसकी जांच करने में असमर्थ हूँ में शामिल है। पिछले .NET ढांचे पर EscapeDataString प्रतिशत ऊपर वर्णों को एन्कोड नहीं करता है। आपको बस String.Replace का उपयोग करने की आवश्यकता हो सकती है और उपरोक्त वर्णों को प्रतिस्थापित यूआरआई से प्रतिस्थापित कर सकते हैं।

+0

धन्यवाद कीबोर्डपी - क्या .NET एन्कोड इन में कोई तरीका है? –

+0

@MarcinWaligora अद्यतन उत्तर – keyboardP

1

तो हमारे पास कुछ अक्षर हैं जो 'ग्रे' जोन में हैं और हो सकते हैं लेकिन उन्हें एन्कोड नहीं किया जाना चाहिए।

सभी वर्ण एन्कोड किए जा सकते हैं। http://stackoverflow.com/questions और http://stackoverflow.com/%71%75%65%73%74%69%6F%6E%73 दोनों समान हैं।

एकमात्र समय एक चरित्र को एन्कोड नहीं किया जा सकता है, अगर इसका उपयोग इस तरह किया जा रहा है कि यूआरआई के साथ विशेष अर्थ है, जैसे / पथ तत्वों को अलग करना।

केवल समय एक चरित्र एन्कोड किया जाना चाहिए, अगर:

  1. यह उन विशेष अर्थ पात्रों में से एक है, और उस विशेष अर्थ के साथ उपयोग नहीं किया जा रहा है।
  2. यह आरक्षित पात्रों में से एक है जिसका विशेष यूआरआई योजना या विशेष स्थान में विशेष अर्थ हो सकता है।
  3. इसमें यू +007 एफ के बारे में एक कोड बिंदु है।

हालांकि पिछले दो में अपवाद हैं।

तीसरे मामले में यदि आप आईआरआई का उपयोग करते हैं तो आप ऐसे पात्रों को एन्कोड नहीं करते हैं, जो कि आईआरआई की परिभाषा काफी अधिक है। आप उस एन्कोडिंग को पूर्ववत या पूर्ववत करके आईआरआई और यूआरआई के बीच परिवर्तित कर सकते हैं। (मेजबान भाग में ऐसे किसी भी वर्ण को यूआरआई-एनकोडेड नहीं, हालांकि एन्कोड किया गया पन्योड होना चाहिए)।

दूसरे मामले में चरित्र को एन्कोड करना सुरक्षित नहीं है अगर इसे संदर्भ में संदर्भ में एक डिलीमीटर के रूप में उपयोग नहीं किया जाता है। तो उदाहरण के लिए, & छोड़ा जा सकता है क्योंकि यह कुछ यूआरआई में है लेकिन HTTP यूआरआई में नहीं है जहां इसे अक्सर क्वेरी डेटा के लिए विभाजक के रूप में उपयोग किया जाता है। हालांकि यह विशेष यूआरआई योजना के विशेष ज्ञान रखने पर निर्भर करता है। यह शायद कुछ अन्य प्रक्रियाओं के जोखिम के लायक नहीं है, यह महसूस नहीं कर रहा है कि यह ठीक है।

! इसका एक उदाहरण है। RFC 3986 उत्पादन में शामिल हैं:

reserved = gen-delims/sub-delims 

gen-delims = ":"/"/"/"?"/"#"/"["/"]"/"@" 

sub-delims = "!"/"$"/"&"/"'"/"("/")" 
      /"*"/"+"/","/";"/"=" 

और इसलिए ! अक्षर हैं जो उपयोग में योजना के आधार पर unencoded छोड़ें या नहीं, सुरक्षित किया जा सकता है के सेट में है।

आमतौर पर, आप (जैसे जब एक HttpEncoder कार्यान्वयन लेखन के रूप में) अपनी खुद की एन्कोडिंग कोड लिख रहे हैं, तो आप शायद बेहतर बस हमेशा ! एन्कोडिंग हैं, लेकिन आप एक एनकोडर उपयोग कर रहे हैं कि ! सभी एन्कोड नहीं करता वह समय जो शायद ठीक है; निश्चित रूप से HTTP यूआरआई में इसे कोई फर्क नहीं पड़ता है।

संबंधित मुद्दे