Home

ASP ADVANCED

A query string is the extra portion of the URL that appears after the question mark. If you've ever used Internet search engines such as Alta Vista, you'll be familiar with query strings. Those extra characters that clutter up the address bar of your browser when you use a search engine are an example of a query string.

You can use a query string with a hyperlink to pass information from one page to another. For instance, consider the following HTML page:

<HTML>
<HEAD><TITLE> Query string Example </TITLE></HEAD>
<BODY>
<A HREF="http://www.aspsite.com/newpage.asp?Click=YES"> Click Me! </A>
</BODY>
</HTML>

In this example, the hyperlink links to the page named newpage. asp. However, the hyperlink also includes a query string. When someone clicks the words Click Me!, the query string "Click=Yes" is passed in the request for the new page.

You can also pass a query string directly by typing it into the address bar of your browser. The server won't know the difference. For example, typing the following string into the address bar of your Web browser would have the same effect as clicking the hyperlink in the preceding example:

http://www.aspsite.com/newpage.asp?Click=Yes

Query strings are useful when you need to present a menu of choices. If you have a number of hyperlinks that link to the same page, you can use a query string to determine the particular hyperlink that was clicked. Consider the following example:

<HTML>
<HEAD><TITLE> Product List </TITLE></HEAD>
<BODY>
<H3> welcome To Our Store! </H3>
Please select the item you want to purchase from the list below:
<P><A HREF="/purchase.asp?ITEM=1"> Used Book </A>
<P><A HREF="/purchase.asp?ITEM=2"> Broken Typewriter </A>
<P><A HREF="/Purchase.asp?ITEM=3"> Horseshoe </A>
</BODY>
</HTML>

This page presents a number of items from which a visitor can select to buy (see Figure below). Each item description is a hyperlink. When the user clicks any of the items, he or she is linked to the purchase. asp page.

A Page With a List of Items For Sale

To detect the selection of the buyer, you need to determine which hypertext link was clicked. You need to determine this within the purchase.asp page. Each hypertext link is uniquely identified by a query string. How do you retrieve this information?

Query strings are passed in an HTTP request. Therefore, you shouldn't be surprised to learn that the Active Server Pages Request object has a collection for query strings. Query strings are contained in the Querystring collection of the Request object.

You can retrieve the items in the QueryString collection in the same way that you retrieve the items in the Form collection. To retrieve a particular query string, you simply pass the name of that query string. Here's an example:

<HTML>
<HEAD><TITLE> Purchase </TITLE></HEAD>
<BODY>
SELECT CASE Request.QueryString("item")
CASE "l"
Response.Write("Thank you for Purchasing a used book.")
CASE "2"
Response.write("Thank you for purchasing a broken typewriter.")
CASE "3"
Response.Write("Thank you for purchasing a horseshoe.")
END SELECT
%>
</BODY>
</HTML>

The Querystring collection is used in this example to determine which hyperlink was clicked. The SELECT CASE statement returns an appropriate response, depending on the query string. For example, if someone selected to buy a horseshoe, the user is thanked for purchasing that particular item.

Encoding a Query String

A query string must be URL-encoded before it can be passed from one page to another. For example, all spaces must be converted to addition signs. If you neglect to URL-encode a query string, you may get strange results.

Fortunately,' it's very easy to URL-encode a query string using Active Server Pages. There's a method for this particular purpose. The server. URLEnoode( ) method converts any string to URL-encoded form. Look at this example:

<A HREF="/response.asp?Message=<%=Server.URLEncode("This query string has been URL encoded.")%>"> Click Here </A>

Notice that you don't URL-encode the name of the query string or the equal sign. Doing this would create problems. You only URL-encode the value of a query string.

Once the query string in the previous example has been URL-encoded, it looks like this:

Message=This+query+string+has+been+URL+encoded%2E

You don't need to worry about decoding a string that has been URL-encoded. Active Server Pages will do this for you
automatically. For example, suppose the response.asp page included the following line of code:

<%=Request.QueryString("message")%>

The message wouldn't be outputted in URL-encoded form. It would look like this:

This query string has been URL encoded.

Query Strings with Multiple Parameters and Multiple Values

You can pass more than one name and value pair in a query string. In other words, you can create a query string with multiple parameters. To pass multiple parameters, simply join them together using the ampersand (&) character. The following query string passes two parameters:

