with the XML Declaration
claiming ?xml version=1.0 encoding=ISO-8859-1?
But the home page is UTF-8, the ucc.xsl file is UTF-8, the xsl:output
inside it specifies UTF-8, and tidy.properties specifies
char-encoding=UTF-8.
Something, somewhere is interfering, and adding this
encoding=ISO-8859-1
(1) Check your web.xml. You should have the init-param form-encoding
set to UTF-8. (It's set by default to ISO-8859-1 on at least some
versions of Cocoon.)
(2) Check your sitemaps, starting from the Cocoon root sitemap. You can
set the encoding of your serializers there, for example
, since this can lead to all kinds of
cross-browser pain). The pipeline breaks if I bork the header altogether
(e.g., I put in this/is/junk; charset=utf-8), but changing the charset
part to iso-8859-1 or this-is-not-an-encoding doesn't make any difference.
By the way, the stream generator sample
). The pipeline breaks if I bork the header
altogether (e.g., I put in this/is/junk; charset=utf-8), but
changing the charset part to iso-8859-1 or this-is-not-an-encoding
doesn't make any difference.
By the way, the stream generator sample at
[COCOON_HOME]/samples/stream/uploadstring breaks
I'm in the process of moving a large Cocoon application from Cocoon
2.1.4 to 2.1.11 (LTTP, I know).
* Platform: Ubuntu, Java 5, Jetty 6.1.15.
* In web.xml, container-encoding set to ISO-8859-1, form-encoding UTF-8.
Problem: when I POST form data to a stream generator, it behaves
);
...
}
I hope this help you.
Victor Pergolesi
_
From: Petteri Sulonen [mailto:petteri.sulo...@avaintec.com]
To: users@cocoon.apache.org
Sent: Wed, 18 Mar 2009 13:50:03 +
Subject: Stream generator encoding problem with Cocoon 2.1.11
I'm in the process of moving a large Cocoon application
, 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
jogil...@hotmail.com
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
€...
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
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
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:
â
On 26.02.2008 16:05, Stefan Ludwig wrote:
my problem is solved!
now i use the FileGenerator. configured like this:
map:generate type=file src={request-param:file}/
I'm really surprised this works. It seems to be a valid alternative to
upload protocol. But then I wonder why having the latter
at
org.apache.cocoon.servletservice.components.ServletSource.createServletC
onnection(ServletSource.java:142)
[...]
So, my questions are
a) Should ServletSource be encoding the URL it receives ? I would've
thought probably not...
a) How can I re-encode the part of the URL I am passing as a request
Hi Robin
Robin Wyles schrieb:
Hi All,
[...]
So, my questions are
a) Should ServletSource be encoding the URL it receives ? I would've
thought probably not...
just my personal opinion: No. It would cause SSF to treat URLs different from
other protocols.
matching happens on de-coded URLS
Hi Rainer,
Thanks very much for your reply... shortly after writing my post I
thought about using an input module, and wrote my own url encoding
input module, not realising there was one already included with
Cocoon - after all these years using Cocoon I've never seen it!
However, I'm
no, i have no chance to set request encoding to the same as datafile
encoding.
situation:
i have to transform a xml-datafile (max file size about 20MB) to a pdf
or a excel document.
the customer want to have a simple html form to upload the xml file and
to set the mandatory informations like
for FileGenerator was:
map:generate type=file src=upload://file/
best regards
stefan
-Original Message-
From: Stefan Ludwig [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: users@cocoon.apache.org
Subject: Re: Max file size in FileGenerator and encoding in
StreamGenerator
Date: Tue, 26 Feb 2008
On 19.02.2008, at 09:47, Stefan Ludwig wrote:
The StreamGenerator works fine with large files (from 20MByte XML-Data
to PDF in just 2mins!), but encoding doesn't work. This generator gets
encoding from request, but i need the encoding from XML-Datafile.
Is there any chance that you make
solution is described here:
http://www.nabble.com/Cocoon%2C-UTF-8-and-encodeURI-to7587213.html#a7595919
K-D
Grzegorz Tańczyk wrote:
Hello,
Can You tell me if it is a known issue that matchers malform
encoding of nonUS characters? I have no problems when I run Cocoon
2.1.5.1
Hi,
I got the same problem in 2.1.11... what's the solution?
regards
dynnamitt.
Grzegorz Tańczyk wrote:
Hello,
Can You tell me if it is a known issue that matchers malform
encoding of nonUS characters? I have no problems when I run Cocoon
2.1.5.1 on Windows, but when I try
Thanks Joerg,
The problem turned out to be in web.xml
I amended
init-param
param-nameform-encoding/param-name
param-valueISO-8859-1/param-value
/init-param
To
init-param
param-nameform-encoding/param-name
param-valueUTF-8/param-value
/init-param
Peter Sparkes wrote:
The problem turned out to be in web.xml
I amended
param-nameform-encoding/param-name
param-valueISO-8859-1/param-value
To
param-nameform-encoding/param-name
param-valueUTF-8/param-value
and now everything is in UTF-8 and works properly
Peter Sparkes wrote:
The problem turned out to be in web.xml
I amended
param-nameform-encoding/param-name
param-valueISO-8859-1/param-value
To
param-nameform-encoding/param-name
param-valueUTF-8/param-value
and now everything is in UTF-8
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
param-nameform-encoding/param-name
param-valueISO-8859-1/param-value
To
param-nameform-encoding
On 23.01.2008 03:51, Tobia Conforto wrote:
The problem turned out to be in web.xml
I amended
param-nameform-encoding/param-name
param-valueISO-8859-1/param-value
To
param-nameform-encoding/param-name
param-valueUTF-8/param-value
and now everything
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 â#130;¬ and UK pound sign £ to £
from the field widget. I am using the saveDocument function from the
samples and have set
=$contextPath
//search.html?queryString=xsl:value-of select=../@query-string
/amp;pagelength=xsl:value-of select=../@page-length /
/xsl:variable
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
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
);
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
On 12.12.2007 8:37 Uhr, Johannes Textor wrote:
Instead of creating a link with a href= 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
.
Hmm I was unaware of this problem, thanks for the info Joerg.
Instead of creating a link with a href= 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
with
xsl:variable name=baseurlxsl:value-of select=$contextPath
//search.html?queryString=xsl:value-of select=../@query-string
/amp;pagelength=xsl:value-of select=../@page-length /
/xsl:variable
Serializers are changed to ISO-8859-1 encoding
Need realy help for workaround or bugfixes
Unfortunately
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
: Re: Need help Character Encoding :-((
On 12.12.2007 8:37 Uhr, Johannes Textor wrote:
Instead of creating a link with a href= 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
Hi,
just for the record:
I've tried to edit /WEB-INF/tidy.properties and /WEB-INF/neko.properties,
but with no success.
I must have been fooled by the caching algorithm. In fact, it does work by
setting
http\://cyberneko.org/html/properties/default-encoding=UTF-8
in neko.properties
Hi,
when parsing HTML pages via HTTP using either the html or nekohtml encoder,
it doesn't correctly decode the German diaeresis characters (äöüÄÖÜ) and
others.
If have checked the page. It doesn't specify an encoding in the header
(plain HTML - maybe 3.2), but the page is delivered
Hi,
when parsing HTML pages via HTTP using either the html or nekohtml encoder,
it doesn't correctly decode the German diaeresis characters (äöüÄÖÜ) and
others.
If have checked the page. It doesn't specify an encoding in the header
(plain HTML - maybe 3.2), but the page is delivered
Hi Joerg
Joerg Heinicke a ecrit le 10/04/07 0:32:
Why do you need a specific encoding? Do your request or response got
parsed wrongly? There is a discouraging comment in the
WebServiceProxyGenerator [1, line 115 and following]:
Can you tell the actual error you want to solve? That might make
them. But of course it needs a hint how to parse the XML, which is
normally the XML declaration. But maybe it makes sense to add a
parameter for response parsing encoding to the generator for such cases
where there is no hint in the response.
Joerg
[1] http://svn.apache.org/viewvc?view
a Mozilla/5.0 (Windows... Firefox/2.0.0.3 user-agent) when I
try the web service directly in a browser (with the very same parameters).
Is the difference of user-agent provoking the difference of encoding ?
If so, how can I change the user-agent, I tried 'set-header' but it
didn't worked :
map:match
(and the remote server tell
I use a Mozilla/5.0 (Windows... Firefox/2.0.0.3 user-agent) when I
try the web service directly in a browser (with the very same parameters).
Why do you need a specific encoding? Do your request or response got
parsed wrongly? There is a discouraging comment
I have a flowscript that handles a simple contact form, sending an email
for each successful submit:
var form = new Form('cocoon:/contact.form')
form.showForm('contact.jx')
var fields = getFormFields(form)
var m = cocoon.getComponent(Packages.org.apache.cocoon.mail.MailSender.ROLE)
Tobia,
Don't you have to use m.setCharset('ISO8859-1') instead of
m.setCharset('utf-8') ?
Regards,
Lionel
Tobia a ecrit le 30/01/07 13:37:
I have a flowscript that handles a simple contact form, sending an email
for each successful submit:
var form = new Form('cocoon:/contact.form')
web.xml specify:
init-param
param-namecontainer-encoding/param-name
param-valueUTF-8/param-value
/init-param
init-param
param-nameform-encoding/param-name
param-valueUTF-8/param-value
/init-param
I think this did the trick with our applications.
Joost
Joost Kuif wrote:
init-param
param-nameform-encoding/param-name
param-valueUTF-8/param-value
/init-param
This did it for me, and it works on every browser.
It would have taken days to me to find that setting on my own.
Thank you!
Tobia
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
fd:upload id=upload mime-types=text/xml required=true/
XML file example : ?xml version=1.0 encoding=UTF-8
//xsp:attribute
/input
input type=submit name=submit value=Submit/
/form
the default font encoding is UTF-8.
the xsl like this:
img align=middle width=100 height=100
xsl:attribute name=srchttp://qrcode.jp/qr?q=xsl:value-of
select=form/input/@value/
/xsl:attribute
Shift_JIS will ok
johnson
許議中 提到:
Hi!
I want to use shift-jis and get this error
An error has occured
org.xml.sax.SAXParseException: Invalid encoding name Shift-JIS.
context://samples/i18n/hello.xml - 1:43
here is the xml
?xml version=1.0 encoding=Shift-JIS?
page xmlns:i18n
Hi!
I want to use shift-jis and get this error
An error has occured
org.xml.sax.SAXParseException: Invalid encoding name Shift-JIS.
context://samples/i18n/hello.xml - 1:43
here is the xml
?xml version=1.0 encoding=Shift-JIS?
page xmlns:i18n=http://apache.org/cocoon/i18n/2.1;
xmlns:jx
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
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
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
: fido.wd-2.net
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO
:
But is then the problem 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 component.
Ard
more a problem with the Rhino layer when
passing the objects from flowscript to java object.
Ard Schrijvers wrote:
But is then the problem not just in your myComponent? What
does it do?
Ard
Yes, the form encoding is well configured.
We are able to retrieve correctly
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 component.
Ard
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 component.
Ard Schrijvers wrote:
In your
.
Ard Schrijvers wrote:
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
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
Hello,
We are using Cocoon 2.1.9 (Windows XP/Tomcat 5.0.30 and Suse 9/Tomcat
5.0) and we have a problem with the encoding when passing Java objects
from the fowscript to an Avalon component.
Here is a sample of our code:
form.save(myBean);
try {
var myComponent
Ok … I have to
admit I haven’t used Modifyable Souces yet. I am used to XQuery with
update extensions and XML-DB api. I would check if it is possible to set the
encoding for the XML-Serializer. Since it is what generates the output.
Chris
Von:
Abbas Mousavi [mailto
and another point that I forgot:recently I have checked the cocoon.xconf bundeled with eXist distributionit uses org.apache.cocoon.components.source.impl.XMLDBSourceFactoryjust like the default cocoon.xconf which has the encoding problem.I wonder why the people at eXist project implemented
e.impl.XMLDBSourceFactory)so the correct configuration is component-instance class="org.exist.cocoon.XMLDBSourceFactory" name="xmldb"driver class="org.exist.xmldb.DatabaseImpl" type="exist"/...which works correctly and has no encoding problem.
Hi I am using eXist with cocoon as my xml database. I can copy xml documents to eXist by a webdav client and exist admin client, and also can retrieve them correctlyby xmldb:exist:// protocol, but when I want to write documents to exist with flowscript it does not writes the unicode documents
Hi Abbas,
I think you should check
the settings in your web.xml (container-encoding
and form-encoding) and the
serializer settings in the sitemap.xmap. I think I remember having some
encoding-problems with CForms. I guess cocoon will provide content encoded in
the format set here
Hi chrisI have set container-encoding and form encoding and serializer encoding to utf-8.also I can write the same pipeline to other sources (for example to hard disk)truly by the same mechanism.I think this problem has some thing related to eXist because I have tested the webdav interface
How exactly do you stroe
your data? Do you use XMLResourc.setContent(xml-string)? You could try explicitly
seting the input-Strings encoding using the String.getBytes(encoding) method.
If this doesn’t
help. I’d try the exist mailinglist, the guys there should be able to
help you solve
HiI dont know how to use String.getBytes(encoding) or XMLResourc.setContent(xml-string) , I explain my whole word:I have this in the sitemapmap:match pattern="*/*.xml"map:generate type="html" src=""/map:transform src=""/map:serialize type="
.
-Original Message-
From: Mark Lundquist [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 27. April 2006 03:18
To: [EMAIL PROTECTED]
Subject: HTTP encoding: trouble with '/'
Hello, me droogs...
Maybe someone can help me with this problem... I've got this Cocoon
site, and the graphic design
On Apr 26, 2006, at 11:14 PM, Nathaniel Alfred wrote:
I would guess that the difference between the laptop and the server is
a proxy the request is going through to reach the server.
D'oh!!! Now, why didn't I think of that?!
I don't understand that you have problems with slashes. Are you
Bonjour,
J'ai rencontré également des soucis avec l'encoding.
Le container-encoding détermine l'encoding du serveur où est installé cocoon.
(ou plutôt un des encodings dispo sur le serveur)
Le form-encoding détermine l'encoding de la request.
Celui ci, dans la config, ne propose qu'une valeur
Frédéric Glorieux wrote:
Cocoon 2.1.8
Dans mon web.xml, j'ai décommenter
init-param
param-namecontainer-encoding/param-name
param-valueutf-8/param-value
/init-param
J'ai l'impression que cela a un mauvais effet sur CForms (les valeurs
récupérées sont mal décodées), en
[container-encoding]
Perso, après quelques déboires et pas mal d'incantations vaudou pour
essayer d'avoir des accents dans mes formulaires, je passe tout en UTF-8
(xxx-encoding et sérialisation), et ça marche :-)
Conclusion : ne pas toucher à ce qui marche. Merci pour ce conseil
rassurant
Frédéric Glorieux wrote:
[container-encoding]
Perso, après quelques déboires et pas mal d'incantations vaudou pour
essayer d'avoir des accents dans mes formulaires, je passe tout en
UTF-8 (xxx-encoding et sérialisation), et ça marche :-)
Conclusion : ne pas toucher à ce qui marche. Merci
Cocoon 2.1.8
Dans mon web.xml, j'ai décommenter
init-param
param-namecontainer-encoding/param-name
param-valueutf-8/param-value
/init-param
J'ai l'impression que cela a un mauvais effet sur CForms (les valeurs
récupérées sont mal décodées), en
This helped me a lot.
map:act type=set-encoding
map:parameter name=form-encoding value=UTF-8/
/map:act
Greets
Nick Nagels
IT Specialist @ KULeuven for EuroGenTest
Derek Hohls wrote:
Antonio
I guess I did - strange that it happens only on the one
server.. maybe UNIX less forgiving
Nick
Thanks - where exactly in the pipeline did you insert this?
Derek
[EMAIL PROTECTED] 2006/02/08 11:56:39 AM
This helped me a lot.
map:act type=set-encoding
map:parameter name=form-encoding value=UTF-8/
/map:act
Greets
Nick Nagels
IT Specialist @ KULeuven for EuroGenTest
Derek
As the first statement
map:pipelines
map:pipeline
map:act type=set-encoding
map:parameter name=form-encoding value=UTF-8/
/map:act
This is the action it uses:
map:action name=set-encoding
src=org.apache.cocoon.acting.SetCharacterEncodingAction/
Hope
are using iso-8859-1, just
search for a file that's not in the right encoding, or a string 160 in
your form files and delete this... (ultraedit or grep, depending on your
system :-) ) probably one of your coders or editors uses utf-8, so
you'll accidently inserted this utf-8 fragment (and doesn't know
2006/2/8, Derek Hohls [EMAIL PROTECTED]:
What I have done;
Tried all the settings as suggested so far in this thread...
switching everything to UTF-8 - checked ALL my files for any
sign of ISO... (to avoid mixing concerns) ... still no luck!
Looked in the offending forms and found the #160;
.:
java.lang.RuntimeException:
org.xml.sax.SAXException:
Attempt to output character of integral value 160 that is not represented in specified output encoding of .
Basically you're already deep in trouble because I think you've
obviously a mixture of UTF-8 and other encodings... which is really a
pain
value 160 that is not represented in specified output encoding of .Basically you're already deep in trouble because I think you've obviously a mixture of UTF-8 and other encodings... which is really a pain in the a...So, first I'd try to replace the default sax parser with saxon. this will cause some headache (abo
Hi Derek,
I encountered encoding problems here and there in java for a long time,
because the JVM could not be enabled to use UTF-8 correctly because the
underlying libc is not UTF-8 (or any other encoding) aware, expecially
on Linux/*nix machines.
Since you are having this problem
the database) is:
org.apache.cocoon.ProcessingException:
Failed to execute pipeline.:
java.lang.RuntimeException:
org.xml.sax.SAXException:
Attempt to output character of integral value 160 that is not represented in
specified output encoding of .
[and no, there is no word missing just before
out the escaped chars. but as you are using iso-8859-1, just
search for a file that's not in the right encoding, or a string 160 in
your form files and delete this... (ultraedit or grep, depending on your
system :-) ) probably one of your coders or editors uses utf-8, so
you'll accidently inserted
Le 7 févr. 06, à 14:37, Derek Hohls a écrit :
...Attempt to output character of integral value 160 that is not
represented in specified output encoding of ...
Might be related to your JVMs running with different default encodings.
The JVM's default encoding can be set with the file.encoding
out the escaped chars. but as you are using iso-8859-1, just
search for a file that's not in the right encoding, or a string 160 in
your form files and delete this... (ultraedit or grep, depending on your
system :-) ) probably one of your coders or editors uses utf-8, so
you'll accidently
2006/2/8, Derek Hohls [EMAIL PROTECTED]:
PS Is there any good reason to prefer ISO-8859-1 over
UTF-8 ... these seem to be used interchangeably, but I
guess they are not?
They are different.
If your app only uses latin characters, you could use one or the
other. Otherwise, you should use
Antonio
I guess I did - strange that it happens only on the one
server.. maybe UNIX less forgiving than Linux.
Is there a default encoding that Cocoon makes use of?
IOW, if I import or reuse stylesheets from Cocoon samples
etc. will I expect to see these in UTF-8? Can I simply omit
Hello,
I am getting this exception when configuring a XHTMLSerializer with
UTF-8 encoding.
org.apache.cocoon.components.serializers.encoding.CharsetFactory$CharsetFactoryException:
The default encoding of this JVM ISO8859_15 is not supported
christian bindeballe wrote:
[...]
That's right. My mistake. I merely deducted the encoding from some
characters used inside the text of the feeds as for example 8221; which
are clearly non-Latin-1 characters. Since both feeds have ISO-8859-1 in
their response headers it means that these feeds
Edwin Kapauni schrieb:
Don't mix characterset and character encoding.
8221 is decimal notation of unicode character U+201D.
iso-8859-1 or utf-8 are just character encodings.
Encoding and formatting of both your sources is ok, but selection of
iso-8859-1 is a poor choice regarding readability
codepoints to byte-sequences is regulated by
the encoding
- there is more then one encoding to choose from: most common known are
iso-8859-1 (latin-1), cp1252, utf-16, utf-8. In other words the same
codepoint/glyph can be interchanged in totally different bytesequences
- latin-1 is a single byte encoding
christian bindeballe wrote:
[...]
I figured last night that what was causing my funny output was not
the character set nor the encoding, but the way my XSL handled the
feeds.
That's the reason why I recommended you omitting the transformation step
and to watch what's happening.
map:match
encoding.
cb
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
;)
it mentions the difficulty between distinguishing character sets and
character encoding.
See also the XML FAQ at http://xml.silmaril.ie/authors/characters/
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
Edwin Kapauni schrieb:
The first one goes into HTTP response header and is needed by any
browser to recognize the character encoding of the following content.
You may run your own test by just omitting it and checking HTTP response
header of your output.
The second one is telling
christian bindeballe wrote:
[...]
[quote] Since the servlet specification requires that the ISO-8859-1
encoding is used (by default), you should never change this value unless
you have a buggy servlet container.[/quote]
Citation without sources? Where did you get that nonsense from
101 - 200 of 565 matches
Mail list logo
