By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,386 Members | 1,676 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,386 IT Pros & Developers. It's quick & easy.

What charset the IIS uses to decode POST request?

P: n/a
Hallo,

I am working on multilingual web-application, and I have to be very sure
about how the international characters are encoded and decoded in the
client-server form requests.

There's a great article about the issue:
http://ppewww.ph.gla.ac.uk/~flavell/...form-i18n.html

Generally, that states that this are is filled with landmines. From my tests
I see that form content upon POST request is encoded using the character
encoding from the html page that hosted the form. However, there is no
information about the used codepage in the POST request, and the server side
has somehow to guess it so that it can decode the data properly and populate
the Request.Form collection. My tests show that if the requester page is
plain html with utf-8 codepage Content-Type metatag, the serverside
sometimes does, but most time fails to decode the characters properly.

So, my question is, what codepage is used when interpreting and decoding the
POST request data anf Request.Form collection is populated? I cuold write my
own interpreter that takes the data out from Request.BinaryRead(), but I
would prefer to use the default Request.Form collection tough.

Thanks,
-- Pavils
Jul 19 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
My sympathies. You may have noticed my posts on this question, and also the
lack of any response. Yes, that link has a super discussion of the issue.

The route I took was to end-run the problem by converting the input at POST
time to 7-bit-safe stuff, filled into a hidden field. In addition to a
database record of the input, I was trying to generate data for an RTF file
as a possible output, and while the database contents were handled correctly
in both directions, I could find nothing on its format for purposes of
converting to the "hex Unicode" Code-page format that RTF requires.

That is, a two-byte UTF-8 Cyrillic character was converted to a 4-byte
value, and I couldn't discern the conversion algorithm. I expect it's
related to a double conversion. A couple of cuts at reverse-engineering
failed. If you succeed, pls share the solution.

FYI, I used the Javascript charCodeAt() function for the client-side
conversion. HTH a bit more than just sympathy.

AS
Jul 19 '05 #2

P: n/a
Hi, Pavils

ASP uses ANSI code page to decode source data. You have to explicitly
specify utf-8 code page to work correctly with form data:
<%@ Codepage=65001 %>

BTW. I worked a lot of time to create component working with form-data,
any code page, accepting up to 2GB of multipart and url-encoded form data
(Request.Form has a 100kB limit). You can find it at http://www.pstruh.cz
(Huge-ASP upload)

Antonin
"Pavils Jurjans" <pa****@mailbox.riga.lv> wrote in message
news:#i**************@TK2MSFTNGP12.phx.gbl...
Hallo,

I am working on multilingual web-application, and I have to be very sure
about how the international characters are encoded and decoded in the
client-server form requests.

There's a great article about the issue:
http://ppewww.ph.gla.ac.uk/~flavell/...form-i18n.html

Generally, that states that this are is filled with landmines. From my tests I see that form content upon POST request is encoded using the character
encoding from the html page that hosted the form. However, there is no
information about the used codepage in the POST request, and the server side has somehow to guess it so that it can decode the data properly and populate the Request.Form collection. My tests show that if the requester page is
plain html with utf-8 codepage Content-Type metatag, the serverside
sometimes does, but most time fails to decode the characters properly.

So, my question is, what codepage is used when interpreting and decoding the POST request data anf Request.Form collection is populated? I cuold write my own interpreter that takes the data out from Request.BinaryRead(), but I
would prefer to use the default Request.Form collection tough.

Thanks,
-- Pavils

Jul 19 '05 #3

P: n/a
Thanks, Antonin,

This bit of info was the last one to complete my puzzle. Now I'm happy (tm).

Yes, I know of your site and the great components you have made. In this
case, I am looking for more tech insight on the POST format problems. I have
my own pure-ASP upload in JScript working very fine, and I prefer to stay
with pure code class, because then I have full control of what happens
inside.

Regards,

-- Pavils

"Antonin Foller" <an*****@foller.cz> wrote in message
news:ud*************@TK2MSFTNGP09.phx.gbl...
Hi, Pavils

ASP uses ANSI code page to decode source data. You have to explicitly
specify utf-8 code page to work correctly with form data:
<%@ Codepage=65001 %>

BTW. I worked a lot of time to create component working with form-data, any code page, accepting up to 2GB of multipart and url-encoded form data
(Request.Form has a 100kB limit). You can find it at http://www.pstruh.cz
(Huge-ASP upload)

Antonin

Jul 19 '05 #4

P: n/a
Arnold, I think I may help you with your issues. Just make you contactable,
mail me or ICQ: 4047612

-- Pavils

"Arnold Shore" <do**@bother.me> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
My sympathies. You may have noticed my posts on this question, and also the lack of any response. Yes, that link has a super discussion of the issue.

The route I took was to end-run the problem by converting the input at POST time to 7-bit-safe stuff, filled into a hidden field. In addition to a
database record of the input, I was trying to generate data for an RTF file as a possible output, and while the database contents were handled correctly in both directions, I could find nothing on its format for purposes of
converting to the "hex Unicode" Code-page format that RTF requires.

That is, a two-byte UTF-8 Cyrillic character was converted to a 4-byte
value, and I couldn't discern the conversion algorithm. I expect it's
related to a double conversion. A couple of cuts at reverse-engineering
failed. If you succeed, pls share the solution.

FYI, I used the Javascript charCodeAt() function for the client-side
conversion. HTH a bit more than just sympathy.

AS

Jul 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.