469,919 Members | 2,091 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,919 developers. It's quick & easy.

Error decoded 8 bit characters.

Hello:

We ran into an issue with the decoding 8 bit characters. We have an
asp page that makes a call to an ashx page. When the HTTPHandler
accesses the query string we find that the 8 bit characters are
stripped. The source asp page is encoding using ISO-Western European
(windows-1252) single byte encoding. I am assuming that the .Net
framework uses the Unicode (UTF8) as the basis for decoding the URL.
Now we managed to get this to work by explicitly requesting that the
HTTPHandler use Windows-1252 for encoding/decoding:

<globalization
requestEncoding="Windows-1252"
responseEncoding="Windows-1252"/>

This works when the URL is passed using a single byte encoding but it
breaks when multi-byte encoding on the URL is used by the source page.
SO the solution is not extensible. This brings up a few questions:

1) Is there a way to programatically indicate the responseEncoding
using an aspx page.
2) Has anyone had luck with a more flexible approach to handling the
encoding/decoding of characters w/o have in to hard code the encoding
in the web.config.

Please let me know,
Thanks
Nov 18 '05 #1
2 1496
T Conti wrote:
Hello:

We ran into an issue with the decoding 8 bit characters. We have an
asp page that makes a call to an ashx page. When the HTTPHandler
accesses the query string we find that the 8 bit characters are
stripped. The source asp page is encoding using ISO-Western European
(windows-1252) single byte encoding. I am assuming that the .Net
framework uses the Unicode (UTF8) as the basis for decoding the URL.
Now we managed to get this to work by explicitly requesting that the
HTTPHandler use Windows-1252 for encoding/decoding:

<globalization
requestEncoding="Windows-1252"
responseEncoding="Windows-1252"/>

This works when the URL is passed using a single byte encoding but it
breaks when multi-byte encoding on the URL is used by the source page.
SO the solution is not extensible. This brings up a few questions:

1) Is there a way to programatically indicate the responseEncoding
using an aspx page.
Yes. You can set the property HttpResponse.ContentEncoding.
2) Has anyone had luck with a more flexible approach to handling the
encoding/decoding of characters w/o have in to hard code the encoding
in the web.config.


On general: if your clients are properly communicating the appropriate
encoding, you can retrieve that value from the HTTP request and apply it. If
they don't, you're out of luck.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

Nov 18 '05 #2
T Conti wrote:
Hello:

We ran into an issue with the decoding 8 bit characters. We have an
asp page that makes a call to an ashx page. When the HTTPHandler
accesses the query string we find that the 8 bit characters are
stripped. The source asp page is encoding using ISO-Western European
(windows-1252) single byte encoding. I am assuming that the .Net
framework uses the Unicode (UTF8) as the basis for decoding the URL.
Now we managed to get this to work by explicitly requesting that the
HTTPHandler use Windows-1252 for encoding/decoding:

<globalization
requestEncoding="Windows-1252"
responseEncoding="Windows-1252"/>

This works when the URL is passed using a single byte encoding but it
breaks when multi-byte encoding on the URL is used by the source page.
SO the solution is not extensible. This brings up a few questions:

1) Is there a way to programatically indicate the responseEncoding
using an aspx page.
Yes. You can set the property HttpResponse.ContentEncoding.
2) Has anyone had luck with a more flexible approach to handling the
encoding/decoding of characters w/o have in to hard code the encoding
in the web.config.


On general: if your clients are properly communicating the appropriate
encoding, you can retrieve that value from the HTTP request and apply it. If
they don't, you're out of luck.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

Nov 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.