Special Characters in Query String

[SMG]

Hi All,
I have created an application which is working fine and is in about to
launch, now suddenly my mgmt says there are chances that Scrip ID( a
particular id and not prim key) may have special characters like '&,*,),( or
/'

This data(field/key) I am passing this value as a querystring. e.g.

value to be passed : ABC
http://localhost/myProj/abc.aspx?ScripID=ABC
this works fine,

But when I have special characters like [ABC&D] then the value retrieved is
wrong it just retrieves ABC and not complete ID [ABC&D]
value to be passed : ABC&D
http://localhost/myProj/abc.aspx?ScripID=ABC&D

how do I overcome this, I know I can do it like we have %20 for space and
like wise for & there will be something, but this will be a major change to
my application, can I do this at one end some where in web.config or in aspx
page?

Regards,
Shailesh Gajare

[Kim Bach Petersen]

SMG wrote:

But when I have special characters like [ABC&D] then the value retrieved is
wrong it just retrieves ABC and not complete ID [ABC&D]
value to be passed : ABC&D
http://localhost/myProj/abc.aspx?ScripID=ABC&D

how do I overcome this, I know I can do it like we have %20 for space and
like wise for & there will be something, but this will be a major change to
my application, can I do this at one end some where in web.config or in aspx
page?

You have to UrlEncode the string you are passing as a querystring:

strQuery = HttpUtility.Url Encode(strQuery , System.Text.Enc oding.Default)

Kim :o)

[Joerg Jooss]

Kim Bach Petersen wrote:

SMG wrote:

But when I have special characters like [ABC&D] then the value
retrieved is wrong it just retrieves ABC and not complete ID [ABC&D]
value to be passed : ABC&D
http://localhost/myProj/abc.aspx?ScripID=ABC&D

how do I overcome this, I know I can do it like we have %20 for
space and like wise for & there will be something, but this will be
a major change to my application, can I do this at one end some
where in web.config or in aspx page?

You have to UrlEncode the string you are passing as a querystring:

strQuery = HttpUtility.Url Encode(strQuery ,
System.Text.Enc oding.Default)

I suggest using a more web-friendly encoding than some Windows specific
default, e.g. ISO-8859-1 or UTF-8.

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e

[Kim Bach Petersen]

Joerg Jooss wrote:

strQuery = HttpUtility.Url Encode(strQuery ,
System.Text.E ncoding.Default )

I suggest using a more web-friendly encoding than some Windows specific
default, e.g. ISO-8859-1 or UTF-8.

Obviously UTF-8 is to be preferred and in most cases this is the actual
default value returned by System.Text.Enc oding.Default.

Still, in my experience, one needs to use the default rather than
explicitly choosing UTF-8 if the application is to run on _any_ webhotel
without encountering encoding mismatch problems, at least with querystrings.

Kim :o)

[Joerg Jooss]

Kim Bach Petersen wrote:

Joerg Jooss wrote:

strQuery = HttpUtility.Url Encode(strQuery ,
System.Text.Enc oding.Default)

I suggest using a more web-friendly encoding than some Windows
specific default, e.g. ISO-8859-1 or UTF-8.

Obviously UTF-8 is to be preferred and in most cases this is the
actual default value returned by System.Text.Enc oding.Default.

Still, in my experience, one needs to use the default rather than
explicitly choosing UTF-8 if the application is to run on any
webhotel without encountering encoding mismatch problems, at least
with querystrings.

You're confusing the need to use Windows-1252 with the need to use
Encoding.Defaul t.

For Western European and US Windows OSs Encoding.Defaul t will be an
instance of Windows-1252, but for other configurations it won't.
Relying on platform or installation dependent default values impairs
your application's portability.

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e

[Juan T. Llibre]

re:

Obviously UTF-8 is to be preferred
Why ?

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Kim Bach Petersen" <in*******@spam .dk> wrote in message
news:eP******** ********@TK2MSF TNGP12.phx.gbl. .. Joerg Jooss wrote:

strQuery = HttpUtility.Url Encode(strQuery ,
System.Text. Encoding.Defaul t)

I suggest using a more web-friendly encoding than some Windows specific
default, e.g. ISO-8859-1 or UTF-8.

Obviously UTF-8 is to be preferred and in most cases this is the actual default value
returned by System.Text.Enc oding.Default.

Still, in my experience, one needs to use the default rather than explicitly choosing
UTF-8 if the application is to run on _any_ webhotel without encountering encoding
mismatch problems, at least with querystrings.

