Hi Mark,
Here's some inline replies.
I've run a few simple tests looking at how query string encoding/decoding
gets handled in asp.net, and it seems like the situation is even messier
than it was in asp... Can't say I think much of the "improvements", but
maybe someone here can point me in the right direction...
First, it looks like asp.net will automatically read and recognize query
strings encoded in utf8 and 16-bit unicode, only the latter is some mutant,
non-standard encoding mechanism that only works in IIS (%u00f1 for
example). This looks like it's the *only* way to decode querystrings. Too
bad, 'cause browsers out there can encode them all kinds of different ways,
and the way most will get done by default is windows-1252. At least in old
asp, the lazy defaults for putting together your forms and the default
behavior for most browsers would fit well. Seems like there's more active
attention required in asp.net.
This is due to responseEncoding/requestEncoding in <globalization> element
in web.config. The default is UTF-8. You can modify this to windows-1252
if you want. UTF-8 is much better.
For IE, it will encode the url (unless you type it directly into the
address bar) according to the following: Response.Charset, Charset header,
then <meta> tag. Using the responseEncoding will send the Charset header.
If you simply type the address into the address, I believe that it is
encoded with the system codepage.
Second, it no longer appears to be using the page's declared output
encoding as a means of interpreting the input (both good and bad, i guess).
This means if it runs into a character in the querystring that's *not*
encoded utf-8 or mutant, it just drops that character out of the input.
Period. No way to handle it. Accented spanish characters, for example,
that most browsers are going to encode in 1252 (i.e. %f1 for ?) just vanish
from the asp.net environment.
It does use the declared output encoding, but this encoding is not where
you expect. It is in <globalization> in web.config.
If you do expect to get upper ascii characters, you can use the following
code in Global.asax in the Application_BeginRequest event:
protected void Application_BeginRequest(Object sender, EventArgs e)
{
//Fires at the beginning of each request
string str;
str = Request.QueryString.ToString();
string delimStr = "%"
char [] delimiter = delimStr.ToCharArray();
string [] split = null;
split = str.Split(delimiter, 2);
if (split.Length <= 1)
{
System.Web.HttpContext.Current.RewritePath(Request .RawUrl.ToString());
}
}
or
Dim str As String
str = Server.UrlPathEncode(Request.RawUrl)
System.Web.HttpContext.Current.RewritePath(str)
Third, in asp, when you have more than one value for a query string
variable name, referencing the Request object gives you a collection. Now
that collection has a toString method that makes a comma-separated list of
the values but you *can* refer to each of the different values separately.
In asp.net, the NameValueCollection mashes multiple values into a single
comma-separated string so if your input has commas in it, well too bad.
In ASP and ASP.NET, you get a collection when referencing the querystring
object.
The comment about the NameValueCollection is the exact same behaviour as in
asp.
Example: using the following querystring gives the following results:
http://kronicas26/Converting/P1.asp?id=5&id=9&test=7
ASP
Code:
<%
Response.Write Request.QueryString & "<BR>"
dim o
for each o in Request.QueryString
Response.Write "Key: " & o & " Value: " & Request.QueryString(o) & "<BR>"
next
%>
Output:
id=5&id=9&test=7
Key: id Value: 5, 9
Key: test Value: 7
ASP.NET
http://kronicas26/ssCS/webform1.aspx?id=5&id=9&test=7
Code:
Response.Write(Request.QueryString.ToString() + "<BR>");
foreach(string t in Request.QueryString.Keys)
{
Response.Write("Key :" + t + " Value: " + Request.QueryString[t] +
"<BR>");
}
Output:
id=5&id=9&test=7
Key :id Value: 5,9
Key :test Value: 7
This shows there is no difference in querystring handling between asp and
asp.net as far as the collection behaviour goes.
Fourth, in asp Request.QueryString gives you the original urlencoded bytes
of the querystring i.e. what you were sent. In asp.net, it's actually a
re-urlencoding of the post-interpreted values, so you can't get out what
you got in... This is most annoying when you get a querysting encoded in
utf-8; referencing Request.QueryString returns you a value encoded in the
mutant %uxxxx syntax instead in asp.net.
If you want to get the original querystring, use Request.RawUrl. This
property is not encoded, and is pulled straight from the aspnet_isapi.dll.
I'm just getting my feet wet in asp.net, coming from an asp environment.
Any pointers on how to handle query string issues better than what appears
to be the default in asp.net? Seems like there are some steps backwards in
asp.net.
If you want things to behave like they did in asp, at least as far as
encoding issues go, do the following:
In web.config, set <globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
/>
To
<globalization
requestEncoding="windows-1252"
responseEncoding=" windows-1252"
/>
And use Response.Charset and session.codepage. Windows-1252 is a single
byte encoding scheme, and multibyte characters will pass through unchanged.
Thanks,
Earl Beaman
Microsoft, ASP.NET
This posting is provided "AS IS", with no warranties, and confers no
rights.