Problem with @Page RequestEncoding

[Guest]

Hello,
in the Web.config I have <globalization requestEncoding="utf-8"
responseEncoding="utf-8" />, but for one page I need to set the
requestEncoding="windows-1250". If I use <%@Page
RequestEncoding="windows-1250"%>, I get an error Atributte RequestEncoding is
not supported by direktive page. What is the problem?

Ondrej Srubar

 

[Guest]

I believe CodePage="1252" is what you need to add to the specific page in
question.

In CodeBehind, you can also use the Response object to set the encoding of a
specific page. This is great when you are controlling the globalization
options programatically.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Juan T. Llibre]

In ASP.NET, System.Web.UI.Page doesn't
have a property named requestEncoding :

http://beta.asp.net/QUICKSTART/util...7f11d50a3a&namespace=System.Web.UI&class=Page

What I would do, if I were you, is place that file in a
subdirectory of your application, with a web config which has :

<globalization
requestEncoding="windows-1250"
responseEncoding="windows-1250"
/>

That will give you the best of both worlds.

 

[Juan T. Llibre]

Cool, but make that CodePage="1250", which is the one he wants.

Setting that CodePage would certainly set the character set to "Windows-1250",
but I'm not sure whether that would affect requestEncoding, though.

You can't set requestEncoding through the Page properties;
you can only set requestEncoding through configuration files.

 

[Guest]

I need requestEncoding="windows-1250" only for one page, which takes request
from another server (i.e. I can't set encoding of a response) and I need all
other pages in utf-8 "(i.e. in the Web.config I need <globalization
requestEncoding="utf-8" responseEncoding="utf-8" />).
If I set a ContentEncoding of the request in code, the property QueryString
is already encoded by utf-8.
And the @Page doesn't have a property named requestEncoding

Ondrej Srubar

 

[Juan T. Llibre]

re:

I need all other pages in utf-8 (i.e. in the Web.config I need
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />)

Maybe I wasn't clear enough.

You *can* place that file in a subdirectory of the *same* application,
and have its encoding set by a different web.config than one which
governs your main application directory and subdirectories.

In *that* web.config, placed in the same directory as
the file which needs windows-1250 encoding, you set :

<globalization
requestEncoding="windows-1250"
responseEncoding="windows-1250"
/>

and that will be the only page which will have that encoding,
as you said you need.

The rest of your pages will have utf-8.

Am I missing something here ?

 

[Joerg Jooss]

re:

Maybe I wasn't clear enough.

You can place that file in a subdirectory of the same application,
and have its encoding set by a different web.config than one which
governs your main application directory and subdirectories.

In that web.config, placed in the same directory as
the file which needs windows-1250 encoding, you set :

<globalization
requestEncoding="windows-1250"
responseEncoding="windows-1250"
/>

Another option is to use the Application_BeginRequest callback, which
overrides any web.config setting:

protected void Application_BeginRequest(Object sender, EventArgs e)
{
if (Request.Path == "/foo/Special.aspx")
{
Request.ContentEncoding = Encoding.GetEncoding(1250);
}
}

Cheers,

 

[Juan T. Llibre]

Quite interesting, Joerg, but why have an application run a procedure
every time *any* page is called, when all that's needed is for a setting
to be made when *one* particular page is called ?

That would seem to run counter to best practices for applications,
in regards to efficient architectural design.

 

[Joerg Jooss]

Quite interesting, Joerg, but why have an application run a procedure
every time any page is called, when all that's needed is for a setting
to be made when one particular page is called ?

Good question!

Well, first I think it's nice to know how to do certain things in code.

Second, assume a more dynamic scenario, where the character encoding is
based on the user's preferences (HTTP Accept-Encoding) or browser type.
Then configuration is no longer an option.

That would seem to run counter to best practices for applications,
in regards to efficient architectural design.

Well, efficiency isn't usually lost or gained at implementation level,
at least for business applications (the usual web app). As an
architect, I'd probably not even care whether a programmer decided to
use this or that approach, as long as the underlying requirement was
techncially fulfilled.

Cheers,