What charset the IIS uses to decode POST request?

[Pavils Jurjans]

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.BinaryR ead(), but I
would prefer to use the default Request.Form collection tough.

Thanks,
-- Pavils

[Arnold Shore]

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

[Antonin Foller]

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******** ******@TK2MSFTN GP12.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.BinaryR ead(), but I
would prefer to use the default Request.Form collection tough.

Thanks,
-- Pavils

[Pavils Jurjans]

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******** *****@TK2MSFTNG P09.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

[Pavils Jurjans]

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******** ********@TK2MSF TNGP11.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