From: Marc Portier
snip/
So as a recap:
Given the fact that todays browser behaviour is coupling
1. the encoding of the HTML-stream (from server to browser)
describing
the form
to
2. the encoding used to encode the request params in the HTTP-request
hosting the form-submit (from
Yes, thank you Marc!
I would prefer iso-8859-1 but this is just a feeling and no opinion
based on facts ;-)
me, too
IIRC correctly at dff we had some encoding issues in the past
...all I remember was we switched to to iso-8859-1 and they
were gone.
...but they might have been caused by the exact
Joerg Heinicke wrote:
On 03.11.2003 11:01, Reinhard Poetz wrote:
Yes, thank you Marc!
I would prefer iso-8859-1 but this is just a feeling and no opinion
based on facts ;-)
Even if it's only one parameter to change I would like to support
non-ISO-characters by default and so prefer UTF-8.
From: Marc Portier
OK,
Thx to Carsten's suggestions I have a patch for this that
rougly looks like
1/ in src/java/org/apache/cocoon/Constants.java
. add constant CONTEXT_DEFAULT_ENCODING
2/ in
src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java
.
On 01.11.2003 12:08, Reinhard Poetz wrote:
personally I think this patch should come together with a
change to our
web.xml so we rather change the default form-encoding to be
also utf-8
sorry, I don't understand this. Does this mean the general encoding is
iso-8859-1 and the form encoding is
On Sat, 2003-11-01 at 12:24, Joerg Heinicke wrote:
On 01.11.2003 12:08, Reinhard Poetz wrote:
personally I think this patch should come together with a
change to our
web.xml so we rather change the default form-encoding to be
also utf-8
sorry, I don't understand this. Does this
Now I'm confused ...
With the container encoding all resources are read, i.e. my text files
and the request. The form encoding only recodes the request parameters
to the expected (i.e. container) encoding. So it works like a servlet
filter.
Joerg
On 01.11.2003 12:36, Bruno Dumon wrote:
On
On Sat, 2003-11-01 at 12:58, Joerg Heinicke wrote:
Now I'm confused ...
With the container encoding all resources are read, i.e. my text files
and the request.
Nope, these are two different encodings:
* text files are read according to whatever encoding/locale is
configured in your OS
Reinhard Poetz wrote:
The parameter CONTEXT_DEFAULT_ENCODING is set in Constants.java - how
can I override this value?
you don't:
it's value IS NOT the encoding, it's value is just the lookup-key inside
the context to read the DEFAULT_ENCODING
as for the remaining question 'where do I set the
be augmented with access to this
kind of 'global' info?
-marc=
Carsten
-Original Message-
From: Marc Portier [mailto:[EMAIL PROTECTED]
Sent: Friday, October 31, 2003 2:15 PM
To: [EMAIL PROTECTED]
Subject: [heads up] cocoon's defaults form-encoding and
seerialize-encoding are inconsistent.
Hi
Marc Portier wrote:
However, what does this say about using cocoon outside the
servlet-context?
In every case: I like the idea of using the contextualize() but maybe it
makes more sense if we don't introduce a dependency between
AbstractTextSerializer and servlet.jar?
Ok, that's true
Marc Portier wrote:
Hi all,
we seem to have a smaal inconsistency concerning encoding of HTML forms
- our HTML serializer by default is using the UTF-8 encoding.
(in fact it's set nowhere in the system and is thus left over to xalan
which most likely is going down the easy path of assuming the
Sylvain Wallez wrote:
Marc Portier wrote:
Hi all,
we seem to have a smaal inconsistency concerning encoding of HTML forms
- our HTML serializer by default is using the UTF-8 encoding.
(in fact it's set nowhere in the system and is thus left over to xalan
which most likely is going down the
OK,
Thx to Carsten's suggestions I have a patch for this that rougly looks like
1/ in src/java/org/apache/cocoon/Constants.java
. add constant CONTEXT_DEFAULT_ENCODING
2/ in src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java
. add imports for Contextualizable
. add
14 matches
Mail list logo
