What's the difference between HttpServerUtility.UrlPathEncode and HttpServerUtility.UrlEncode? And when should I choose one over the other?
3 Answers
UrlEncode is useful for query string values (so to the left or especially, right, of each =).
In this url, foo, fooval, bar, and barval should EACH be UrlEncode'd separately:
UrlEncode encodes everything, such as ?, &, =, and /, accented or other non-ASCII characters, etc, into %-style encoding, except space which it encodes as a +. This is form-style encoding, and is best for something you intend to put in the querystring (or maybe between two slashes in a url) as a parameter without it getting all jiggy with the url's control characters (like &). Otherwise an unfortunately placed & or = in a user's form input or db value value could break things.
EDIT: Uri.EscapeDataString is a very close match to UrlEncode, and may be preferable, though I don't know the exact differences.
UrlPathEncode is useful for the rest of the query string, it affects everything to the left of the ?.
In this url, the entire url (from http to barval) should be run through UrlPathEncode.
UrlPathEncode does NOT encode ?, &, =, or /. It DOES, however, like UrlEncode, encode accented/non-ASCII characters with % notation, and space also becomes %20. This is useful to make sure the url is valid, since spaces and accented characters are not. It won't touch your querystring (everything to the right of ?), so you have to encode that with UrlEncode, above.
6 Comments
Eamon Nerbonne
UrlPathEncode is intrinsically buggy; it cannot possibly work correctly. Consider the url
http://example.com/really?-unexpected-truths?id=3&user=eamon & co The intent is that the first question mark is part of the url, and the second the delimiter for the uri's query component, but there's no way to know. And the intent again is for the first & to be a delimiter and the second to be content... but again, there's no way to know. The whole point of encoding is that the data may include special control characters that are used by the underlying format, so you cannot encode this way.Eamon Nerbonne
UrlEncode is simply a mildy non-standard, legacy version of EscapeDataString. Use that instead; don't use UrlEncode if you want reliable portability of the generated uri.
Scott Stafford
@EamonNerbonne: I think your TL;DR is dangerously misleading. Read out of context, it says, "don't bother to encode at all." I recognize that you're pointing out to use
EscapeDataString instead, and that it should be used in a piecewise manner on any parts of the URL that you intend NOT to contain control characters, but the TL;DR doesn't even hint at any of that.Eamon Nerbonne
Comments are limited in length; I wrote that in another comment.
cbp
Well I for one am even more thoroughly confused after reading all this.
|
Update: as of 4.5, per MSDN reference, Microsoft recommends to only use UrlEncode. Also, the information previously listed in MSDN does not fully describe behavior of the two methods - see comments.
The difference is all in the space escaping - UrlEncode escapes them into + sign, UrlPathEncode escapes into %20. + and %20 are only equivalent if they are part of QueryString portion per W3C. So you can't escape whole URL using + sign, only querystring portion. Bottom line is that UrlPathEncode is always better imho
You can encode a URL using with the UrlEncode() method or the UrlPathEncode() method. However, the methods return different results. The UrlEncode() method converts each space character to a plus character (+). The UrlPathEncode() method converts each space character into the string "%20", which represents a space in hexadecimal notation. Use the UrlPathEncode() method when you encode the path portion of a URL in order to guarantee a consistent decoded URL, regardless of which platform or browser performs the decoding.
6 Comments
Tim Goodman
There are actually more differences than just the treatment of spaces, although the documentation doesn't really make this clear. UrlEncode will encode characters like "?" and "&" which are ignored by UrlPathEncode. See here: connect.microsoft.com/VisualStudio/feedback/details/551839/…
Tim Goodman
Also UrlPathEncode doesn't encode anything after the first occurence of "?". It assumes the rest is the query string, and assumes the query string is already encoded.
Martin Belcher - AtWrk
HttpUtility.UrlPathEncode("your.URI.here") + "?" + HttpUtility.UrlEncode("name1") + "=" + HttpUtility.UrlEncode("value1") + "&" + HttpUtility.UrlEncode("name2") + "=" + HttpUtility.UrlEncode("value2") + "#" + HttpUtility.UrlPathEncode("anchor")
Snixtor
It's worth noting that the .NET 4.5 version of Documentation for
UrlPathEncode states: "Do not use; intended only for browser compatibility. Use UrlEncode." msdn.microsoft.com/en-us/library/… This is true of both HttpUtility.UrlPathEncode and HttpServerUtility.UrlPathEncode
nothingisnecessary
UrlPathEncode seems to encode consistently with JavaScript's encodeURIComponent. I use UrlPathEncode when I need to render URLs whose output can be decoded in browser with decodeURIComponent (and vice versa). |
To explain it as simply as possible:
HttpUtility.UrlPathEncode("http://www.foo.com/a b/?eggs=ham&bacon=1")
becomes
http://www.foo.com/a%20b/?eggs=ham&bacon=1
and
HttpUtility.UrlEncode("http://www.foo.com/a b/?eggs=ham&bacon=1")
becomes
http%3a%2f%2fwww.foo.com%2fa+b%2f%3feggs%3dham%26bacon%3d1
UrlPathEncode)