Product Manager, Storage - READY TO HIRE! (PA) Next Step Systems US-PA-Wayne Post A Job | Post A Resume

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. Basically, the 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:

calling Server.URLencode(strURL) would return:

http%3A%2F%2Fwww%2E4guysfromrolla%2Ecom%2Fdefault%2Easp%3Fid%3D123%26usr%3Dbob

[View the live demo!]

You may be wondering, for good reason, why (and how on Earth) the Server.UrlEncode method 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:

<a href="http://www.myserver.com/SomePage.asp?URL=http://www.4guysfromrolla.com/default.asp?id=123&usr=bob">    Click me! </a>

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=http://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 value being http://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 (URL=http://www.4guysfromrolla.com/default.asp?id=123 and 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 using 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 Request.Querystring 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 about what 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:

strURL = "http://www.4guysfromrolla.com/default.asp?id=123&usr=bob" 'Now, encode the string strEncodedURL = Server.URLencode(strURL)

At this point strEncodedURL has the value:

http%3A%2F%2Fwww%2E4guysfromrolla%2Ecom%2Fdefault%2Easp%3Fid%3D123%26usr%3Dbob

If we attach it to the URL of our login page while performing a redirect:

Response.redirect "login.asp?backlink=" & strEncodedURL

Then our login URL becomes:

login.asp?backlink=http%3A%2F%2Fwww%2E4guysfromrolla%2Ecom%2Fdefault%2Easp%3Fid%3D123%26usr%3Dbob

Now, to read the original link back from login.asp all we need to do is call Request.QueryString like we normally would:

Request.Querystring("backlink")

which returns the original value, i.e.,

http://www.4guysfromrolla.com/default.asp?id=123&usr=bob

Pretty cool, huh? If you want, you can view the technical docs for Server.UrlEncode, but they are pretty shabby. (Be sure to view the live demo.) Happy Programming!

WebMediaBrands Corporate Info
Copyright 2009 WebMediaBrands Inc. All Rights Reserved.

Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs