Re: CForms Character Encoding

[Francesco Chicchiriccò]

On 04/12/2012 13:08, Peter Sparkes wrote:

On 04/12/2012 09:15, Peter Sparkes wrote:

On 04/12/2012 08:46, Francesco Chicchiriccò wrote:

On 04/12/2012 09:40, Peter Sparkes wrote:

I am using C.2.11

I have a CForm implementation and there are, in the xml text, 
special characters such as:


£, Â, ⅗ and â

I am using UTF-8 encoding and such characters in the xml file are 
correctly displaced in the CForm and when the form is saved they 
are correctly saved in the xml file.


However, I am building another CForm, within the same Cocoon 
application, this time using the JXTemplate Generator and I am 
having encoding problems; the above characters are not correctly 
saved in the xml file.


In the sitemap I have:





I suspect the locale setting but do not know how to set it to UTF-8


Hi Peter,
did you take a look at [1] and [2] (for C2.2 but most concepts apply 
to C2.1 as well)?


Regards.

[1] http://wiki.apache.org/cocoon/RequestParameterEncoding
[2] http://cocoon.apache.org/2.2/1366_1_1.html


Hi Francesco,

No, but I will now

Thank you

Peter


Hi Francesco,

All working now

Thank you again


You're welcome :-)

Regard.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: CForms Character Encoding

[Peter Sparkes]

On 04/12/2012 09:15, Peter Sparkes wrote:

On 04/12/2012 08:46, Francesco Chicchiriccò wrote:

On 04/12/2012 09:40, Peter Sparkes wrote:

I am using C.2.11

I have a CForm implementation and there are, in the xml text, special 
characters such as:

£, Â, ⅗ and â

I am using UTF-8 encoding and such characters in the xml file are correctly displaced in the 
CForm and when the form is saved they are correctly saved in the xml file.


However, I am building another CForm, within the same Cocoon application, this time using the 
JXTemplate Generator and I am having encoding problems; the above characters are not correctly 
saved in the xml file.


In the sitemap I have:





I suspect the locale setting but do not know how to set it to UTF-8


Hi Peter,
did you take a look at [1] and [2] (for C2.2 but most concepts apply to C2.1 as 
well)?

Regards.

[1] http://wiki.apache.org/cocoon/RequestParameterEncoding
[2] http://cocoon.apache.org/2.2/1366_1_1.html


Hi Francesco,

No, but I will now

Thank you

Peter


Hi Francesco,

All working now

Thank you again

Peter

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: CForms Character Encoding

[Peter Sparkes]

On 04/12/2012 08:46, Francesco Chicchiriccò wrote:

On 04/12/2012 09:40, Peter Sparkes wrote:

I am using C.2.11

I have a CForm implementation and there are, in the xml text, special 
characters such as:

£, Â, ⅗ and â

I am using UTF-8 encoding and such characters in the xml file are correctly displaced in the 
CForm and when the form is saved they are correctly saved in the xml file.


However, I am building another CForm, within the same Cocoon application, this time using the 
JXTemplate Generator and I am having encoding problems; the above characters are not correctly 
saved in the xml file.


In the sitemap I have:





I suspect the locale setting but do not know how to set it to UTF-8


Hi Peter,
did you take a look at [1] and [2] (for C2.2 but most concepts apply to C2.1 as 
well)?

Regards.

[1] http://wiki.apache.org/cocoon/RequestParameterEncoding
[2] http://cocoon.apache.org/2.2/1366_1_1.html


Hi Francesco,

No, but I will now

Thank you

Peter

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: CForms Character Encoding

[Francesco Chicchiriccò]

On 04/12/2012 09:40, Peter Sparkes wrote:

I am using C.2.11

I have a CForm implementation and there are, in the xml text, special 
characters such as:


£, Â, ⅗ and â

I am using UTF-8 encoding and such characters in the xml file are 
correctly displaced in the CForm and when the form is saved they are 
correctly saved in the xml file.


However, I am building another CForm, within the same Cocoon 
application, this time using the JXTemplate Generator and I am having 
encoding problems; the above characters are not correctly saved in the 
xml file.


In the sitemap I have:





I suspect the locale setting but do not know how to set it to UTF-8


Hi Peter,
did you take a look at [1] and [2] (for C2.2 but most concepts apply to 
C2.1 as well)?


Regards.

[1] http://wiki.apache.org/cocoon/RequestParameterEncoding
[2] http://cocoon.apache.org/2.2/1366_1_1.html

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

CForms Character Encoding

[Peter Sparkes]

I am using C.2.11

I have a CForm implementation and there are, in the xml text, special 
characters such as:

£, Â, ⅗ and â

I am using UTF-8 encoding and such characters in the xml file are correctly displaced in the CForm 
and when the form is saved they are correctly saved in the xml file.


However, I am building another CForm, within the same Cocoon application, this time using the 
JXTemplate Generator and I am having encoding problems; the above characters are not correctly saved 
in the xml file.


In the sitemap I have:





I suspect the locale setting but do not know how to set it to UTF-8

Help please

Peter





-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: character encoding of a HttpServletRequest

[Dominic Mitchell]

On Mon, Jan 11, 2010 at 10:34 AM, Jos Snellings wrote:

> That is right!
> It is just a confusing situation :-(
> The filter works fine. The init() method of a generator does not give a
> chance to call setCharacterEncoding, as the parsing already happened.
> The good thing is that the code is already in spring, so, no new
> external dependencies. Maybe later on I add a
> "tryToGuessEncodingFilter".
>
>
Trying to guess encodings isn't a good idea, in general.  About the only one
that can be reliably detected is UTF-8.  In past projects, I've done
something like this:

  String result;
  try {
result = new String(someBytes, "UTF-8");
  catch (EncodingError e) {
result = new String(someBytes, "Windows-1252");
  }

In my experience, Windows-1252 was a better guess than ISO-8859-1, as users
tend to paste in stuff from word documents with curly quotes.

-Dom

Re: character encoding of a HttpServletRequest

[Jos Snellings]

That is right!
It is just a confusing situation :-(
The filter works fine. The init() method of a generator does not give a
chance to call setCharacterEncoding, as the parsing already happened.
The good thing is that the code is already in spring, so, no new
external dependencies. Maybe later on I add a
"tryToGuessEncodingFilter".

Jos

On Mon, 2010-01-11 at 10:49 +0100, Reinhard Pötz wrote:
> Jos Snellings wrote:
> > Hi,
> > 
> > HttpServletRequest looks 'imperfect':
> > Cocoon 3, alpha 2.
> > A generator accesses the HttpServletRequest in the setup method:
> > 
> > request = HttpContextHelper.getRequest(parameters);
> > text = request.getParameter("tekst");
> > 
> > The pages, including forms are ecoded in utf-8.
> > The String 'text' is strange: the original content (utf-8) is encoded
> > once again:
> > if the string on the form was one character, say 'é', the string has a
> > length of 4 bytes. It is the result of utf-8 encoding the two byte
> > character coming from the client. So, a second conversion is happening.
> > 
> > Now:
> > new String(request.getParameter("text").getBytes("ISO-8859-1")) works
> > fine.
> > 
> > Where should this be corrected?
> 
> Jos,
> 
> in Cocoon 3 there isn't any code that changes the encoding of request
> parameters. The plain HttpServletRequest as provided by the servlet
> container is used.
> 
> IIRC Tomcat uses ISO-8859-1 by default which follows the recommendation
> of the Servlet API spec:
> 
> ~~~~~~~
> SRV.4.9 Request data encoding
> Currently, many browsers do not send a char encoding qualifier with the
> Content-Type header, leaving open the determination of the character
> encoding for reading HTTP requests. The default encoding of a request
> the container uses to create the request reader and parse POST data must
> be “ISO-8859-1” if none has been specified by the client request.
> However, in order to indicate to the developer in this case the failure
> of the client to send a character encoding, the container returns null
> from the getCharacterEncoding method.
> If the client hasn’t set character encoding and the request data is
> encoded with a different encoding than the default as described above,
> breakage can occur. To remedy this situation, a new method
> setCharacterEncoding(String enc) has been added to the ServletRequest
> interface. Developers can override the character encoding supplied by
> the container by calling this method. It must be called prior to parsing
> any post data or reading any input from the request. Calling
> this method once data has been read will not affect the encoding.
> ~~~
> 
> So as some others suggested, the best option is using one of the
> CharecterEncoding servlet filters and not to remedy this situation
> somewhere in C3.
> 



-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: character encoding of a HttpServletRequest

[Jos Snellings]

This, to notify you that the solution you suggested works fine:
So, for all cocoon users: if you are experiencing problems with the
character encoding of POST form data (which is very likely to occur):
the problem is generally cured by
Inserting the following code in web.xml


encodingFilter

org.springframework.web.filter.CharacterEncodingFilter

encoding
UTF-8


forceEncoding
true

 

 
encodingFilter
/*
 

(Insert it as the first children under the  root element)

Jos


On Mon, 2010-01-11 at 08:54 +, Dominic Mitchell wrote:
> 2010/1/10 Jos Snellings 
> This is not a specific cocoon issue, I believe. It probably
> has to do
> with Tomcat 5.5.27.
> request.setCharacterEncoding simply does not work; it does not
> change a
> thing.
> request.getCharacterEncoding returns nothing.
> 
> You have to call request.setCharacterEncoding() really early for it to
> have any impact.  Your best bet is to look at spring's
> CharacterEncodingFilter.  You can add that to your web.xml to get the
> character set defined very early on.
> 
> -Dom 
> 
> 



-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: character encoding of a HttpServletRequest

[Reinhard Pötz]

Jos Snellings wrote:
> Hi,
> 
> HttpServletRequest looks 'imperfect':
> Cocoon 3, alpha 2.
> A generator accesses the HttpServletRequest in the setup method:
> 
> request = HttpContextHelper.getRequest(parameters);
> text = request.getParameter("tekst");
> 
> The pages, including forms are ecoded in utf-8.
> The String 'text' is strange: the original content (utf-8) is encoded
> once again:
> if the string on the form was one character, say 'é', the string has a
> length of 4 bytes. It is the result of utf-8 encoding the two byte
> character coming from the client. So, a second conversion is happening.
> 
> Now:
> new String(request.getParameter("text").getBytes("ISO-8859-1")) works
> fine.
> 
> Where should this be corrected?

Jos,

in Cocoon 3 there isn't any code that changes the encoding of request
parameters. The plain HttpServletRequest as provided by the servlet
container is used.

IIRC Tomcat uses ISO-8859-1 by default which follows the recommendation
of the Servlet API spec:

~~~
SRV.4.9 Request data encoding
Currently, many browsers do not send a char encoding qualifier with the
Content-Type header, leaving open the determination of the character
encoding for reading HTTP requests. The default encoding of a request
the container uses to create the request reader and parse POST data must
be “ISO-8859-1” if none has been specified by the client request.
However, in order to indicate to the developer in this case the failure
of the client to send a character encoding, the container returns null
from the getCharacterEncoding method.
If the client hasn’t set character encoding and the request data is
encoded with a different encoding than the default as described above,
breakage can occur. To remedy this situation, a new method
setCharacterEncoding(String enc) has been added to the ServletRequest
interface. Developers can override the character encoding supplied by
the container by calling this method. It must be called prior to parsing
any post data or reading any input from the request. Calling
this method once data has been read will not affect the encoding.
~~~

So as some others suggested, the best option is using one of the
CharecterEncoding servlet filters and not to remedy this situation
somewhere in C3.

-- 
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  reinh...@apache.org


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: character encoding of a HttpServletRequest

[Dominic Mitchell]

On Mon, Jan 11, 2010 at 9:12 AM, Jos Snellings wrote:

> Thanks, I will try CharacterEncodingFilter!
> I will lookup in the code were filtering takes place, because the
> problem is rather that it looks like the form data are filtered twice.
>
> In addition, do I remember right that there used to be a cocoon servlet
> setting,
>
>form-encoding
>UTF-8
>
>
> Cheers, thanks for the hint. I will post the result... I will certainly
> not be the only person who is confronted with this problem.
>

There are so many places to set the encoding.  And just for fun, you can
have different encodings for query string parameters and form-data in the
body in the same request.  Sigh.

I've had good luck with
CharacterEncodingFilterthough.

-Dom

Re: character encoding of a HttpServletRequest

[Jos Snellings]

Thanks, I will try CharacterEncodingFilter!
I will lookup in the code were filtering takes place, because the
problem is rather that it looks like the form data are filtered twice. 

In addition, do I remember right that there used to be a cocoon servlet
setting, 

form-encoding
UTF-8


Cheers, thanks for the hint. I will post the result... I will certainly
not be the only person who is confronted with this problem.

Jos


On Mon, 2010-01-11 at 08:54 +, Dominic Mitchell wrote:
> 2010/1/10 Jos Snellings 
> This is not a specific cocoon issue, I believe. It probably
> has to do
> with Tomcat 5.5.27.
> request.setCharacterEncoding simply does not work; it does not
> change a
> thing.
> request.getCharacterEncoding returns nothing.
> 
> You have to call request.setCharacterEncoding() really early for it to
> have any impact.  Your best bet is to look at spring's
> CharacterEncodingFilter.  You can add that to your web.xml to get the
> character set defined very early on.
> 
> -Dom 
> 
> 



-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: character encoding of a HttpServletRequest

[Dominic Mitchell]

2010/1/10 Jos Snellings 

> This is not a specific cocoon issue, I believe. It probably has to do
> with Tomcat 5.5.27.
> request.setCharacterEncoding simply does not work; it does not change a
> thing.
> request.getCharacterEncoding returns nothing.
>

You have to call request.setCharacterEncoding() really early for it to have
any impact.  Your best bet is to look at spring's CharacterEncodingFilter.
You can add that to your web.xml to get the character set defined very early
on.

-Dom

Re: character encoding of a HttpServletRequest

[Jos Snellings]

This is not a specific cocoon issue, I believe. It probably has to do
with Tomcat 5.5.27.
request.setCharacterEncoding simply does not work; it does not change a
thing.
request.getCharacterEncoding returns nothing.

Best,
Jos


On Sat, 2010-01-09 at 08:01 +0100, Jos Snellings wrote:
> Hi,
> 
> HttpServletRequest looks 'imperfect':
> Cocoon 3, alpha 2.
> A generator accesses the HttpServletRequest in the setup method:
> 
> request = HttpContextHelper.getRequest(parameters);
> text = request.getParameter("tekst");
> 
> The pages, including forms are ecoded in utf-8.
> The String 'text' is strange: the original content (utf-8) is encoded
> once again:
> if the string on the form was one character, say 'é', the string has a
> length of 4 bytes. It is the result of utf-8 encoding the two byte
> character coming from the client. So, a second conversion is happening.
> 
> Now:
> new String(request.getParameter("text").getBytes("ISO-8859-1")) works
> fine.
> 
> Where should this be corrected?
> 
> Cheers,
> Jos
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> For additional commands, e-mail: users-h...@cocoon.apache.org
> 
> 



-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

character encoding of a HttpServletRequest

[Jos Snellings]

Hi,

HttpServletRequest looks 'imperfect':
Cocoon 3, alpha 2.
A generator accesses the HttpServletRequest in the setup method:

request = HttpContextHelper.getRequest(parameters);
text = request.getParameter("tekst");

The pages, including forms are ecoded in utf-8.
The String 'text' is strange: the original content (utf-8) is encoded
once again:
if the string on the form was one character, say 'é', the string has a
length of 4 bytes. It is the result of utf-8 encoding the two byte
character coming from the client. So, a second conversion is happening.

Now:
new String(request.getParameter("text").getBytes("ISO-8859-1")) works
fine.

Where should this be corrected?

Cheers,
Jos


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: Character encoding problem with umlauts (ä ö ü)

[Gabriel Gruber]

You probably will find your answers somewhere in this thread:
http://cocoon.apache.org/2.2/1366_1_1.html

__
Mag. Gabriel Gruber
Senior Consultant
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Workflow EDV GmbH, Dannebergplatz 6/23, A-1030 Wien




Smigge  
05.01.2009 14:54
Please respond to
users@cocoon.apache.org


To
users@cocoon.apache.org
cc

Subject
Character encoding problem with umlauts (ä ö ü)







Hi!

I have a pipeline that takes a couple of parameters, does an sql query 
with
them and returns the result. The problem is that it doesn't work with 
umlaut
characters. They turn into boxes instead (and causes the sql query to 
break
the pipeline). However, if I use eg. %C3%A4 to escape ä, it works. 

How could this be fixed, eg. by changing the whole encoding or converting
the parameters somehow?
-- 
View this message in context: 
http://www.nabble.com/Character-encoding-problem-with-umlauts-%28%C3%A4-%C3%B6-%C3%BC%29-tp21291365p21291365.html

Sent from the Cocoon - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Character encoding problem with umlauts (ä ö ü)

[Smigge]

Hi!

I have a pipeline that takes a couple of parameters, does an sql query with
them and returns the result. The problem is that it doesn't work with umlaut
characters. They turn into boxes instead (and causes the sql query to break
the pipeline). However, if I use eg. %C3%A4 to escape ä, it works. 

How could this be fixed, eg. by changing the whole encoding or converting
the parameters somehow?
-- 
View this message in context: 
http://www.nabble.com/Character-encoding-problem-with-umlauts-%28%C3%A4-%C3%B6-%C3%BC%29-tp21291365p21291365.html
Sent from the Cocoon - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: Character encoding problem with latest Saxon + Cocoon 2.1

[Mark Lundquist]

On Dec 31, 2008, at 1:25 AM, Bertrand Delacretaz wrote:

On Wed, Dec 31, 2008 at 2:11 AM, Mark Lundquist   
wrote:
...Cocoon is serving a web page with a bunch of occurrences of the  
"ndash"
character (Unicode #8211).  These displayed correctly with the old  
Saxon,

but now with the new version they instead look like this:

  â€"...


Did you try setting the encoding at the JVM level as well? (- 
Dfile.encoding=...)


Your problem might be related to some code using the platform's
default encoding in places, instead of the specified one.


Hi Bertrand,

Thanks but I don't think so :-)... no code within Saxon (the only  
thing that has changed) is reading any character data from outside the  
JVM, e.g. the offending characters are from the source document which  
has been parsed by Xalan, same as before, so the effect of the  
file.encoding property (or its absence) would not have changed.


I thought maybe somebody (Vadim?) w/ experience using Cocoon+Saxon  
might just be able to say "oh, that!" :-).


cheers, HNY,
—ml—



smime.p7s
Description: S/MIME cryptographic signature

Re: Character encoding problem with latest Saxon + Cocoon 2.1

[Bertrand Delacretaz]

On Wed, Dec 31, 2008 at 2:11 AM, Mark Lundquist  wrote:
> ...Cocoon is serving a web page with a bunch of occurrences of the "ndash"
> character (Unicode #8211).  These displayed correctly with the old Saxon,
> but now with the new version they instead look like this:
>
>â€"...

Did you try setting the encoding at the JVM level as well? (-Dfile.encoding=...)

Your problem might be related to some code using the platform's
default encoding in places, instead of the specified one.

-Bertrand

Character encoding problem with latest Saxon + Cocoon 2.1

[Mark Lundquist]

Hi All,

I have a Cocoon 2.1.8 application using Saxon, and after a very long  
time with no problems, we just stumbled upon a bug in the (now rather  
old) version of Saxon that we were using.  So I downloaded the latest  
Saxon distribution and swapped out the Saxon JAR, and... problem  
solved!  Except that now, I seem to have a new problem with character  
encoding...


Cocoon is serving a web page with a bunch of occurrences of the  
"ndash" character (Unicode #8211).  These displayed correctly with the  
old Saxon, but now with the new version they instead look like this:


–

:-(.  The HTMLSerializer is adding the correct



The declaration for that component did not include any   
element.  I tried adding one like this:


utf-8

which had no effect.  But then just for giggles I tried

iso-8859-1

...and discovered that this "fixed" the bad characters.  (It also  
changes the  element generated by the  
serializer).  Which is interesting, but not really what I want; I want  
to be all UTF-8.  So I reverted back to 'utf-8' in the  of  
the HTMLSerializer  configuration and kept fiddling around.  I tried  
adding




to my stylesheets, but that had no effect.  In addition, I then also  
tried adding 'encoding="UTF-8"' to the  preamble of my source  
document, and that also had no effect.


Anybody have any clues to share?

thx,
—ml—




smime.p7s
Description: S/MIME cryptographic signature

Re: Cforms and Character Encoding

[Joerg Heinicke]

On 23.01.2008 03:51, Tobia Conforto wrote:


The problem turned out to be in web.xml
I amended
  form-encoding
  ISO-8859-1
To
  form-encoding
  UTF-8
and now everything is in UTF-8 and works properly


Just a word of caution: make sure you test your forms on every possible 
web browser. I've had trouble with this setting in the past.


I've never encountered a browser-specific problem of that kind.

Joerg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cforms and Character Encoding

[Peter Sparkes]

Thanks for the advice

I have tested with various versions of IE and Firefox and all' fine

Peter

Peter Sparkes wrote:

The problem turned out to be in web.xml
I amended
  form-encoding
  ISO-8859-1
To
  form-encoding
  UTF-8
and now everything is in UTF-8 and works properly


Just a word of caution: make sure you test your forms on every 
possible web browser.

I've had trouble with this setting in the past.


Tobia

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cforms and Character Encoding

[Gabriel Gruber]

> Peter Sparkes wrote:
> > The problem turned out to be in web.xml
> > I amended
> >   form-encoding
> >   ISO-8859-1
> > To
> >   form-encoding
> >   UTF-8
> > and now everything is in UTF-8 and works properly
> 
> Just a word of caution: make sure you test your forms on every 
> possible web browser.
> I've had trouble with this setting in the past.

Our enterprise product which heavily uses Cforms and cocoon has the 
form-encoding set to UTF-8 which works for us quite well :-)

Gabriel

Re: Cforms and Character Encoding

[Tobia Conforto]

Peter Sparkes wrote:

The problem turned out to be in web.xml
I amended
  form-encoding
  ISO-8859-1
To
  form-encoding
  UTF-8
and now everything is in UTF-8 and works properly


Just a word of caution: make sure you test your forms on every  
possible web browser.

I've had trouble with this setting in the past.


Tobia

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cforms and Character Encoding

[Peter Sparkes]

Thanks Joerg,

The problem turned out to be in web.xml

I amended


   form-encoding
   ISO-8859-1


To


   form-encoding
   UTF-8


and now everything is in UTF-8 and works properly

The problem was that the form was sending UTF-8 but it was being read as 
ISO-8859-1


Peter

On 08.12.2007 13:37, Peter Sparkes wrote:

I am using Cforms in Cocoon 2.1.10 to amend an XML file. The 
character encoding is UTF-8


The Euro sign € gets converted to € and UK pound sign £ to £
from the field widget. I am using the saveDocument function from the 

samples and have set
transformer.setOutputProperty(Packages.javax.xml.transform.OutputKeys.ENCODING, 
"UTF-8");


Please, how do I correct this problem?


I can't tell you how to correct it since I don't know where it goes 
wrong. But what happens is that a 2-byte-character (as in UTF-8) is 
read byte by byte (as in ISO-8859-1). Maybe it is only a problem with 
watching the file without an encoding-aware editor which reads it in 
ISO-8859-1?


Joerg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cforms and Character Encoding

[Joerg Heinicke]

On 08.12.2007 13:37, Peter Sparkes wrote:

I am using Cforms in Cocoon 2.1.10 to amend an XML file. The character 
encoding is UTF-8


The Euro sign € gets converted to € and UK pound sign £ to £
from the field widget. I am using the saveDocument function from the 

samples and have set
transformer.setOutputProperty(Packages.javax.xml.transform.OutputKeys.ENCODING, 
"UTF-8");


Please, how do I correct this problem?


I can't tell you how to correct it since I don't know where it goes 
wrong. But what happens is that a 2-byte-character (as in UTF-8) is read 
byte by byte (as in ISO-8859-1). Maybe it is only a problem with 
watching the file without an encoding-aware editor which reads it in 
ISO-8859-1?


Joerg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Need help Character Encoding :-((

[Andreas Busch]

Thanks ,

Then the workaround described in my last post, is not a workaround, it was
the solution.
:-)) working now.

Thanks a lot 
Andreas 

-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 12, 2007 2:59 PM
To: users@cocoon.apache.org
Subject: Re: Need help Character Encoding :-((

On 12.12.2007 8:37 Uhr, Johannes Textor wrote:

>> Instead of creating a link with  you should create a form 
>> with hidden elements and a button. The form values will get encoded
>> ISO-8859-1 correctly.
> 
> Or you set form-encoding to UTF-8 specifically for this pipeline. But
given this bug, it is probaby best to only use UTF-8? 

It's not a bug, it's by intention - or by spec (I think the HTML spec).

Joerg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


++
ILOGICS Informatik Service GmbH - Berduxstrasse 22 - 81245 Muenchen  
Tel: +49 89 896667-0 
Fax: +49 89 896667-29
HRB 156342  AG Muenchen; USTDID: DE812478281 
GF: Andreas Busch, Karl Rappert, Ralf Moormann
++


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Need help Character Encoding :-((

[Joerg Heinicke]

On 12.12.2007 8:37 Uhr, Johannes Textor wrote:

Instead of creating a link with  you should create a form 
with hidden elements and a button. The form values will get encoded 
ISO-8859-1 correctly.


Or you set form-encoding to UTF-8 specifically for this pipeline. But given this bug, it is probaby best to only use UTF-8? 


It's not a bug, it's by intention - or by spec (I think the HTML spec).

Joerg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Need help Character Encoding :-((

[Johannes Textor]

> Unfortunately, creating your own links does not work with special 
> characters. While your pages are in ISO-8859-1 and probably work fine 
> with all forms and stuff since the server also expects ISO-8859-1, these 
> links get *always* UTF-8 encoded so that you have a mismatch on the
> server.
> 

Hmm I was unaware of this problem, thanks for the info Joerg. 

> Instead of creating a link with  you should create a form 
> with hidden elements and a button. The form values will get encoded 
> ISO-8859-1 correctly.

Or you set form-encoding to UTF-8 specifically for this pipeline. But given 
this bug, it is probaby best to only use UTF-8? 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE: Need help Character Encoding :-((

[Johannes Textor]

Hi Andreas,

I'd bet that the screwed umlaut arises already at the level of the multisearch 
generator, can you confirm this? (by looking at search.xml?cocoon-view=debug 
and checking the source code). 

If this is indeed the problem, your generator is not using the correct encoding 
to decode the request parameters. Normally, you define this encoding in 
WEB-INF/web.xml (look for "form-encoding", you should not touch  
"container-encoding" though). It should suffice to set form-encoding to the one 
you use.

However, some older generators do not honour this setting (I don't know about 
the lucene generator, but it is the case for request generator, for example). 
In this case, you have to set the encoding explicitly for the pipeline using 
SetEncodingAction. It is defined in sitemap.xmap like this (at least in 2.1.10):


 


You can then set the encoding to use for each pipeline like this:


  
   
  
  
   
  


Hope this helps,
Johannes

 Original-Nachricht 
> Datum: Wed, 12 Dec 2007 13:54:08 +0100
> Von: "Andreas Busch" <[EMAIL PROTECTED]>
> An: users@cocoon.apache.org
> Betreff: RE: Need help  Character Encoding :-((

> Hi johannes,
> 
> Here is the sitemap fragment 
> 
>   
> 
>  
> 
> 
> 
>  
>value="{request:contextPath}/OCI" />
> 
>   
>  
>
> 
>   
>   
> 
> The important search.xml comes from 
> 
>   
>type="multisearch">
>value="{global:RealPath}/data/DE/KatalogListe.xml" />
>value="8" />
>   
>src="xsl/Sresult.xsl">
>  
> value="{request:servletPath}" />
>  value="{request:sitemapURI}"
> />
>  
> value="{request:contextPath}/OCI/DE" />
>   
> 
>   
> 
>   
> 
> The multisearch generator is a based on lucene search generatore (only
> works
> on multiple index-files)
> 
> It's seems that the problem only happens on url-paramters.
> I have made a workeround with  and javascript, ist not nice ,but
> works
> 
> 
>   
>value="{../@query-string}"/>
>value="{../@page-length}"/>
>value="{$offset}"/>
> 
>   ...
>   
> class="prevButton"
>   
> href="javascript:dopage([EMAIL PROTECTED])"/>  
> 
>   is the next set 
> 
> Javascript-function: 
> function dopage(iStart)
>  {
> var myform=document.getElementById("pageform");
> if (myform != null)
>  { 
>  var inp=document.getElementById("startIndex");
>   if (inp != null) 
>   {
>   inp.setAttribute("value",iStart);
>   myform.submit();
>  }
>   }
>};
> 
> 
> Thanks in advance 
> 
> Andreas
>  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Need help Character Encoding :-((

[Joerg Heinicke]

On 12.12.2007 3:09 Uhr, Andreas Busch wrote:


I have a problem with search and paging,
 
I do search with a post from form and then do pagination with the

search-result.
work's , but if there are some spezial charachters in the search like ü
etc the paging makes problems.
 
some codesnippets ..
 




 
form method="get" action="/openclass/OCI/DE/search.html">



 
looks good but the paging links are broken 
 
div id="nav-next">



there is a problem in queryString %C3%BC 
its createt in xsl with 

/>/search.html?queryString=&pagelength=



Serializers are changed to ISO-8859-1 encoding 

Need realy help for workaround or bugfixes 


Unfortunately, creating your own links does not work with special 
characters. While your pages are in ISO-8859-1 and probably work fine 
with all forms and stuff since the server also expects ISO-8859-1, these 
links get *always* UTF-8 encoded so that you have a mismatch on the server.


Instead of creating a link with  you should create a form 
with hidden elements and a button. The form values will get encoded 
ISO-8859-1 correctly.


Joerg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Need help Character Encoding :-((

[Andreas Busch]

Hi johannes,

Here is the sitemap fragment 

  

 



   



 
   


  

The important search.xml comes from 
















The multisearch generator is a based on lucene search generatore (only works
on multiple index-files)

It's seems that the problem only happens on url-paramters.
I have made a workeround with  and javascript, ist not nice ,but works







  ...

   

is the next set 

Javascript-function: 
function dopage(iStart)
 {  
var myform=document.getElementById("pageform");
if (myform != null)
 { 
 var inp=document.getElementById("startIndex");
  if (inp != null) 
  {
inp.setAttribute("value",iStart);
myform.submit();
   }
}
   };


Thanks in advance 

Andreas
 

-Original Message-
From: Johannes Textor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 12, 2007 11:44 AM
To: users@cocoon.apache.org
Subject: Re: Need help Character Encoding :-((

Hi Andreas,

if something goes wrong with the encoding, it's almost certainly a generator
issue. Which generator are you using? Could you post the corresponding part
of sitemap.xmap so we can have a look at your pipeline?

Johannes

Andreas Busch wrote:
> Hello,
>  
> I have a problem with search and paging,
>  
> I do search with a post from form and then do pagination with the 
> search-result.
> work's , but if there are some spezial charachters in the search like 
> ü etc the paging makes problems.
>  
> some codesnippets ..
>  
> 
> 
> 
>  
> form method="get" action="/openclass/OCI/DE/search.html">
>  value="drücker"> height="7" width="10" border="0"> class="search_buttonsmall">
> 
>  
> looks good but the paging links are broken
>  
> div id="nav-next">
> 
href="javascript:dolink('/openclass/OCI/DE/search.html?queryString=dr%C3%BCc
ker&pagelength=8&startIndex=8')" 
> class="prevButton">
> 
> there is a problem in queryString %C3%BC its createt in xsl with
>
>  />/search.html?queryString= />&pagelength=
>
> 
>
> Serializers are changed to ISO-8859-1 encoding
>
> Need realy help for workaround or bugfixes
>
> Cocoon is version 2.1.9
>
>  
>
> thanks in advance
>
> Andreas
>
> ++
> ILOGICS Informatik Service GmbH - Berduxstrasse 22 - 81245 Muenchen
> Tel: +49 89 896667-0
> Fax: +49 89 896667-29
> HRB 156342 AG Muenchen; USTDID: DE812478281
> GF: Andreas Busch, Karl Rappert, Ralf Moormann
> ++


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


++
ILOGICS Informatik Service GmbH - Berduxstrasse 22 - 81245 Muenchen  
Tel: +49 89 896667-0 
Fax: +49 89 896667-29
HRB 156342  AG Muenchen; USTDID: DE812478281 
GF: Andreas Busch, Karl Rappert, Ralf Moormann
++


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Need help Character Encoding :-((

[Johannes Textor]

Hi Andreas,

if something goes wrong with the encoding, it's almost certainly a 
generator issue. Which generator are you using? Could you post the 
corresponding part of sitemap.xmap so we can have a look at your pipeline?


Johannes

Andreas Busch wrote:

Hello,
 
I have a problem with search and paging,
 
I do search with a post from form and then do pagination with the 
search-result.
work's , but if there are some spezial charachters in the search like 
ü etc the paging makes problems.
 
some codesnippets ..
 




 
form method="get" action="/openclass/OCI/DE/search.html">
value="drücker">height="7" width="10" border="0">class="search_buttonsmall">


 
looks good but the paging links are broken
 
div id="nav-next">
href="javascript:dolink('/openclass/OCI/DE/search.html?queryString=dr%C3%BCcker&pagelength=8&startIndex=8')" 
class="prevButton">


there is a problem in queryString %C3%BC
its createt in xsl with

/>/search.html?queryString=/>&pagelength=




Serializers are changed to ISO-8859-1 encoding

Need realy help for workaround or bugfixes

Cocoon is version 2.1.9

 


thanks in advance

Andreas

++
ILOGICS Informatik Service GmbH - Berduxstrasse 22 - 81245 Muenchen
Tel: +49 89 896667-0
Fax: +49 89 896667-29
HRB 156342 AG Muenchen; USTDID: DE812478281
GF: Andreas Busch, Karl Rappert, Ralf Moormann
++



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Need help Character Encoding :-((

[Andreas Busch]

Hello,
 
I have a problem with search and paging,
 
I do search with a post from form and then do pagination with the
search-result.
work's , but if there are some spezial charachters in the search like ü
etc the paging makes problems.
 
some codesnippets ..
 



 
form method="get" action="/openclass/OCI/DE/search.html">


 
looks good but the paging links are broken 
 
div id="nav-next">


there is a problem in queryString %C3%BC 
its createt in xsl with 
/search.html?queryString=&pagelength=



Serializers are changed to ISO-8859-1 encoding 

Need realy help for workaround or bugfixes 

Cocoon is version 2.1.9

 

thanks in advance 

Andreas


++
ILOGICS Informatik Service GmbH - Berduxstrasse 22 - 81245 Muenchen  
Tel: +49 89 896667-0 
Fax: +49 89 896667-29
HRB 156342  AG Muenchen; USTDID: DE812478281 
GF: Andreas Busch, Karl Rappert, Ralf Moormann
++

Cforms and Character Encoding

[Peter Sparkes]

Hi,

I am using Cforms in Cocoon 2.1.10 to amend an XML file. The character 
encoding is UTF-8


The Euro sign € gets converted to € and UK pound sign £ to £ 
from the field widget. I am using the saveDocument function from the 
samples and have set
transformer.setOutputProperty(Packages.javax.xml.transform.OutputKeys.ENCODING, 
"UTF-8");


Please, how do I correct this problem?


Regards

Peter Sparkes



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

upload and character encoding with cforms

[Sébastien Geindre]

Hi cocooners !

I'va a little pb with upload widget and encoding.

Explanations:
i use upload widget in a form to upload ( ;-) , it sounds good!) an file 
which is an XML file

   

XML file example : 

in my flowscript, i try to handle the xml stream and give it to a cocoon 
pipe.


i use the following fonction handleUpload().
The probleme is that my xml data retrieved by weatherData = 
handleUpload(form) is encoded.

all the < character are encoded in <




Any suggestion ?
i've tried several charsetnew 
java.io.InputStreamReader(stream,"UTF-8"));


sébastien.


function handleUpload(form) {

 var buf = new java.lang.StringBuffer();

 var uploadWidget = form.lookupWidget("upload");
 if (uploadWidget.getValue() != null) {
   var stream = uploadWidget.getValue().getInputStream();
   var reader = new java.io.BufferedReader(new 
java.io.InputStreamReader(stream));

   var line;
   while ((line=reader.readLine())!=null)
 buf.append(line).append("\n");

   reader.close();
 }
 return buf.toString();

--
Sébastien Geindre
DPREVI/AERO/DEV
[EMAIL PROTECTED]
05 61 07 84 93




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: character encoding: utf-8 and ISO-8859-1 on Mac OS X with Safari

[Frank MW]

Yes, I tried all of that.

Frank

> Have you set the form parameter encoding to UTF-8?
> (http://wiki.apache.org/cocoon/RequestParameterEncoding).
> 
> Peter
>  
> 
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Frank MW
> Sent: Friday, September 15, 2006 10:08 AM
> To: users@cocoon.apache.org
> Subject: character encoding: utf-8 and ISO-8859-1 on Mac OS X with Safari
> 
> Hi all, 
> 
> I have a problem with some special characters in a request parameter.
> 
> This is the URL with the correct representation of characters:
> 
> http://localhost:8080/webapp/gangyin/vokabelSuchen-rgyaḥ·mtsho.html
> 
> Now 'rgyaḥ·mtsho' is what I need in an xslt-stylesheet.
> 
> So in the sitemap I have the following:
> 
>   
>   
> 
>   
>
> 
> In the xslt, I try to catch the 'rgyaḥ·mtsho':
> 
> 
> 
> But then with 
> 
> 
> 
> the word looks quite different:
> 
> rgyaḥ·mtsho
> 
> In the URL, it was fine, but then in the browser window, it is distorted.
> 
> With firefox, the URL looks different:
> 
> http://localhost:8080/webapp/gangyin/vokabelSuchen-rgya%E1%B8%A5%C2%B7mtsho.
> html
> 
> but the problem remains the same.

Mithilfe von Microsoft Entourage 2004 für Mac Test Drive versendet.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: character encoding: utf-8 and ISO-8859-1 on Mac OS X with Safari

[Binkley, Peter]

Have you set the form parameter encoding to UTF-8? 
(http://wiki.apache.org/cocoon/RequestParameterEncoding). 

Peter
 

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Frank MW
Sent: Friday, September 15, 2006 10:08 AM
To: users@cocoon.apache.org
Subject: character encoding: utf-8 and ISO-8859-1 on Mac OS X with Safari

Hi all, 

I have a problem with some special characters in a request parameter.

This is the URL with the correct representation of characters:

http://localhost:8080/webapp/gangyin/vokabelSuchen-rgyaḥ·mtsho.html

Now 'rgyaḥ·mtsho' is what I need in an xslt-stylesheet.

So in the sitemap I have the following:

  
  

  
   

In the xslt, I try to catch the 'rgyaḥ·mtsho':



But then with 



the word looks quite different:

rgyaḥ·mtsho

In the URL, it was fine, but then in the browser window, it is distorted.

With firefox, the URL looks different:

http://localhost:8080/webapp/gangyin/vokabelSuchen-rgya%E1%B8%A5%C2%B7mtsho.
html

but the problem remains the same.



Any ideas?

Thanks,
Frank
Mithilfe von Microsoft Entourage 2004 für Mac Test Drive versendet.

Mithilfe von Microsoft Entourage 2004 für Mac Test Drive versendet.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

character encoding: utf-8 and ISO-8859-1 on Mac OS X with Safari

[Frank MW]

Hi all, 

I have a problem with some special characters in a request parameter.

This is the URL with the correct representation of characters:

http://localhost:8080/webapp/gangyin/vokabelSuchen-rgyaḥ·mtsho.html

Now 'rgyaḥ·mtsho' is what I need in an xslt-stylesheet.

So in the sitemap I have the following:

  
  

  
  


In the xslt, I try to catch the 'rgyaḥ·mtsho':



But then with 



the word looks quite different:

rgyaḥ·mtsho

In the URL, it was fine, but then in the browser window, it is distorted.

With firefox, the URL looks different:

http://localhost:8080/webapp/gangyin/vokabelSuchen-rgya%E1%B8%A5%C2%B7mtsho.
html

but the problem remains the same.



Any ideas?

Thanks,
Frank
Mithilfe von Microsoft Entourage 2004 für Mac Test Drive versendet.

Mithilfe von Microsoft Entourage 2004 für Mac Test Drive versendet.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character encoding...

[Joerg Heinicke]

On 27.03.2004 11:26, beyaNet Consultancy wrote:
Hi Marc,
I am trying to achieve the following:
1. Determine, in my sitemap, whether a browser is XHTML 1.1 compatible.  
If it is, the XHTML 1.1 serializer is used, which when view sourced in  
the browser you see:


http://www.w3.org/TR/xhtml1/DTD/xhtml1.dtd";>

Now, as part of the XHTML 1.1 specification you also need to say the  
following in the  tag:

http://www.w3.org/1999/xhtml";>

I have not found a way in the serialization process of writing the  
xmlns line into the  tag if the browser viewing the site is XHTML  
1.1 compatible, so I thought maybe if I specify UTF-8 as the encoding  
type for XHTML 1.1 browsers and a different encoding type for non 1.1  
browsers, I could then dynamically write the xmlns line into the tag if  
the browser was XHTML 1.1 compatible.

Do you know of a more efficient way I could probably do this?

Peter
This is only possible by operating on the XML stream, for example using 
an additional stylesheet that puts all your HTML elements into XHTML 
namespace. But wouldn't it be possible to put them always in that 
namespace, i.e. does not the HTMLSerializer remove this namespace?

Joerg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character encoding...

[beyaNet Consultancy]

Hi Marc,
I am trying to achieve the following:

1. Determine, in my sitemap, whether a browser is XHTML 1.1 compatible. If it is, the XHTML 1.1 serializer is used, which when view sourced in the browser you see:




Now, as part of the XHTML 1.1 specification you also need to say the following in the  tag:



I have not found a way in the serialization process of writing the xmlns line into the  tag if the browser viewing the site is XHTML 1.1 compatible, so I thought maybe if I specify UTF-8 as the encoding type for XHTML 1.1 browsers and a different encoding type for non 1.1 browsers, I could then dynamically write the xmlns line into the tag if the browser was XHTML 1.1 compatible.

Do you know of a more efficient way I could probably do this?

Peter

p.s.

sitemap snippet:

		

-//W3C//DTD XHTML 1.1 //EN










			



-//W3C//DTD XHTML 1.0 Transitional//EN




		










...

			




On 27 Mar 2004, at 07:30, Marc Portier wrote:

Peter,

sorry for the bad advice then, but you lost me,
pls elaborate on where you see what and how your setup is looking
and what you try to achieve

regards,
-marc=

beyaNet Consultancy wrote:

Marc,
I am using Cocoon version 2.1.4. I have made the changes you mentioned, but nothing has really changed. If I now  and change the encoding in the page so that it now reads  i still only get what is specified in the web.xml document and not in the web-page. Any ideas?
Peter
On 26 Mar 2004, at 23:08, Marc Portier wrote:
beyaNet Consultancy wrote:
Hi,
I am trying to obtain the encoding type as specified in at the
top of my site page when you view source the page. At the moment
the encoding type is specified as:


"http://www.w3.org/TR/xhtml1/DTD/xhtml1.dtd">

I was under the impression that if i used
 that it would return UTF-8,
in this instance. At the moment it is returning ISO-8859-1 which
is the encoding type of the server. How do I get the encoding
type as specified within my page?
which version of cocoon are you using?
pre 2.1.3 there was a possible mismatch between the encoding used in
the html-generation (encoding) and the one used in the
request-parameter-processing (decoding)
this should be fixed per

http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java?rev=1.6&view=markup

http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java?rev=1.20&view=markup
prior to this you can manually assure that both sides are in sync:
just make sure the encoding set-up in your  (see it's
config in sitemap.xmap) is matching the setting in the web.xml (see
init-param 'form-encoding' to the cocoon servlet)
HTH,
-marc=
many thanks in advance
Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character encoding...

[Marc Portier]

Peter,

sorry for the bad advice then, but you lost me,
pls elaborate on where you see what and how your setup is looking
and what you try to achieve
regards,
-marc=
beyaNet Consultancy wrote:

Marc,
I am using Cocoon version 2.1.4. I have made the changes you mentioned, 
but nothing has really changed. If I now 
 and change the encoding in the page 
so that it now reads  i still 
only get what is specified in the web.xml document and not in the 
web-page. Any ideas?

Peter
On 26 Mar 2004, at 23:08, Marc Portier wrote:


beyaNet Consultancy wrote:

Hi,
I am trying to obtain the encoding type as specified in at the
top of my site page when you view source the page. At the moment
the encoding type is specified as:

http://www.w3.org/TR/xhtml1/DTD/xhtml1.dtd";>

I was under the impression that if i used
 that it would return UTF-8,
in this instance. At the moment it is returning ISO-8859-1 which
is the encoding type of the server. How do I get the encoding
type as specified within my page?
which version of cocoon are you using?

pre 2.1.3 there was a possible mismatch between the encoding used in
the html-generation (encoding) and the one used in the
request-parameter-processing (decoding)
this should be fixed per

http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java?rev=1.6&view=markup
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java?rev=1.20&view=markup

prior to this you can manually assure that both sides are in sync:
just make sure the encoding set-up in your  (see it's
config in sitemap.xmap) is matching the setting in the web.xml (see
init-param 'form-encoding' to the cocoon servlet)
HTH,
-marc=
many thanks in advance
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character encoding...

[beyaNet Consultancy]

Marc,
I am using Cocoon version 2.1.4. I have made the changes you mentioned, but nothing has really changed. If I now  and change the encoding in the page so that it now reads ISO-8859-1"?> i still only get what is specified in the web.xml document and not in the web-page. Any ideas?

Peter
On 26 Mar 2004, at 23:08, Marc Portier wrote:

beyaNet Consultancy wrote:

Hi,
I am trying to obtain the encoding type as specified in at the top of my site page when you view source the page. At the moment the encoding type is specified as:



I was under the impression that if i used  that it would return UTF-8, in this instance. At the moment it is returning  ISO-8859-1 which is the encoding type of the server. How do I get the encoding type as specified within my page?

which version of cocoon are you using?

pre 2.1.3 there was a possible mismatch between the encoding used in the html-generation (encoding) and the one used in the request-parameter-processing (decoding)

this should be fixed per
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java?rev=1.6&view=markup 
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java?rev=1.20&view=markup

prior to this you can manually assure that both sides are in sync:
just make sure the encoding set-up in your  (see it's config in sitemap.xmap) is matching the setting in the web.xml (see init-param 'form-encoding' to the cocoon servlet)

HTH,
-marc=

many thanks in advance
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character encoding...

[Marc Portier]

beyaNet Consultancy wrote:

Hi,
I am trying to obtain the encoding type as specified in at the top of my 
site page when you view source the page. At the moment the encoding type 
is specified as:


http://www.w3.org/TR/xhtml1/DTD/xhtml1.dtd";>


I was under the impression that if i used 
 that it would return UTF-8, in this 
instance. At the moment it is returning  ISO-8859-1 which is the 
encoding type of the server. How do I get the encoding type as specified 
within my page?

which version of cocoon are you using?

pre 2.1.3 there was a possible mismatch between the encoding used in the 
html-generation (encoding) and the one used in the 
request-parameter-processing (decoding)

this should be fixed per
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java?rev=1.6&view=markup 

http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java?rev=1.20&view=markup

prior to this you can manually assure that both sides are in sync:
just make sure the encoding set-up in your  (see it's config 
in sitemap.xmap) is matching the setting in the web.xml (see init-param 
'form-encoding' to the cocoon servlet)

HTH,
-marc=
many thanks in advance

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Character encoding...

[beyaNet Consultancy]

Hi,
I am trying to obtain the encoding type as specified in at the top of 
my site page when you view source the page. At the moment the encoding 
type is specified as:


http://www.w3.org/TR/xhtml1/DTD/xhtml1.dtd";>


I was under the impression that if i used 
 that it would return UTF-8, in 
this instance. At the moment it is returning  ISO-8859-1 which is the 
encoding type of the server. How do I get the encoding type as 
specified within my page?

many thanks in advance

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with character encoding

[Leszek Gawron]

On Tue, Dec 02, 2003 at 03:10:51PM +0100, Jakub Kaniewski wrote:
> I have problem with character encoding, when using standart Cocoon 
> database actions (like explained in tutorial action-set, that use class 
> org.apache.cocoon.acting.DatabaseAddAction). All my Cocoon engine i set 
> to encode in iso-8859-2 charset, I have no problem in fetching good 
> encoded record from database (using XSP and ESQL), but I can't update 
> with modules I mentioned above. I think there should be proper 
> paramemeter in SQL descriptor file, but I can't find it in the 
change the container's form encoding :
 - via web.xml  (form-encoding entry)
 - via SetCharacterEncodingAction
lg
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problem with character encoding

[Jakub Kaniewski]

I have problem with character encoding, when using standart Cocoon 
database actions (like explained in tutorial action-set, that use class 
org.apache.cocoon.acting.DatabaseAddAction). All my Cocoon engine i set 
to encode in iso-8859-2 charset, I have no problem in fetching good 
encoded record from database (using XSP and ESQL), but I can't update 
with modules I mentioned above. I think there should be proper 
paramemeter in SQL descriptor file, but I can't find it in the 
documentation. I am using Cocoon 2.1.3 and PostgreSQL.

J. K.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

xhtml character encoding

[John Morrow]

Hi,

I am using cocoon 2.1.2 and I need some help getting the xml serializer 
to behave like the html serializer. I can demostrate the problem using 
the hello-world sample.

If I modify  samples/hello-world/content/hello.xml and insert the code 
½ as follows:


  


  


Hello

 This is my ½ first Cocoon page!


When I access it as hello.html I get
This is my ½ first Cocoon page!
as hello.xhtml I get
This is my ½ first Cocoon page!
I'm not sure the extra char will appear in this email, however viewing 
the page in a browser displays an additional A with a caret in front of 
the half symbol.

I would like to output as xhtml but would prefer the output using the 
text encoding as in the html example.

Is this possible?

Many thanks,
John.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Character encoding

[Nuno Leong]




Hi all,
 
I'm having some trouble with character encoding on 
cocoon. Basically, i'm using Jboss-Net to access webservices via SOAP. The Soap 
Response has the encoding correct but the presentation (with cocoon) is showing 
some characters all garbled.
 
Here's a simple method i've used to test 
this:
 
 
public String teste() 
{    return "á : à : ã : â : é : í : 
ó : õ : ú : Á : À : Ã : É : Í : Ó : Õ : Ô : Ú : ç : Ç";
 
 
These are the special characters i'm having trouble 
with. The SOAP encoding is UTF-8, according to the Jboss-Net log.
 
I've set up a small match on the sitemap to 
serialize the response to HTML:
 
    
    
  

 
 
teste.xsp has the SOAP call:
 
  language="java"  
xmlns:xsp="http://apache.org/xsp"  
xmlns:xsp-request="http://apache.org/xsp/request/2.0"  
xmlns:xscript="http://apache.org/xsp/xscript/1.0"  
xmlns:soap="http://apache.org/xsp/soap/3.0"  
xmlns:xsp-session="http://apache.org/xsp/session/2.0"  
>      
http://192.168.0.2:8080/jboss-net/services/Teste">    
    
  
     

 
 
The output on the browser is showing these strange 
characters:
á : à : ã : â : é : í : ó : õ : ú : Á : À : Ã : É : 
Í : Ó : Õ : Ô : Ú : ç : Ç  
 
 
and the Source shows:
http://apache.org/xsp" xmlns:xsp-session="http://apache.org/xsp/session/2.0" 
xmlns:xscript="http://apache.org/xsp/xscript/1.0" 
xmlns:soap="http://apache.org/xsp/soap/3.0" 
xmlns:xsp-request="http://apache.org/xsp/request/2.0"> 
http://schemas.xmlsoap.org/soap/envelope/" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">   
http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:ns1="urn:Teste">   á : à : 
ã : â : é : 
í : ó : õ : 
ú : Á : À : 
à : É : Í : 
Ó : Õ : Ô : 
Ú : ç : 
Ç  
    
  
 
 
I'm not sure why this is happening, but i guess it 
has something to do with character encoding that cocoon is applying to the SOAP 
response. I've tested the webservice with a small VB.Net console application, 
and the output is correct, so the problem is definitely with 
cocoon.
 
Any thoughts on this?
 
Thanks in advance.
--Nuno LeongPráxia 
SI