Kim :o)

[Joerg Jooss]

Juan T. Llibre wrote:

re:

Obviously UTF-8 is to be preferred

Why ?

Globalization -- assuming you serve mostly content based on Western
European languages but don't want to get stuck with any 8 bit encodings
like ISO-8859-x.

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e

[Juan T. Llibre]

re:

assuming you serve mostly content based on Western European languages
That's a mighty big assumption to make, don't you think ?

Even so, using UTF-8, I haven't found a way
to display characters in the high-ascii 128-255 range,
which several Western European languages require.

I've been able to do that by using iso-8859-1.

Can you post a sample, using utf-8,
which displays characters in the high-ascii 128-255 range ?

I'd be a bit more liable to believe you if you did.

Specifically, if you could show me how to display the
characters ñ, Ñ, ¡, ¿, á, é, í, ó, and ú with utf-8, I'd be grateful.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Joerg Jooss" <ne********@joe rgjooss.de> wrote in message
news:xn******** ********@msnews .microsoft.com. .. Juan T. Llibre wrote:

re:

> Obviously UTF-8 is to be preferred

Why ?

Globalization -- assuming you serve mostly content based on Western
European languages but don't want to get stuck with any 8 bit encodings
like ISO-8859-x.

Cheers,
http://www.joergjooss.de

[Joerg Jooss]

Juan T. Llibre wrote:

re:

assuming you serve mostly content based on Western European
languages
That's a mighty big assumption to make, don't you think ?

No, not all. It just doesn't make sense to use UTF-8 from a bandwidth
perspective once you need to serve a lot of content in on other
languages or scripts, as one character may require up to six bytes.
Even so, using UTF-8, I haven't found a way
to display characters in the high-ascii 128-255 range,
which several Western European languages require.
Then you've been doing something wrong. Let me quote the Unicode
standard document:

"The Unicode Standard provides 1,114,112 code points, most of which are
available for encoding of characters. The majority of the common
characters used in the major languages of the world are encoded in the
first 65,536 code points, also known as the Basic Multilingual Plane
(BMP). The overall capacity for more than a million characters is more
than sufficient for all known character encoding requirements,
including full coverage of all minority and historic scripts of the
world."

There's no civilized 8 bit encoding that cannot be replaced by Unicode
;-)
I've been able to do that by using iso-8859-1.
If you can display your characters with ISO-8859-1, you have
accidentally or willingly switched the response encoding.
Can you post a sample, using utf-8,
which displays characters in the high-ascii 128-255 range ?
Let's avoid the errors of the past -- there's no such thing as Hi ASCII
or 8 bit ASCII. US-ASCII and all its localized clones (ISO-646-xx) are
7 bit. ISO-8859-x, Windows-125x are built "on top of" US-ASCII.

If you want to see UTF-8 in real live, feel free to visit my homepage
which is running dasBlog and serves content in UTF-8.
I'd be a bit more liable to believe you if you did.

Specifically, if you could show me how to display the
characters ñ, Ñ, ¡, ¿, á, é, í, ó, and ú with utf-8, I'd be grateful.

OK, do the following:

1. Create a new WebForm in a new ASP.NET project. Make sure that your
web.config's <globalizatio n/> looks like this:
<globalizatio n
requestEncoding ="utf-8"
responseEncodin g="utf-8" />

2. Add a Label control to the WebForm, call it "label" and set its text
in the property control to the empty string.

3. Implement the Page_Load method like this:
this.label.Text = "ñ, Ñ, ¡, ¿, á, é, í, ó, and ú";

4. Run the WebForm -- it should display the text given above.

And that's pretty much it.

See, once you have the characters in a string object and the page is
not rendered correctly, one of the following errors may have occurred:

-- Your browser is configured to use a fixed encoding, which does not
match andf is not compatible with the real encoding (like ISO-8859-1
vs. UTF-8 for non-ASCII content). This will lead to weird or missing
characters in web pages (responses).

-- Neither the HTTP response nor the HTML source specify the character
encoding. In that case, the browser must guess, and of course it can
guess wrong. This should never happen with any decent web application
technology. ASP.NET for example sends a proper
Content-Type: text/html; charset=utf-8
HTTP header.

