Hi Mika,
Some questions:
- are you having problems submitting forms where the data is not received
server side as UTF-8?
- what application container are you using? Tomcat, Jetty, ...
Robby
-Original Message-
From: m...@digikartta.net [mailto:m...@digikartta.net]
Sent: Wednesday,
Hi Mika,
Some questions:
- are you having problems submitting forms where the data is not received
server side as UTF-8?
- what application container are you using? Tomcat, Jetty, ...
Robby
-Original Message-
From: m...@digikartta.net [mailto:m...@digikartta.net]
Sent: Wednesday,
Hi,
yep, if I got you right, problems appear somewhere between the submit
and the outcome of the bind, at server side. Container is Tomcat 6.
Something like this:
flowscript:
form.createBinding(cocoon:/form_ + id + _bind);
form.save(doc);
cocoon.sendPage(vastaus-display-pipeline.jx, {title:
version=1.0 encoding=UTF-8 indent=yes/
Robby
-Original Message-
From: m...@digikartta.net [mailto:m...@digikartta.net]
Sent: Friday, August 31, 2012 9:33 AM
To: users@cocoon.apache.org
Subject: RE: encoding issue
Hi,
yep, if I got you right, problems appear somewhere between the submit
-
From: m...@digikartta.net [mailto:m...@digikartta.net]
Sent: Friday, August 31, 2012 9:33 AM
To: users@cocoon.apache.org
Subject: RE: encoding issue
Hi,
yep, if I got you right, problems appear somewhere between the
submit
and the outcome of the bind, at server side. Container is Tomcat 6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Laurent,
On 12/17/2010 11:25 AM, Laurent Medioni wrote:
Have a look at http://wiki.apache.org/tomcat/FAQ/CharacterEncoding I
think the comment you refer to tries to say that if no
charset/encoding is set when producing a response then assume the
On 17/12/10 15:06, Peter Flynn wrote:
[...]
The result is that the output at
http://publish.ucc.ie/researchprofiles/A005
has Unicode replacement characters instead of accents.
Curiouser and curiouser, that page serves as UTF-8 but lower down it says:
!DOCTYPE html
PUBLIC -//W3C//DTD HTML
What is your
init-param
param-namecontainer-encoding/param-name
param-valueUTF-8/param-value
/init-param
In web.xml ?
• This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the
On 17/12/10 15:37, Laurent Medioni wrote:
What is your
init-param
param-namecontainer-encoding/param-name
param-valueUTF-8/param-value
/init-param
In web.xml ?
Interesting. ISO-8859-1, because
!--
Set encoding used by the container. If not set the ISO-8859-1 encoding
-8'/ ? sorry from
memory, not an XSL specialist...), then you won't get the default encoding back.
Laurent
-Original Message-
From: Peter Flynn [mailto:pfl...@ucc.ie]
Sent: vendredi, 17. décembre 2010 17:06
To: users@cocoon.apache.org
Subject: Re: Encoding
On 17/12/10 15:37, Laurent
I mean the problem occurs in my component but i don't think it is
because of my component.
I think that the bean is already corrupted when my component receives
it because my component method does nothing except getting an attribute
value from the bean.
I already wrote multiple components that
I mean the problem occurs in my component but i don't think it is
because of my component.
I think that the bean is already corrupted when my
component receives
it because my component method does nothing except getting an
attribute
value from the bean.
I already wrote multiple
Well for the moment we don't have the time to test it with another
Coccon version.
Ard Schrijvers wrote:
I mean the problem occurs in my component but i don't think it is
because of my component.
I think that the bean is already corrupted when my
component receives
it because my component
Think I am lost: I suppose cocoon.getComponent(myComponent.ROLE); gets a
component you wrote yourself? I thought you might have made a mistake in there,
but now you are saying it is not my component I am seriously confused
Regards Ard
It's not my component.
If I do a myBean.getName() in
It's not my component.
If I do a myBean.getName() in the flowscript for exemple, the string is
well encoded.
But if i do the same call in my component, the string is no more well
encoded.
I think it's more a problem with the Rhino layer when passing the
objects from flowscript to java object.
In your web.xml, you have the form-encoding configured correctly??
For example,
init-param
param-nameform-encoding/param-name
param-valueutf8/param-value
/init-param
Regards Ard
Hello,
We are using Cocoon 2.1.9 (Windows XP/Tomcat 5.0.30 and Suse 9/Tomcat
5.0) and we have
Yes, the form encoding is well configured.
We are able to retrieve correctly the accentuated characters from the
form in the flowsript.
The problem occurs when we pass the bean from the flowscript to the
component.
Ard Schrijvers wrote:
In your web.xml, you have the form-encoding
But is then theproblem not just in your
myComponent? What does it do?
Ard
Yes,
the form encoding is well configured.We are able to retrieve correctly the
accentuated characters from the form in the flowsript.The problem occurs
when we pass the bean from the flowscript to the
I mean,
map:serializer
encodingISO-8859-1/encoding
/map:serializer
And I had to modify container-encoding and form-encoding in web.xml
(UTF-8 - ISO-8859-1)
Otherwise, I had some UTF8Exception during my upload(streamgenerator).
Lionel
Geert Josten wrote:
Hi,
Now I need to
Hi,
Now I need to change my encoding on the serializers. (UTF-8 -
ISO-8859-1).
What do you mean with 'need to change'?
Grtz,
Geert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
On Sun, 2005-03-06 at 20:46 +0100, stefan pickschneider wrote:
Bertrand Delacretaz wrote:
Le 5 mars 05, à 15:17, stefan pickschneider a écrit :
..we have a problem with the encoding, cforms and file uploads.
Did you look at http://wiki.apache.org/cocoon/RequestParameterEncoding ?
This problem is already fixed, though in a different way:
http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/servlet/CocoonServlet.java?rev=106200r1=55730r2=106200
Hey Bruno,
thanks for your reply.
I am not sure if the above patch fixes the problem I
On Mon, 2005-03-07 at 11:02 +0100, stefan pickschneider wrote:
This problem is already fixed, though in a different way:
http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/servlet/CocoonServlet.java?rev=106200r1=55730r2=106200
Hey Bruno,
thanks
Hey Bruno,
I am not sure if the above patch fixes the problem I mentioned.
The patch replaces
this.defaultFormEncoding);
by
this.containerEncoding);
In our configuration the
defaultFormEncoding == containerEncoding == UTF-8 - so the patch
doesn't seem to have a influence on our problem :-(
On Mon, 2005-03-07 at 12:33 +0100, stefan pickschneider wrote:
Hey Bruno,
I am not sure if the above patch fixes the problem I mentioned.
The patch replaces
this.defaultFormEncoding);
by
this.containerEncoding);
In our configuration the
defaultFormEncoding == containerEncoding
It should work the same for both normal and multipart forms, without use
of the SetCharacterEncodingAction. You do need the fix though I pointed
to in a previous mail, since that one is not yet in Cocoon 2.1.6 IIRC.
Got it ;-) Should've tried that first. It just works.
Thanks a lot!
Stefan.
Bertrand Delacretaz wrote:
Le 5 mars 05, à 15:17, stefan pickschneider a écrit :
..we have a problem with the encoding, cforms and file uploads.
Did you look at http://wiki.apache.org/cocoon/RequestParameterEncoding ?
It might give some answers.
-Bertrand
Hello,
thanks for your suggestion - it
Le 6 mars 05, à 20:46, stefan pickschneider a écrit :
...It seems that the cocoon servlet initializes the container-encoding
for the request too late..
Could you create a bugzilla entry (http://issues.apache.org/bugzilla/)
for this, so that we don't forget to have a look at it?
-Bertrand
Le 5 mars 05, à 15:17, stefan pickschneider a écrit :
..we have a problem with the encoding, cforms and file uploads.
Did you look at http://wiki.apache.org/cocoon/RequestParameterEncoding ?
It might give some answers.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
On 28.07.2004 12:03, Jan Hoskens wrote:
Hi,
I'm currently facing the following problem: I've set the encoding in my
serializers to ISO-8859-1 and checked the web.xml file (utf-8 is in
comment, defaults to the ISO-8859-1)
Everything is ok (special chars in cforms offer no problem, saving the
On 07.11.2004 15:32, [EMAIL PROTECTED] wrote:
in the past i have contibute some greek translations an a sample that live
in scratchpad and i have notice that some greek charakters are brocken.
the charakters are:
(rho, mi, omikron)
it was unable to me to find why this happend until now.
today i
Hi:
Yep, we need to care about that. Can you post the path to the files?
Best Regards,
Antonio Gallardo.
[EMAIL PROTECTED] dijo:
hi people
in the past i have contibute some greek translations an a sample that live
in scratchpad and i have notice that some greek charakters are brocken.
On 31.10.2004 18:16, Marc Portier wrote:
So assuming all this reasoning is ok, what could never work is this:
- change your form-encoding (and matching setting of serialization)
to anything else then UTF-8, cos then request-params in forms and
pre-built ones in url's get encoded differently and
, Philip, EMP-UK
Subject: Re: Encoding problems, still!
In mozilla Firefox, when you open the right-click menu and choose View page Info
what is the value for Encoding there?
The serializer still seems to use ISO-8859 (e.g. not UTF-8)(according to the link
problem)?
The serializer add's the encoding
[EMAIL PROTECTED] wrote:
I have just recently resolved a problem with fragment identifiers in URLs for pages
that are served-up by Cocoon in UTF-8 to IE 6 on the PC.
My sitemap was set-up to deliver XHTML in UTF-8 and IE understood this. However, if I
sent a request that had a fragment
and commented out the reference to ISO-8859-1
Any ideas any one?
Regards
Phil Fennell
-Original Message-
From: Leszek Gawron [mailto:[EMAIL PROTECTED]
Sent: 01 November 2004 13:18
To: [EMAIL PROTECTED]
Subject: Re: Encoding problems, still!
[EMAIL PROTECTED] wrote:
I have just recently
taking one step at the time (what am I not seeing?):
- suppose a sax stream (producing xhtml) before serialization has a @href
holding an eurosign (\u20AC unicode char)
- I hear you guys saying that xalan will recognize the uri-type attribute and
serialize this character out as %E2%82%AC
On Fri, 29 Oct 2004, Kees van Dieren wrote:
In mozilla Firefox, when you open the right-click menu and choose View
page Info what is the value for Encoding there?
The same than used in serializer configuration. No problem here.
The serializer still seems to use ISO-8859 (e.g. not
On 30.10.2004 02:42, Marc Portier wrote:
That late? ;-)
But then in the bug report for Xalan (someone having this same
problem) it says:
According to section 16.2 of the XSLT Recommendation [1], non-ASCII
characters in URI attribute values should be escaped using the method
recommended in
Joerg Heinicke wrote:
On 30.10.2004 02:42, Marc Portier wrote:
That late? ;-)
ugh
But then in the bug report for Xalan (someone having this same
problem) it says:
According to section 16.2 of the XSLT Recommendation [1], non-ASCII
characters in URI attribute values should be escaped using the
In mozilla Firefox, when you open the right-click menu and choose View
page Info what is the value for Encoding there?
The serializer still seems to use ISO-8859 (e.g. not UTF-8)(according to
the link problem)?
The serializer add's the encoding type to the resulting html page, just
behind the
...adding to my latest post
The URL-encoding is done wrong when serializing to HTML. According to
specs äö should become %E4%F6 when encoded, not %C3%A4%C3%B6. This
seems to be the problem. So far I've noticed this problem with the
HREF-attribute only.
For a test I made a styslesheet that
just scanning through this issue fast it seems to me like more evidence
of things expressed here:
http://marc.theaimsgroup.com/?t=10923117717r=1w=2
rehashing what I read from Tuomo's setup:
- cocoon-servlet init params are set to have container-encoding
unchanged (thus iso_8859_1) like we
Ok, now I'm really confused.
In Bruno's excellent paper about Cocoon encoding, there's a section that
says:
For Java-insiders: what Cocoon actually does internally is apply the
following trick to get a parameter correctly decoded: suppose value is a
string containing a request parameter, then
Tuomo L wrote:
Ok, now I'm really confused.
In Bruno's excellent paper about Cocoon encoding, there's a section that
says:
For Java-insiders: what Cocoon actually does internally is apply the
following trick to get a parameter correctly decoded: suppose value is
a string containing a request
On 28.10.2004 21:35, Tuomo L wrote:
We're having some serious encoding problems. This happens only with the
@href attributes in html, when using characters like å, ä and ö (in
Finnish alphabet). Form encoding works just fine. I've gone through all
the threads concerning encoding (other people
Christian Hoofe wrote:
[...]
Put this into your sitemap.xmap to produce output IE understands:
map:serializer ...
omit-xml-declarationyes/omit-xml-declaration
/map:serializer
That's exactly what I already suggested in the second posting of this
thread. (Did you read it?).
But only
-nameform-encoding/param-name
param-valueUTF-8/param-value
/init-param
I uncommented it and now it works perfectly!
Thanks to you guys,
Fred
Messages d´origine
De: Jan Hoskens [EMAIL PROTECTED]
Date: Mardi, Août 3, 2004 8:29 am
Objet: Re: Encoding
You may want to take a look at the wiki page:
http://wiki.apache.org/cocoon/RequestParameterEncoding
I had this problem a while ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=109100902605917w=2
I'm wondering what the best solution is and which encoding is preferred
for handling special
Jan Hoskens wrote:
You may want to take a look at the wiki page:
http://wiki.apache.org/cocoon/RequestParameterEncoding
I had this problem a while ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=109100902605917w=2
I'm wondering what the best solution is and which encoding is preferred
perfectly!
Thanks to you guys,
Fred
Messages d´origine
De: Jan Hoskens [EMAIL PROTECTED]
Date: Mardi, Août 3, 2004 8:29 am
Objet: Re: Encoding problems
You may want to take a look at the wiki page:
http://wiki.apache.org/cocoon/RequestParameterEncoding
I had this problem a while
On Tue, 03 Aug 2004 11:02:43 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Jan Hoskens wrote:
You may want to take a look at the wiki page:
http://wiki.apache.org/cocoon/RequestParameterEncoding
I had this problem a while ago:
Gerald Aichholzer wrote:
On Tue, 03 Aug 2004 11:02:43 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Jan Hoskens wrote:
You may want to take a look at the wiki page:
http://wiki.apache.org/cocoon/RequestParameterEncoding
I had this problem a while ago:
FREDERIC MOSER wrote:
Hi,
I've got some encoding problems using the xhtml serializer, I don't
really understand .
(I use Mozilla on Win XP and my editor is set to use UTF-8)
Part 1:
---
I've got the following stylesheet:
On 31.03.2004 19:01, [EMAIL PROTECTED] wrote:
Hello *
We are using this mechanism to pass request params to the stylesheets:
map:transform src=stylesheets/my.xsl
map:parameter name=use-request-parameters value=true/
/map:transform
In some cases there are german umlauts like äöü in the values
After a lot of tries, it seems that Cocoon authentication is not involved, nor
DOM model : it is the fact of transforming such characters in a xsl:comment
section that produce this kind of error.
If I remove the xsl:comment tags, my string appears without any error. Is
anybody knows the problem ?
to the mailing list.
I used his patched version and it works just
fine now.
Is his patch included in CVS now?
Thanks,
- Brent
-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 07, 2004 6:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Encoding Params
:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 10:22 AM
To: [EMAIL PROTECTED]
Subject: RE: Encoding Params in the Sitemap
It was - and the solution was to use the
RawRequestParameterModule. I found some docs in the Wiki for
using this... but it doesn't seem to work as it should
Brent L Johnson wrote:
Dangit - please ignore that slappy email address. This
is an email address I setup specifically to test
my webmail functionality. For some reason Outlook
keeps defaulting replies to this list to that
email address.
My apologies...
no problemo Slappy !
;)
Jorg
Brent L Johnson wrote:
Is there a way I can encode the {request-param:paramname} in
a sitemap? I'm trying to use a request parameter in
the HTMLGenerator as part of a GET request, but using
{request-param:paramname} decodes the parameter. So
if the parameter has a space - instead of putting a
-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 07, 2004 6:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Encoding Params in the Sitemap
Brent L Johnson wrote:
Is there a way I can encode the {request-param:paramname} in a
sitemap? I'm
]
Sent: Saturday, February 07, 2004 6:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Encoding Params in the Sitemap
Brent L Johnson wrote:
Is there a way I can encode the {request-param:paramname} in a
sitemap? I'm trying to use a request parameter in the
HTMLGenerator
as part
On 20.01.2004 11:14, Nicolas Toper wrote:
Hi,
If I'm using UTF-8 encoding with a French file special characters as é or à
makes an error...
I don't understand why... Isn't UTF-8 supposed to integrate this characters or
did I miss something?
Is it this one:
No
Le Mardi 20 Janvier 2004 12:05, Joerg Heinicke a écrit :
On 20.01.2004 11:14, Nicolas Toper wrote:
Hi,
If I'm using UTF-8 encoding with a French file special characters as é
or à makes an error...
I don't understand why... Isn't UTF-8 supposed to integrate this
characters or did
Hi,
be carefull.
ISO-8859-1 ASCII goes from 0 to 255
UTF-8 ASCII goes from 0 to 127
For example,
A é is the 233 character in the ISO-8859-1 ASCII table. It will be
encoded on one octet.
But with UTF-8 this character is not included in the ASCII table so it will
be converted from ISO-8859-1 to
Are you sure, the viewer is UTF8?
-Message d'origine-
De : Lionel Crine [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 27 novembre 2003 11:58
À : [EMAIL PROTECTED]
Objet : encoding, UTF-8
Hi,
I want to put the entire plateform into UTF-8. For now, cocoon is using
ISO-8859-1.
Here what I've
i'm allmost sure that the entire cocoon has UTF-8 as default encoding
corect me
--stavros
On Thu, 27 Nov 2003, Nicolas Toper wrote:
Are you sure, the viewer is UTF8?
-Message d'origine-
De : Lionel Crine [mailto:[EMAIL PROTECTED]
Envoy : jeudi 27 novembre 2003 11:58
:
From: Nicolas Toper [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 Nov 2003 12:16:11 +0100
To: [EMAIL PROTECTED]
Subject: RE: encoding, UTF-8
Are you sure, the viewer is UTF8?
-Message d'origine-
De : Lionel Crine [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 27
Did you set the form-encoding parameter in web.xml?
Guido
Lionel Crine wrote:
Hi,
I want to put the entire plateform into UTF-8. For now, cocoon is
using ISO-8859-1.
Here what I've already done :
map:serializer logger=sitemap.serializer.html
mime-type=text/html name=html
Hallo Lionel,
we had problems with this issues several
times.
Play arround with these two
initparams.
The strange thing was, that on different engines we
had to change the container-encoding to avoid encoding problems.
Now we do not have any problems with encoding
anymore and we don't
In fact :
The encoding parameter for the serializer modify the ?xml ...?
declaration according the the value.
Now I'm sure of that, my previous message was false.
Now, I'm using that :
map:serializer logger=sitemap.serializer.html
mime-type=text/html name=html pool-grow=4 pool-max=32
we have solve the same problem using action
map:actions
map:action name=set-encoding
src=org.apache.cocoon.acting.SetCharacterEncodingAction/
...
...
...
!-- === order form === --
map:pipeline
Thx.
At 16:03 27/11/2003 +0200, you wrote:
we have solve the same problem using action
map:actions
map:action name=set-encoding
src=org.apache.cocoon.acting.SetCharacterEncodingAction/
...
...
...
!-- === order form === --
Hi,
It really seams that this is the reason!! I had master copy on Tomcat
4.1.27, and the new copy on 4.1.29. As I changed to 4.1.27 everything is
fine :-) I'm pretty suprised, I must say!
Thanks for help!
Marcin
On Tue, Nov 18, 2003 at 11:10:38AM +0100, [EMAIL PROTECTED] wrote:
Hi,
I have
Hi,
I've asked the same question yesterday. And the solution (unfortunately)
was exactly the same!
Regards,
Marcin
This looks to be a problem with Tomcat 4.1.29. I'm not quite sure how
to resolve it, but running Cocoon 2.1.3 in Tomcat 4.1.27 seems to work.
- Justin
On Nov 18, 2003, at 4:42
On Tue, Nov 18, 2003 at 11:10:38AM +0100, [EMAIL PROTECTED] wrote:
Hi,
I have copied my Cocoon based WebApp from one Tomcat to another. On
the new copy, the page is displayed incorrectly - browser takes
encoding as ISO-8859-1 instead of UTF-8. When I change encoding
manually to UTF-8
I guess you build URLs using request parameters with German letters
(something like a href=test.html?myname=Jörg/). This URL is encoded
using UTF-8, while you have your documents encoded in ISO-8859-1 (configured
at the serializer).
If all these guesses are true you have different
on Tue, 19 Aug 2003 23:51:20 -0600 (CST) Antonio Gallardo
[EMAIL PROTECTED] wrote:
Hi:
Why the web.xml of cocoon is still having:
?xml version=1.0 encoding=ISO-8859-1?
I already changed it to
?xml version=1.0 encoding=UTF-8?
and it works.
Of course it works, UTF-8 is superset of
Joerg Heinicke dijo:
Is there any problem with ISO-8859-1 or do you think switching to UTF-8
would be good in general?
I think switching all to UTF-8 would be good in general. It is a step
ahead. UTF-8 is the default standard of every XML doc. The ISO-8859-1 is a
deprecated encoding. The IETF
rufio dijo:
Of course it works, UTF-8 is superset of ISO-8859-1.
Yep. But the correct would be have all in UTF-8 and not using the
deprecated ISO-8859-1
Antonio Gallardo.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Wow, what a /hymn/ on UTF-8 :-) I know the advantages of UTF-8 and even
if there is currently no need for switching I did it. The conversion was
done hopefully correctly by jEdit.
Joerg
Antonio Gallardo wrote:
Joerg Heinicke dijo:
Is there any problem with ISO-8859-1 or do you think switching
Joerg Heinicke dijo:
Wow, what a /hymn/ on UTF-8 :-) I know the advantages of UTF-8 and even
if there is currently no need for switching I did it. The conversion was
done hopefully correctly by jEdit.
Thanks, I know this is a little change (and maybe meaningless), but I hope
it would help us
82 matches
Mail list logo
