Greg,
On 3/31/22 12:17, Christopher Schultz wrote:
Greg,
On 3/29/22 13:41, gelo1234 wrote:
Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters:
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc
Hmm. Are the HTMLT
Hi,
To help isolate the issue, could you test with a simpler pipeline with
only generator/single simple XSLT/xml serializer ?
Cédric
Le 31/03/2022 à 17:54, Christopher Schultz a écrit :
Cédric,
On 3/29/22 12:52, Cédric Damioli wrote:
Do you use Xalan as XSLT Processor ?
If so, I remember h
Greg,
On 3/31/22 12:13, Christopher Schultz wrote:
On 3/29/22 13:37, gelo1234 wrote:
Hello Chris,
I think you will not get any icon-type character on output without
using proper font rendering - like Emoji support? Emoji might not be
supported by default in Cocoon.
This isn't a font-render
Greg,
On 3/29/22 13:41, gelo1234 wrote:
Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters:
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc
Hmm. Are the HTMLT / XHTMLT serializers built-in? I have disabled all
b
Greg,
On 3/29/22 13:37, gelo1234 wrote:
Hello Chris,
I think you will not get any icon-type character on output without using
proper font rendering - like Emoji support? Emoji might not be supported
by default in Cocoon.
This isn't a font-rendering issue; it's just ... wrong. Either the raw
Cédric,
On 3/29/22 12:52, Cédric Damioli wrote:
Do you use Xalan as XSLT Processor ?
If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617
which could be a cause of your issue.
I resolved it on my side years ago by compiling my own patched version
> of Xalan.
I'm using whatever
Chris,
Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters:
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc
Greetings,
Greg
wt., 29 mar 2022 o 19:37 gelo1234 napisał(a):
> Hello Chris,
>
> I think you will not get
Hello Chris,
I think you will not get any icon-type character on output without using
proper font rendering - like Emoji support? Emoji might not be supported by
default in Cocoon.
So this might be the reason why you get HTML entities instead of
Emoji-icons.
Also notice:
https://www.mail-archive.c
Do you use Xalan as XSLT Processor ?
If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617
which could be a cause of your issue.
I resolved it on my side years ago by compiling my own patched version
of Xalan.
For "markers", you may use labels on your sitemap steps associated wit
Cédric,
On 3/29/22 12:06, Cédric Damioli wrote:
Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?
It's somewhat straightforward:
https://source/"; />
wrote:
All,
I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
a servlet generating XML in UTF-8 encoding and I have a pipeline
with a few transforms in it, ultimately serializing to XHTML.
If I have a Unicode character in the XML which is outside of the
BMP, such as t
topher Schultz wrote:
All,
Some additional information at the end.
On 10/30/18 11:58, Christopher Schultz wrote:
All,
I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
a servlet generating XML in UTF-8 encoding and I have a pipeline
with a few transforms in it, ultima
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
Some additional information at the end.
On 10/30/18 11:58, Christopher Schultz wrote:
> All,
>
> I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
> a servlet generating XML in UTF-8 encoding and I have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have a
servlet generating XML in UTF-8 encoding and I have a pipeline with a
few transforms in it, ultimately serializing to XHTML.
If I have a Unicode character in the XML
, ⅗ 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
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
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
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
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
Just wanted to have a look.
I compared to with what I had, and it is the same. No luck.
On Thu, Sep 20, 2012 at 3:18 PM, wrote:
>
> if you are referring to this part, it's like this:
>
> container-**encoding
> ISO-8859-1
>
>
>
>
&
if you are referring to this part, it's like this:
container-encoding
ISO-8859-1
form-encoding
UTF-8
Or some else setting you are interested in?
This works home and this works in another remote server. I also copied
the java from working s
What does your web.xml look like?
On Thu, Sep 20, 2012 at 2:51 PM, wrote:
>
> Also XML-element tags in xsp-files have question marks instead of scands.
> I also verified that the database is delivering the right stuff. The same
> database used in this (http://88.148.163.59/cocoon/**
> palaute_ap
Also XML-element tags in xsp-files have question marks instead of
scands.
I also verified that the database is delivering the right stuff. The
same database used in this
(http://88.148.163.59/cocoon/palaute_app/linkki/html/1059), works with
local copy of cocoon.
Updated data, just checked t
Hi Jos,
yep, that's right, the text seems not to be utf-8.
Same problem occurs in another page where the text not working comes
from flowscript.
1) No it's not, it's a copy. But you can verify everything is ok in
http://88.148.163.59/cocoon/palaute_app/linkki/1059 (database reader).
Seems to m
Hi Mika,
Your page declares utf-8 as a character set, but the text you send is not
in utf-8. Hence the question mark
characters.
Question 1: is it the same database that is accessed? (or rather, a copy)
Question 2: what is the database url?
Cheers,
Jos
On Thu, Sep 20, 2012 at 9:22 AM, wrote:
>
d you explicitly
set the encoding?
http://cocoon.apache.org/2.1/userdocs/default/html-serializer.html
http://cocoon.apache.org/2.1/userdocs/xhtml-serializer.html
-Original Message-
From: m...@digikartta.net [mailto:m...@digikartta.net]
Sent: Thursday, September 20, 2012 10:11 AM
To:
Can you check which serializer you're using and did you explicitly set the
encoding?
http://cocoon.apache.org/2.1/userdocs/default/html-serializer.html
http://cocoon.apache.org/2.1/userdocs/xhtml-serializer.html
-Original Message-
From: m...@digikartta.net [mai
Yep,
I noticed that too. But where it is coming from?
Remember, the whole cocoon directory is a copy from old to new.
I also copied e.g. Tomcat server.xml same way.
- mika -
On Thu, 20 Sep 2012 10:03:46 +0200, Robby Pelssers
wrote:
The one that does not work has following encoding in
The one that does not work has following encoding in
Robby
-Original Message-
From: m...@digikartta.net [mailto:m...@digikartta.net]
Sent: Thursday, September 20, 2012 9:23 AM
To: users@cocoon.apache.org
Subject: more encoding problems
Hi,
C2.11, I moved my app from one server to
Hi,
C2.11, I moved my app from one server to another, which resulted some
pages to broke that is scands won't encode properly.
I have this in my sitemap:
You can try this out:
Old server
http://77.240.23.91/cocoon/palaute_app/linkki/841 works
http://77.240.23.91/cocoon/palaut
lly hard to
properly help you out here.
I know that for C2.2 we have to set 2 properties:
org.apache.cocoon.containerencoding=utf-8
org.apache.cocoon.formencoding=utf-8
As a side note: Check encoding in your xslt's
indent="yes"/>
Robby
-Original Message-
From: m.
Problem is I'm not using C2.1.x anymore so it's really hard to properly help
you out here.
I know that for C2.2 we have to set 2 properties:
org.apache.cocoon.containerencoding=utf-8
org.apache.cocoon.formencoding=utf-8
As a side note: Check encoding in your xslt's
Robby
,
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, August 29, 2012 12:
, August 29, 2012 12:37 PM
To: users@cocoon.apache.org
Subject: encoding issue
Hi.
C2.11 and CForms. I loose scands after binding, they are all replaced
by a question mark. I have read all the sites possible to resolve this,
but without luck. All is UTF-8, except container-encoding iso-8859-1
, August 29, 2012 12:37 PM
To: users@cocoon.apache.org
Subject: encoding issue
Hi.
C2.11 and CForms. I loose scands after binding, they are all replaced
by a question mark. I have read all the sites possible to resolve this,
but without luck. All is UTF-8, except container-encoding iso-8859-1
Hi.
C2.11 and CForms. I loose scands after binding, they are all replaced
by a question mark. I have read all the sites possible to resolve this,
but without luck. All is UTF-8, except container-encoding iso-8859-1.
Changing container to utf-8 will change the question marks to some other
I did found a workaround by the way…
If you add an extra request parameter called cocoon-form-encoding and set it to
utf-8 it will work
Snippet from RequestProcessor.java:
protected Environment getEnvironment(String uri,
HttpServletRequest req
Hi all,
Just wanted to have a short discussion on an issue that I wasted quite some
hours on. Let me first explain that I configured my cocoon block with
following two properties as per http://cocoon.apache.org/2.2/1366_1_1.html :
org.apache.cocoon.containerencoding=UTF-8
org.apache.cocoon.for
when I implement a
>> feature
>> some national character (ĐđČčĆć in unicode notation) remain as "#"
>> signs).
>>
>> Is this really a bug or there is a solution, so please once more
>> apologize
>> for some dumb entries in this issu
4. Dezember 2011 13:02
> To: users@cocoon.apache.org
> Subject: XML-> PDF bad encoding
>
>
> Appologize in front if this is somewhere explained, but as I'm not guru in
> Cocoon, after 5 days of google search and testing all possible
> combinations,
> haven't fou
l character (ĐđČčĆć in unicode notation) remain as "#" signs).
>
> Is this really a bug or there is a solution, so please once more apologize
> for some dumb entries in this issue, but pretty lost in this case.
> Regards,
> Funky
> --
> View this message in conte
]
Sent: Sonntag, 4. Dezember 2011 13:02
To: users@cocoon.apache.org
Subject: XML-> PDF bad encoding
Appologize in front if this is somewhere explained, but as I'm not guru in
Cocoon, after 5 days of google search and testing all possible combinations,
haven't found a solution. So
feature
some national character (ĐđČčĆć in unicode notation) remain as "#" signs).
Is this really a bug or there is a solution, so please once more apologize
for some dumb entries in this issue, but pretty lost in this case.
Regards,
Funky
--
View this message in context
-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 th
Setting container-encoding to UTF-8 enables you to share your servlet container
(keeping its Latin1 default) with other applications not supporting UTF-8 (and
not fiddling with encodings...), if relevant (we had the case...).
Have a look at http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
I
On 17/12/10 15:37, Laurent Medioni wrote:
> What is your
>
> container-encoding
> UTF-8
>
> In web.xml ?
Interesting. ISO-8859-1, because
I wouldn't call Tomcat buggy, exactly, but the servlet spec made a poor
choice in making ISO-8859-1 the default, giv
What is your
container-encoding
UTF-8
In web.xml ?
• This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
• Any
t
coming from? Is Cocoon sticking it in by itself? The page template which
I take for the framework is
http://www.ucc.ie/en/old-design-base/
and that says quite clearly
Something, somewhere is sticking a bogus encoding in the works.
///Peter
I restored the Xalan settings after (failing to) add Saxon by copying
Emacs' ~ backup copies of cocoon.xconf and sitemap.xmap, but now
suddenly there are Unicode replacement characters (U+FFFD) appearing for
accents in pages which were working before.
The data is taken from a feed from an Oracle A
So this changed from 2.1, pity…
From: Ali Mahdoui [mailto:mahd...@hotmail.de]
Sent: lundi, 8. novembre 2010 13:08
To: Cocoon users
Subject: RE: Set Encoding for XMLSerializer dynamically
Hi,
no that does not help (and the syntax is not allowed in the
Hi,no that does not help (and the syntax is not allowed in the schema of the
sitemap)thanksAli
> Subject: RE: Set Encoding for XMLSerializer dynamically
> Date: Mon, 8 Nov 2010 12:56:11 +0100
> From: lmedi...@odyssey-group.com
> To: users@cocoon.apache.org
>
> Hi
Hi,
have you tried:
...
"{charsetEncoding}"
...
?
Laurent
From: Ali Mahdoui [mailto:mahd...@hotmail.de]
Sent: dimanche, 7. novembre 2010 12:10
To: Cocoon users; d...@cocoon.apache.org
Subject: Set Encoding for XML
Hi,i am using cocoon 2.2 and i want to set the encoding for the xml serializer
dynamically depending on the return value of a previous action.for example like
this
...For the moment i can only set the encoding in the bean definition... Is
that possible? Thanks
e is
text/plain body set with MimeMessage variable and when mime-type is another
value the body field set with MimeBodyPart variable.
It seem that MimeMessage variable does not manage encoding correctly.
Anyway for me the matter is fixed.
Thanks all.
--
View this message in context:
http://ol
the garbled characters and then went
back through the method calls to find the point where they were created.
In my case it was the tomcat Connector object using its default
character encoding.
On 10/8/10 8:02 AM, Charles Yates wrote:
Hello, I think you need to set URIencoding in your tomcat
Hi Charles
I have configured the parameter URIEncoding to UTF-8, even I used the
parameter useBodyEncodingForURI but I go on with the same problem.
--
View this message in context:
http://old.nabble.com/problem-encoding-using-SendMailTransformer-tp29886850p29931532.html
Sent from the Cocoon
The form used get method, because with the post method not work the
"request-param" of Cocoon.
--
View this message in context:
http://old.nabble.com/problem-encoding-using-SendMailTransformer-tp29886850p29931504.html
Sent from the Cocoon - Users mailing list archive at
rEncodingFilter in your code base.
>
>
> Yes, SetCharacterEncodingFilter is a filter defined on web.xml of Cocoon
> Application:
>
> SetCharacterEncoding
>
> es.sadesi.filter.SetCharacterEncodingFilter
>
> encoding
> UTF-8
Hello, I think you need to set URIencoding in your tomcat connector:
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Common_Attributes
|URIEncoding|
This specifies the character encoding used to decode the URI bytes,
after %xx decoding the URL. If not specified, ISO-8859-1 will be
Hi Andre
I load file with HTTP header of web page to send email:
http://old.nabble.com/file/p29914700/HTTP_header_Email-send.txt
HTTP_header_Email-send.txt
I see that Accept-Charset parameter contains UTF-8 and in query-string data
are codified right.
Besides I check encoding browser is UTF-8
, SetCharacterEncodingFilter is a filter defined on web.xml of Cocoon
Application:
SetCharacterEncoding
es.sadesi.filter.SetCharacterEncodingFilter
encoding
UTF-8
..
SetCharacterEncoding
DispatcherServlet
.
I have test put
defined on web.xml of Cocoon
Application:
SetCharacterEncoding
es.sadesi.filter.SetCharacterEncodingFilter
encoding
UTF-8
..
SetCharacterEncoding
DispatcherServlet
.
I have test put encoding on HTML FORM, so with the parameter:
accept
ail (It is a class that extend from AbstractSAXTransformer, really is
> @version $Id: SendMailTransformer.java 607381 2007-12-29 05:42:58Z
> vgritsenko) then the field body has lost the encoding.
>
> However I come back to do the test that you tell me.
can be the problematic part, si
r, really is
@version $Id: SendMailTransformer.java 607381 2007-12-29 05:42:58Z
vgritsenko) then the field body has lost the encoding.
However I come back to do the test that you tell me.
--
View this message in context:
http://old.nabble.com/problem-encoding-using-SendMailTransformer-tp29886850p29897843.
nderlying
server has the locale UTF8_ES?
> It's seems that all text lose encoding, but I have checked that emails have
> subject correct and bad encoding on body field.
> I load a test email:
> http://old.nabble.com/file/p29889393/test-email.txt test-email.txt
Hmm, let us do
...@juntadeandalucia.es
It's seems that all text lose encoding, but I have checked that emails have
subject correct and bad encoding on body field.
I load a test email:
http://old.nabble.com/file/p29889393/test-email.txt test-email.txt
--
View this message in context:
http://old.nabble.com/pr
On Tue, 2010-10-05 at 05:26 -0700, mvalencia wrote:
> Hi all
>
> I have a problem using the code of:
> org.apache.cocoon.mail.transformation.SendMailTransformer, when I send an
> email, target user always receive the field body with strange characters, so
> seemd bad encodi
Hi all
I have a problem using the code of:
org.apache.cocoon.mail.transformation.SendMailTransformer, when I send an
email, target user always receive the field body with strange characters, so
seemd bad encoding, and is curious only the field body, the subject is ok.
I work with encoding UTF
Hello
I followed the instruction here http://cocoon.apache.org/2.2/1366_1_1.html
. For cocoon-2.1.11 I set
container-encoding
UTF-8
form-encoding
UTF-8
in my web.xml instead of org.apache.cocoon.containerencoding=utf-8 and
default. you can switch completely
> to UTF-8 with:
> - send html content in utf-8
> - set container-encoding to utf-8
> - set form-encoding to utf-8
> - set URIEncoding to utf-8
> - and include a class like SetCharacterEncodingFilter to set request
> character encoding
Note th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron,
On 9/29/2010 5:43 AM, Ron Van den Branden wrote:
> There is stated that
> apparently (and counter-intuitively, IMO), 'request parameters are
> always decoded using ISO-8859-1 ', and that consequently
> 'container_encoding should always be ISO-88
hi,
that arabic character should fail with latin1.
we see a difference between jetty and tomcat (6.0). tomcat follows specs
(see Andre's mail) and uses iso per default. you can switch completely
to UTF-8 with:
- send html content in utf-8
- set container-encoding to utf-8
- set
eager?) container-encoding parameter in
web.xml back to the default:
container-encoding
ISO-8859-1
Do I understand this correctly: you have encoded everything in UTF8,
but to able to read your input fields (UTF8) you need to decode their
value with ISO-8859-1 on the server?
Apparently: even A
Hi Thomas,
I'm not much of an expert in encoding matters, and could indeed be happy
with ISO-8859-1 instead of UTF-8.
However, testing with ISO-8859-1 set as container-encoding, even Arabic
input is passed through correctly: ص (Arabic letter 'sad' -
http://www.fileformat.in
ncoding should be the same one as
on your serializer.'.
And lo: changing the (over-eager?) container-encoding parameter in
web.xml back to the default:
container-encoding
ISO-8859-1
...seems to do the trick!
(phew!)
(note: I found this info also at
<http://wiki.apache.org/cocoo
does not (by default, UTF8). According
to specification, servlet engine are suppose to decode using ISO-8859-1
by default.
And lo: changing the (over-eager?) container-encoding parameter in
web.xml back to the default:
container-encoding
ISO-8859-1
Do I understand this correctly: you have encod
#x27;, and that consequently
'container_encoding should always be ISO-8859-1 (unless you have a
broken servlet container), and form_encoding should be the same one as
on your serializer.'.
And lo: changing the (over-eager?) container-encoding parameter in
web.xml back to the def
Hi,
check out request character encoding. For tomcat look at
http://confluence.atlassian.com/display/DOC/Configuring+Tomcat%27s+URI+encoding
and in your tomcat installation at
webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java
that worked for me
regards
Thomas
Am
direction.
Cheers,
Robby Pelssers
-Oorspronkelijk bericht-
Van: Ron Van den Branden [mailto:ron.vandenbran...@kantl.be]
Verzonden: wo 29-9-2010 11:11
Aan: users@cocoon.apache.org
Onderwerp: form encoding issues
Hi,
I'm stumbling on a character encoding issue (cocoon-2.1.10) and r
Hi,
I'm stumbling on a character encoding issue (cocoon-2.1.10) and really
can't see why. Apparently, text input in a form is passed on in a wrong
encoding. I've set Cocoon's default encoding in all thinkable places as
UTF-8:
web.xml:
Cocoon
container-e
Robby
-Oorspronkelijk bericht-
Van: Christopher Schultz [mailto:ch...@christopherschultz.net]
Verzonden: ma 13-9-2010 15:46
Aan: users@cocoon.apache.org
Onderwerp: Re: wrong encoding used when opening xml file with encoding utf-8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robby,
On 9/13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robby,
On 9/13/2010 8:31 AM, Robby Pelssers wrote:
> I'm generating an html table using Chinese characters and i set the encoding
> and mimetype as follows:
>
> var response = cocoon.response;
> res
: wrong encoding used when opening xml file with encoding utf-8
Hi all,
I'm generating an html table using Chinese characters and i set the encoding
and mimetype as follows:
var response = cocoon.response;
response.setContentType("application/vnd.ms-excel; cha
Hi all,
I'm generating an html table using Chinese characters and i set the encoding
and mimetype as follows:
var response = cocoon.response;
response.setContentType("application/vnd.ms-excel; charset=utf-8");
response.setHeader(
And that fixed the problem! Winner of the cake is Dominic Mitchell,
thanks a lot :-)
--
Med vennlig hilsen
Søren D. Krum
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@
Hi again!
:-) You see me smiling, the file encoding on the one machine is utf-8,
there it works, and the other is iso-8859-1. I am not sure if it fixes
the problem if i change it, but that i figure out soon (if i have
figured out why this differs at all, and how to change it.) :-) Thx for
this
On Thu, Feb 11, 2010 at 6:40 AM, Jos Snellings wrote:
> The two tomcat versions on the machines are the same, but, can you
> please make a diff between the two server.xml under $CATALINA_HOME/conf?
> Just to be sure ...
>
>
The other thing to check are the system properties file.encoding and
sun.j
The two tomcat versions on the machines are the same, but, can you
please make a diff between the two server.xml under $CATALINA_HOME/conf?
Just to be sure ...
Jos
On Thu, 2010-02-11 at 11:47 +0100, Søren Krum wrote:
> Hello!
>
> I have a small problem with a cocoon application and forms.
>
> T
Hello!
I have a small problem with a cocoon application and forms.
The application runs fine on one machine, but for some reason we want to
have a mirror of that machine. Higg Avalability and failover...
And here some more details: The part failing is a simple form build up
via cocoon forms (we
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 alre
(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.
> >
&g
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
;
>
> 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
t 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
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
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
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
ng '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 happenin
Ok.
I already found out how-to ;-)
http://cocoon.apache.org/2.2/1366_1_1.html 4. Setting Cocoon's
encoding (especially CForms) solved my issue.
Cheers,
Robby
From: Robby Pelssers [mailto:robby.pelss...@ciber.nl]
Sent: Wednesday, May 27, 2009 12:34 PM
To:
Hi all,
I can't seem to set encoding properly when writing xml to a file using
the write-source transformer. Googling around has not yet resulted in a
solution ;-(
In my sitemap I have declared the serializer like below:
UTF-8
All my styles
1 - 100 of 622 matches
Mail list logo