Then there's the case that you have a build-time error. In the example
given above, I've hardcoded the string in my source file. The ASP.NET
page processor needs to know the source file's encoding to decode these
characters correctly -- that's what the fileEncoding attribute of the
<globalizatio n/> element does. If you'd changed that attribute to an
incompatible one or one that cannot represent a given character, that
particular character would be already missing in the resulting string
object. This isn't usually a problem as display text belongs into
satellite assemblies anyway, but for simple applications this needs to
be kept in mind.

I hope this helps.

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e

[Juan T. Llibre]

Hi, Joerg.

Take a look at the result :
http://asp.net.do/test/utf-8.aspx
( Browsing it with IE6 set to use utf-8 results in the same.)

Now, look at the same code, using iso-8859-1 :
http://asp.net.do/test3/iso-8859-1.aspx
( Browsing with IE6 set to "Auto-select",
results in Western European getting selected.)

I've had numerous problems with utf-8, all of which result
in common characters in spanish not geting displayed.

Using iso-8859-1 gets rid of the problems.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Joerg Jooss" <ne********@joe rgjooss.de> wrote in message
news:xn******** ********@msnews .microsoft.com. ..

Juan T. Llibre wrote:

re:

> assuming you serve mostly content based on Western European
> languages

That's a mighty big assumption to make, don't you think ?

No, not all. It just doesn't make sense to use UTF-8 from a bandwidth
perspective once you need to serve a lot of content in on other
languages or scripts, as one character may require up to six bytes.

Even so, using UTF-8, I haven't found a way
to display characters in the high-ascii 128-255 range,
which several Western European languages require.

Then you've been doing something wrong. Let me quote the Unicode
standard document:

"The Unicode Standard provides 1,114,112 code points, most of which are
available for encoding of characters. The majority of the common
characters used in the major languages of the world are encoded in the
first 65,536 code points, also known as the Basic Multilingual Plane
(BMP). The overall capacity for more than a million characters is more
than sufficient for all known character encoding requirements,
including full coverage of all minority and historic scripts of the
world."

There's no civilized 8 bit encoding that cannot be replaced by Unicode
;-)

I've been able to do that by using iso-8859-1.

If you can display your characters with ISO-8859-1, you have
accidentally or willingly switched the response encoding.

Can you post a sample, using utf-8,
which displays characters in the high-ascii 128-255 range ?

Let's avoid the errors of the past -- there's no such thing as Hi ASCII
or 8 bit ASCII. US-ASCII and all its localized clones (ISO-646-xx) are
7 bit. ISO-8859-x, Windows-125x are built "on top of" US-ASCII.

If you want to see UTF-8 in real live, feel free to visit my homepage
which is running dasBlog and serves content in UTF-8.

I'd be a bit more liable to believe you if you did.

Specifically, if you could show me how to display the
characters ñ, Ñ, ¡, ¿, á, é, í, ó, and ú with utf-8, I'd be grateful.

OK, do the following:

1. Create a new WebForm in a new ASP.NET project. Make sure that your
web.config's <globalizatio n/> looks like this:
<globalizatio n
requestEncoding ="utf-8"
responseEncodin g="utf-8" />

2. Add a Label control to the WebForm, call it "label" and set its text
in the property control to the empty string.

3. Implement the Page_Load method like this:
this.label.Text = "ñ, Ñ, ¡, ¿, á, é, í, ó, and ú";

4. Run the WebForm -- it should display the text given above.

And that's pretty much it.

See, once you have the characters in a string object and the page is
not rendered correctly, one of the following errors may have occurred:

-- Your browser is configured to use a fixed encoding, which does not
match andf is not compatible with the real encoding (like ISO-8859-1
vs. UTF-8 for non-ASCII content). This will lead to weird or missing
characters in web pages (responses).

-- Neither the HTTP response nor the HTML source specify the character
encoding. In that case, the browser must guess, and of course it can
guess wrong. This should never happen with any decent web application
technology. ASP.NET for example sends a proper
Content-Type: text/html; charset=utf-8
HTTP header.

Then there's the case that you have a build-time error. In the example
given above, I've hardcoded the string in my source file. The ASP.NET
page processor needs to know the source file's encoding to decode these
characters correctly -- that's what the fileEncoding attribute of the
<globalizatio n/> element does. If you'd changed that attribute to an
incompatible one or one that cannot represent a given character, that
particular character would be already missing in the resulting string
object. This isn't usually a problem as display text belongs into
satellite assemblies anyway, but for simple applications this needs to
be kept in mind.

I hope this helps.

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e