<A HREF="/response.asp?FirstParam=<%=Server.URLEncode("This is the first parameter.")%>&SecondParam=<%=Server.URLEncode("This is the second parameter.")%>"> Click Here </A>

This query string includes two parameters named FirstParam and SecondParam. FirstParam has the value "This is the first parameter. ' SecondParam has the value "This is the second parameter." The Server.URLEncode( ) method is used to convert the values of the parameters so they can be properly passed.

In the response.asp page, you can output the values of the two parameters like this:

By passing the name of a query string parameter to the Querystring collection, you retrieve the value of the parameter. The output from the previous two statements would appear like this:

This is the first parameter.

This is the second parameter.

You can also assign a single parameter more than one value. To do this, simply use the name of the parameter twice in the query string. Following is an example:

<A HREF="/response.asp?OnlyParam=<%=Server.URLEncode("I am the first value of the only parameter.")%>&OnlyParam=<%=Server.URLEncode('I am the second value of the only parameter.")%>"> Click Here </A>

In this example, the parameter named OnlyParam is assigned a value twice, First the parameter is assigned the value "I am the first value of the only parameter. " Next, the parameter is assigned the value "I am the second value of the only parameter."

Once you have assigned a single parameter with more than one value, you can use the count property to determine the number of values of the parameter. The following example displays a count of the number of values of the OnlyParam parameter and then displays each value:

The OnlyParam parameter has
<%=Request.QueryString("OnlyParam").Count%> values.
<P>They are:
<%
FOR EACH pvalue IN Request.QueryString("OnlyParam")
Response.Write("<BR>"&pvalue)
NEXT
%>

The FOR... EACH loop iterates through each value of the OnlyParam parameter. If the OnlyParam parameter has zero values, the Count property would return 0 and no values would be displayed.

Dumping the QueryString Collection

If you want to retrieve all the parameters in the QueryString collection, you can iterate through the collection using a FOR ... EACH loop. For example, the following script dumps the contents of the QueryString collection to the screen:

<%
FOR EACH QSParam IN Request.QueryString
Response.Write("<BR>"&QSParam&"=')
Response.Write(Request.QueryString(QSParam)
NEXT
%>

Instead of using a FOR... EACH loop, you can also use a FOR ... NEXT loop to dump the query string collection. To do this, you need to determine the number of items in the QueryString collection. You can use the Count property to recover this information. Here's an example:

<%
FOR i=1 TO Request.QueryString.Count
Response.Write("<BR>"&Request.QueryString(i))
NEXT
%>

Finally, if you simply prefer to retrieve an unparsed query string, you can call the Request.QueryString collection with no parameters.

<%=Request.QueryString %>

When Not to Use Query Strings

Query strings are useful when you need to pass small bits of information from one page to another, but there are two situations in which you definitely shouldn't use a query string: when you're passing hidden information, and when you're passing large chunks of data.

A query string isn't hidden from view in any way. The query string will always appear in the address bar of a browser. This means that passing the password of a user from page to page with a query string is a very bad idea. Anyone looking over the user's shoulder will immediately know the password.

Query strings are also not a good choice for passing large chunks of data. The exact number of characters that a query string can contain depends on a number of factors. One of the main factors is the browser being used. Different browsers have different limitations on query string size. For example, Microsoft Internet Explorer 4.0 can't handle a query string that's larger than about 2,000 characters. A hyperlink with a query string of this size will simply fail to work as a hyperlink with this browser.

You shouldn't conclude from this fact that you can use query strings up to 2,000 characters long. First, the true maximum depends on the length of the URL as well. The combination of the URL and query string--everything in the address bar of the browser--determines the maximum size.

Second, when you URL-encode a query string, this often makes the string considerably longer. For example, periods are converted into three characters (%2E) instead of one. The maximum size of a query string depends on the URL-encoded form of the string.

Third, browsers other than Internet Explorer 4.0 can often handle far fewer than 2,000 characters. Once a query string hits a length of 1,000 characters or so, you risk losing compatibility with a number of browsers.

In brief, it's a good idea to keep your query strings short. Query strings aren't an efficient method of passing large amounts of data. Even worse, a page with a large query string may completely fail to function on certain browsers. If you need to pass a large amount of data from one page to another, use a hidden form field. None of the limitations discussed here applies to form fields. The HTTP protocol passes form fields in a much more efficient way than query strings.