Petteri Sulonen wrote:
(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.)
/var/lib/tomcat5/webapps/cocoon/WEB-INF/web.xml says:
container-
(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 seria
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", but I'm at a loss where to look.
I also notice that all my generated HTML from Cocoon is being label
n the browser side, 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.
B
s with
headers on the browser side, 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
UTF-8");
...
}
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
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 as if
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
ä, 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
th 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
t;â€"...
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
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:
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 all?
last (non-working for bigger files) c
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
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 protoco
: servlet:exist:/db/feeds/
testfeed/entries?terms=one|two
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..
rds
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 11:01:10 +0100
no, i have no chance to set request encoding to the
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
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 mak
Hi,
I try to generate pdf and excel documents from a XML-Datafile (sent via
multipart/form-data). The datafile can be very large (about 20MByte) and
encoded in ISO or Unicode (ISO-8859-1 or UTF-8).
The FileGenerator works perfect with Encoding (gets encoding from
XML-Datafile), but with large
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 wh
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
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
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-
> 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
&
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
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
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
: 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 t
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
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 specific
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 decod
length=
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-88
}
};
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&#
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 s
et" 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
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
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.prope
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 delivere
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 delivere
able to handle
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/
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
e (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 discour
l
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).
Is the difference of user-agent provoking the difference of encoding ?
If so, how can I change the user-agent, I tried 'set-head
Joost Kuif wrote:
>
> form-encoding
>UTF-8
>
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
-
To unsubscribe, e-
Hi Tobia,
1) In your formtemplate set the attribute enctype to "multipart/form-data"
2) In your pipeline, use:
3) In your cocoon web.xml specify:
container-encoding
UTF-8
form-encoding
UTF-8
I think this did the
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')
form.s
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)
m.setSmtpHost
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 us
Hi!
I want to do a form, when input some words, it can use url to call other
web site to get a qrcode.
the xsp input like this:
the default font encoding is UTF-8.
the xsl like this:
http://qrcode.jp/qr?q=
it ok
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
>
&
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
http://apache.org/cocoon/i18n/2.1";
xmlns:jx="http://apache.org/coc
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,
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
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
Hi Mark,
in the web.xml of cocoon you can set the form-encoding
form-encoding
utf8
What does it look like?
Regards,
Reijn
Mark Lundquist wrote:
Hi all,
I'm using Cocoon 2.1.8 w/ Jetty, and I'm having a problem with a
character submitted in a form textarea
54c3614.continue HTTP/1.1
Host: 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: gz
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 the accentuated characters
from the form in the flowsript.
The problem occurs when we pass the bean from
omponent.
> >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 f
wscript 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 the accentuated characters from the form in
the flowsript.
The problem occurs when we pass
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 Schrij
ava 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 the accentuated characters from the
form in the flowsript.
The problem occurs when w
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
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
In your web.xml, you have the form-encoding configured correctly??
For example,
form-encoding
utf8
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 a problem with the encoding when passi
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
t;xmldb"> but this is not the correct way, exist has its own source factory (org.exist.cocoon.XMLDBSourceFactory)that is a modified version of (org.apache.cocoon.components.source.impl.XMLDBSourceFactory)so the correct configuration is ...which works correctly and has no encoding problem.
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 the
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
HiI dont know how to use String.getBytes(encoding) or XMLResourc.setContent(xml-string) , I explain my whole word:I have this in the sitemap that reads a html file from the disk and generates an
xmland I have this function in my
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
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 to
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. And
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 corr
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 u
to:[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 calls for a big block of text at the top
of
Hello, me droogs...
Maybe someone can help me with this problem... I've got this Cocoon
site, and the graphic design calls for a big block of text at the top
of each page, in Gill Sans font with a drop-shadow effect. OK, fine
:-)... I put together a pipeline that renders the text in SVG a
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 on a
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 in the a...So, first I'd try to replace the de
e 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 .
Basically you're already deep in trouble because I think you've
obviously a mixture of UTF-8 and other encodings... which
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 t
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 this utf-8 fragment
Hohls wrote:
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 thes
nge 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 simp
This helped me a lot.
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" than Linux.
Is there a "default" encoding that Cocoo
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? C
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 us
ot enough time, just
threw 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
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.enc
aped 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 ins
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
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
As I thought, it was the "html-include" serializer in
{base}/portal/sitemap.xmap that needed some fitting :)
cb
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Edwin Kapauni schrieb:
UTF-8
no
Best way to test is from a very minimalistic sample application with
just this serializer configuration and a short pipeline with only
UTF-8
no
http://www.netzpolitik.org/feed"/
christian bindeballe wrote:
[...]
also, Marc Portier wrote: (see this thread, message-ID
<[EMAIL PROTECTED]>)
never change your container-encoding unless you have a servlet container
of which you can specify the used encoding applied in decoding of url's
and request parameters
Edwin Kapauni schrieb:
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
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
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 the
//en.wikipedia.org/wiki/Character_encoding ;)
>
> it mentions the difficulty between distinguishing character sets and
> character encoding.
See also the XML FAQ at http://xml.silmaril.ie/authors/characters/
///Peter
encoding.
cb
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
101 - 200 of 622 matches
Mail list logo
