By Jeffrey Humpherys
After failing to find a 4Guys article that explains the usefulness of
Server.UrlEncode I decided to write one. I only learned about this nifty
method a few weeks ago and I thought I would share it with y'all.
Server.UrlEncode method takes a string input and converts
non-alphanumeric symbols into their ASCII Hex equivalents with a
% in front (spaces are converted into
+ symbols). For example, if
we have the string
strURL assigned like so:
Server.URLencode(strURL) would return:
You may be wondering, for good reason, why (and how on Earth) the
is useful. Imagine, though, that you wanted to pass such a string as
strURL through the querystring.
For example, assume that you had an
HREF tag like so:
Now, when the user clicked on the hyperlink generated by the
HREF tag, what should happen is the ASP page
http://www.myserver.com/SomePage.asp would be called
with the querystring
?URL=https://www.4guysfromrolla.com/default.asp?id=123&usr=bob. However, ask yourself
this: how is the Web server (IIS) supposed to know where the querystring begins (and, therefore, where the requested URL
ends)? You might say, "Easy, at the
?." Well... which one? There's two! One after
SomePage.asp and one after
default.asp. Also, what are the name/value pairs in the querystring? Remember that each name/value
pair is separated by an ampersand. We mean to have only one name/value pair: the name being
URL and the
https://www.4guysfromrolla.com/default.asp?id=123&usr=bob. But with an unencoded querystring,
it is ambiguous, since
usr=bob could be interpretted as its own name/value pair, thereby giving us
two name/value pairs (
usr=bob). To resolve these problems (and the problem of having other non-alphanumeric characters in
the URL/querystring), use
Server.UrlEncode, which will successfully map those "illegal" non-alphanumeric
characters into the correct ASCII codes.
Let's take a moment to look at a real-world example.
A previous 4Guys article, Simple Authentication
illustrates how to create "secure" ASP pages, ones accessible only by those who have "logged in."
This is accomplished by adding a few lines of code at the top of each protected
.asp page, which
checks a Session variable to determine if a user is logged in. If the user has been logged in, they are allowed
to view the page; if, however, the user has not been logged in, they are redirected to a login page.
However, it's important when sending someone to the login page that you "remember" the page they were trying to
access so that you redirect the user back to the original request once they have successfully logged in.
Hence you need to pass the URL of the page they originally tried to request to the login page so that the
login page knows how to get the user back to their originally-requested page!
The two basic methods for doing this are either placing the URL in a
hidden variable or in the querystring. The Simple Authentication
article uses both: on each page that checks the Session variable to determine if the user is not logged in, the
user is sent to the Login page (
Authenticate.asp) and the current URL is passed through the querystring
Server.UrlEncode; once in
Authenticate.asp, the user is prompted for her username/password -
it is at this juncture that the URL is stuffed into a hidden form variable and passed along to the validation page
Validate.asp) once the user submits the login form.
Personally, I generally prefer sticking with the querystring approach for all instances. One main reason is
because you can run into problems with client proxy servers caching pages, but other
advantages may include not having those annoying refresh warnings when you
hit the back button, the ability to bookmark/email the link, etc.
Ok, now that you know how to encode, you may be wondering how in the world to decode. Fortunately,
it's quite simple - in fact, you don't have to do anything different! Just use
like you normally do to read values from the querystring - the decoding (the coversion from the ASCII equivalent of
non-alphanumeric characters back to their original character form) will occur automagically. If you think
Request.Querystring does, it will make sense.
Let's look at a complete example that both encodes a querystring and then reads it in from another page. Let's take our string from before:
At this point
strEncodedURL has the value:
If we attach it to the URL of our login page while performing a redirect:
Then our login URL becomes:
Now, to read the original link back from
login.asp all we need to do is call
like we normally would:
which returns the original value, i.e.,