Server.UrlEncode vs. HttpUtility.UrlEncode

Question

Is there a difference between Server.UrlEncode and HttpUtility.UrlEncode?

Answer 1

HttpServerUtility.UrlEncode will use HttpUtility.UrlEncode internally. There is no specific difference. The reason for existence of Server.UrlEncode is compatibility with classic ASP.

Answer 2

Only in the method name.

Answer 3

The same. Server.UrlEncode() calls HttpUtility.UrlEncode();

Answer 4

Server.UrlEncode() is there to provide backward compatibility with Classic ASP,

Server.UrlEncode(str);

Is equivalent to:

HttpUtility.UrlEncode(str, Response.ContentEncoding);

Answer 5

Keep in mind that you probably shouldn't be using either one of those methods. Microsoft's Anti-Cross Site Scripting Library includes replacements for HttpUtility.UrlEncode and HttpUtility.HtmlEncode that are both more standards-compliant, and more secure. As a bonus, you get a JavaScriptEncode method as well.

Answer 6

Having had significant headaches with these methods before, I recommend you avoid any variant of UrlEncode, and instead use Uri.EscapeDataString - at least that one has a comprehensible behavior.

Let's see...

HttpUtility.UrlEncode(" ") == "+" //breaks ASP.NET when used in paths, non-
                                  //standard, undocumented.
Uri.EscapeUriString("a?b=e") == "a?b=e" // makes sense, but rarely what you
                                        // want, since you still need to
                                        // escape special characters yourself

But my personal favorite has got to be HttpUtility.UrlPathEncode - this thing is really incomprehensible. It encodes:

• " " ==> "%20"
• "100% true" ==> "100%%20true" (ok, your url is broken now)
• "test A.aspx#anchor B" ==> "test%20A.aspx#anchor%20B"
• "test A.aspx?hmm#anchor B" ==> "test%20A.aspx?hmm#anchor B" (*note the difference with the previous escape sequence!*)

It also has the lovelily specific MSDN documentation "Encodes the path portion of a URL string for reliable HTTP transmission from the Web server to a client." - without actually explaining what it does. You are less likely to shoot yourself in the foot with an Uzi...

In short, stick to Uri.EscapeDataString