4

Server.UrlEncode("My File.doc") returns "My+File.doc", whereas the javascript escape("My File.doc") returns "My%20File.doc". As far as i understand it the javascript is corectly URL encoding the string whereas the .net method is not. It certainly seems to work that way in practice putting http://somesite/My+File.doc will not fetch "My File.doc" in any case i could test using firefox/i.e. and IIS, whereas http://somesite/My%20File.doc works fine. Am i missing something or does Server.UrlEncode simply not work properly?

Ben Robinson
  • 21,601
  • 5
  • 62
  • 79
  • Use URLPathEncode instead for bit before the ? querystring see http://stackoverflow.com/questions/4145823/httpserverutility-urlpathencode-vs-httpserverutility-urlencode?lq=1 – Martin Belcher - AtWrk Jan 10 '13 at 14:12
  • Haha, this is probably the best answer given, unfortunately nearly 2 years after it is actually useful. Oh well at least I will know for future reference. – Ben Robinson Jan 10 '13 at 14:40
  • :) Actually it looks like Uri.EscapeDataString is the one to use because URLPathEncode does not escape chars such as percent signs http://stackoverflow.com/questions/9400445/how-do-you-correctly-escape-a-document-name-in-net – Martin Belcher - AtWrk Jan 11 '13 at 12:32
  • Every day is a school day ;-) – Ben Robinson Jan 11 '13 at 15:17

4 Answers4

7

Use Javascripts encodeURIComponent()/decodeURIComponent() for "round-trip" encoding with .Net's URLEncode/URLDecode.

EDIT

As far as I know, historically the "+" has been used in URL encoding as a special substitution for the space char ( ASCII 20 ). If an implementation does not take the space into consideration as a special character with the '+' substitution, then it still has to escape it using its ASCII code ( hence '%20' ).

There is a really good discussion of the situation at http://bytes.com/topic/php/answers/5624-urlencode-vs-rawurlencode. It's inconclusive, by the way. RFC 2396 lumps the space with other characters without an unreserved representation, which sides with the '%20' crowd.

RFC 1630 sides with the '+' crowd ( via forum discusion )...

Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must beencoded. This method was used to make query URIs easier to pass in systems which did not allow spaces.

Also, the core RFCs are...

RFC 1630 - Universal Resource Identifiers in WWW

RFC 1738 - Uniform Resource Locators (URL)

RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax

Community
  • 1
  • 1
kervin
  • 11,672
  • 5
  • 42
  • 59
4

As far as i understand it the javascript is corectly URL encoding the string whereas the .net method is not

Actually they're both wrong!

JavaScript escape() should never be used. As well as failing to encode the + character to %2B, it encodes all non-ASCII characters as a non-standard %uNNNN sequence.

Meanwhile Server.UrlEncode is not exactly URL-encoding as such, but encoding to application/x-www-form-urlencoded, which should only normally be used for query parameters. Using + to represent a space outside of a form name=value construct, such as in a path part, is wrong.

This is rather unfortunate. You might want to try doing a string replace of the + character with %20 after encoding with UrlEncode() when you are encoding into a path part rather than a parameter. In a parameter, + and %20 are equally good.

bobince
  • 528,062
  • 107
  • 651
  • 834
3

A + instead of a space is correct URL encoding, as would escaping it to %20. See this article (CGI Programming in Perl - URL Encoding).

The + is not something that JavaScript can parse, so javascript will escape the space or + to %20.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
2

Using System.Uri.EscapeDataString() serverside and decodeURIComponent clientside works.

stealthyninja
  • 10,343
  • 11
  • 51
  • 59
JaiB
  • 71
  • 1
  • 1