RE: jfor encoding problem (POST encoding problem, indeed)
Bertrand, Thank you very much for your help!!! The html encoding was the problem!!! You are the man!!! I'm just so happy that it works. Charlene -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 3:25 AM To: [EMAIL PROTECTED] Subject: Fwd: jfor encoding problem (POST encoding problem, indeed) Hi Charlene, using the Orderpage example at http://localhost:8080/cocoon/samples/stream/order. If you add ?xml version=1.0 encoding=ISO-8859-1? at the top of the default xml and change Order Id to be Gérer, the next html page will display OrderIDGérer /OrderID as Order Id This has nothing to do with jfor - in your scenario, Cocoon's StreamGenerator is used to read your XML from an HTML form field. Your encoding problem is caused by the StreamGenerator using the wrong encoding when *reading data* from the form's POST request. To use a different encoding, you have to change the HTML code of the form, replacing meta http-equiv=Content-Type content=text/html; charset=UTF-8 with meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 for example. The encoding declaration that you used in the XML input field is probably handled correctly later on, but it's too late as the StreamGenerator has already read the data with the wrong encoding. Hope this helps, -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jfor encoding problem
Bertrand, Thank you very much for your reply. First of all, I'm using Cocoon-2.1m2 and jdk1.3.1. I am using the xercesImpl-2.4.1.jar (875KB), xalan-20030506.jar(2571KB), and xml-apis.jar(122kb) in tomcat4.0.5's common/lib dir. You can easily reproduce it by using the Orderpage example at http://localhost:8080/cocoon/samples/stream/order. If you add ?xml version=1.0 encoding=ISO-8859-1? at the top of the default xml and change Order Id to be Gérer, the next html page will display OrderIDGérer /OrderID as Order Id. It is doing the same thing to rtf report. Is it a parser problem? The same xml is parsed correctly in my struts application using different xml jars. I'm going to switch to using those jars to try if it will work. Thanks! Charlene -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 1:41 AM To: [EMAIL PROTECTED] Cc: Yan, Charlene Subject: Re: jfor encoding problem Le Lundi, 2 juin 2003, à 21:51 Europe/Zurich, Yan, Charlene a écrit : ... I'm trying to display accented characters correctly using jfor. However, when I try to run http://localhost:8080/cocoon/samples/jfor/minimal.rtf, it gives the following exception. I have put some French words such as Gére in the xml file... Is the encoding declaration correct in your input XML? Can you parse it with another tool (XML editor or parser)? If you can reduce your input to the smallest XML file that causes the problem, you could post it here so that someone can test it. Hope this helps, -- Bertrand Delacretaz (codeconsult.ch, jfor.org) XML, java, XSLT, Cocoon, FOP, mentoring/programming/teaching blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: jfor encoding problem
Bertrand, Thank you very much for your reply. First of all, I'm using Cocoon-2.1m2 and jdk1.3.1. I am using the xercesImpl-2.4.1.jar (875KB), xalan-20030506.jar(2571KB), and xml-apis.jar(122kb) in tomcat4.0.5's common/lib dir. You can easily reproduce it by using the Orderpage example at http://localhost:8080/cocoon/samples/stream/order. If you add ?xml version=1.0 encoding=ISO-8859-1? at the top of the default xml and change Order Id to be Gérer, the next html page will display OrderIDGérer /OrderID as Order Id. It is doing the same thing to rtf report. Is it a parser problem? The same xml is parsed correctly in my struts application using different xml jars. I'm going to switch to using those jars to try if it will work. Thanks! Charlene -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 1:41 AM To: [EMAIL PROTECTED] Cc: Yan, Charlene Subject: Re: jfor encoding problem Le Lundi, 2 juin 2003, à 21:51 Europe/Zurich, Yan, Charlene a écrit : ... I'm trying to display accented characters correctly using jfor. However, when I try to run http://localhost:8080/cocoon/samples/jfor/minimal.rtf, it gives the following exception. I have put some French words such as Gére in the xml file... Is the encoding declaration correct in your input XML? Can you parse it with another tool (XML editor or parser)? If you can reduce your input to the smallest XML file that causes the problem, you could post it here so that someone can test it. Hope this helps, -- Bertrand Delacretaz (codeconsult.ch, jfor.org) XML, java, XSLT, Cocoon, FOP, mentoring/programming/teaching blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: jfor encoding problem (POST encoding problem, indeed)
Hi Charlene, using the Orderpage example at http://localhost:8080/cocoon/samples/stream/order. If you add ?xml version=1.0 encoding=ISO-8859-1? at the top of the default xml and change Order Id to be Gérer, the next html page will display OrderIDGérer /OrderID as Order Id This has nothing to do with jfor - in your scenario, Cocoon's StreamGenerator is used to read your XML from an HTML form field. Your encoding problem is caused by the StreamGenerator using the wrong encoding when *reading data* from the form's POST request. To use a different encoding, you have to change the HTML code of the form, replacing meta http-equiv=Content-Type content=text/html; charset=UTF-8 with meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 for example. The encoding declaration that you used in the XML input field is probably handled correctly later on, but it's too late as the StreamGenerator has already read the data with the wrong encoding. Hope this helps, -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jfor encoding problem
Hi everyone, I'm trying to display accented characters correctly using jfor. However, when I try to run http://localhost:8080/cocoon/samples/jfor/minimal.rtf, it gives the following exception. I have put some French words such as Gére in the xml file. Looks like it is a parser issue. Anyone has any experience of this? Thanks so much for your help!! Charlene org.apache.cocoon.ProcessingException: Failed to execute pipeline.: java.io.UTFDataFormatException: Invalid byte 2 of 3-byte UTF-8 sequence. at org.apache.xerces.impl.io.UTF8Reader.invalidByte(Unknown Source) at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.scanContent(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:318) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:337) at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:198) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:140) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:262) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:679) at org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:415) at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:193) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:140) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:292) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:489) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:133) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:133) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
RE: jfor encoding problem
Charlene, it looks to me like your problem is not with jfor, but merely with parsing the XML source file. The parser thinks the French text is encoded as UTF-8, but my guess is that it actually uses ISO-8859-1. You should either open the XML file again and save it in UTF-8 format, or add an encoding declaration to the start of the file. e.g. ?xml version=1.0 encoding=ISO-8859-1? Cheers Con -Original Message- From: Yan, Charlene [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 07:52 To: [EMAIL PROTECTED] Subject: jfor encoding problem Hi everyone, I'm trying to display accented characters correctly using jfor. However, when I try to run http://localhost:8080/cocoon/samples/jfor/minimal.rtf, it gives the following exception. I have put some French words such as Gére in the xml file. Looks like it is a parser issue. Anyone has any experience of this? Thanks so much for your help!! attachment: winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jfor encoding problem
Con, Thanks for your reply. You are right that I should have encoding=ISO-8859-1 in the prolog. My current xml string doesn't have any declaration in the front. That's causing the problem. Thanks again! Charlene -Original Message- From: Conal Tuohy [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 5:05 PM To: [EMAIL PROTECTED] Subject: RE: jfor encoding problem Charlene, it looks to me like your problem is not with jfor, but merely with parsing the XML source file. The parser thinks the French text is encoded as UTF-8, but my guess is that it actually uses ISO-8859-1. You should either open the XML file again and save it in UTF-8 format, or add an encoding declaration to the start of the file. e.g. ?xml version=1.0 encoding=ISO-8859-1? Cheers Con -Original Message- From: Yan, Charlene [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 07:52 To: [EMAIL PROTECTED] Subject: jfor encoding problem Hi everyone, I'm trying to display accented characters correctly using jfor. However, when I try to run http://localhost:8080/cocoon/samples/jfor/minimal.rtf, it gives the following exception. I have put some French words such as Gére in the xml file. Looks like it is a parser issue. Anyone has any experience of this? Thanks so much for your help!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jfor encoding problem
Le Lundi, 2 juin 2003, à 21:51 Europe/Zurich, Yan, Charlene a écrit : ... I'm trying to display accented characters correctly using jfor. However, when I try to run http://localhost:8080/cocoon/samples/jfor/minimal.rtf, it gives the following exception. I have put some French words such as Gére in the xml file... Is the encoding declaration correct in your input XML? Can you parse it with another tool (XML editor or parser)? If you can reduce your input to the smallest XML file that causes the problem, you could post it here so that someone can test it. Hope this helps, -- Bertrand Delacretaz (codeconsult.ch, jfor.org) XML, java, XSLT, Cocoon, FOP, mentoring/programming/teaching blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jfor encoding problem
Le Mardi, 3 juin 2003, à 07:40 Europe/Zurich, Bertrand Delacretaz a écrit : ...Is the encoding declaration correct in your input XML? Sorry, didn't notice that this was answered already (but I had two other messages from the same person at my private address ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
encoding problem and xsp
Hello,
I'm having trouble with my xsp page and ISO-8859-1 encoding. I use
cocoon-2.0.4.
I have an xsp which get the request object of a form and create again a
link for an xsl page which redirect all to frame.
All generators, transfomers and serializer have to encoding parameter.
the sitemap :
!-- frame page --
map:match pattern=frame
map:generate type=serverpages src=proto/xsp/frame.xsp/
--create a link from request parameters
map:transform type=xslt src=proto/xsl/frame.xsl/ --
redirection to three pages (via frames).
map:serialize type=html/
/map:match
frame.xsl :
?xml version=1.0 encoding=ISO-8859-1?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:output encoding=ISO-8859-1/
xsl:template match=page
html
head
link rel=stylesheet type=text/css href=style.css/
/head
frameset rows=120,* cols=* frameborder=1 border=1
framespacing=0
!-- top frame --
frame name=top marginwidth=0 marginheight=0
scrolling=NOxsl:attribute name=srcxsl:value-of
select=content/link/top//xsl:attribute/frame
frameset cols=512,* rows=* frameborder=1 border=1
framespacing=0
!-- left frame --
frame name=search marginwidth=0
marginheight=0xsl:attribute name=srcxsl:value-of
select=content/link/left//xsl:attribute/frame -- this frame the the
link
!-- right frame --
frame name=empty marginwidth=0
marginheight=0xsl:attribute name=srcxsl:value-of
select=content/link/right//xsl:attribute/frame
/frameset
/frameset
noframes
body/
/noframes
/html
/xsl:template
/xsl:stylesheet
I also put a piece of frame.xsp :
?xml version=1.0 encoding=ISO-8859-1?
...
content
titlePrototype RLR/title
link
toptop/top
rightempty/right
leftsearch?xsp:logicfor(int i=0;i lt;
values.size();i++){/xsp:logicxsp:expr(String)tempVector.elementAt(i)/xsp:expr=xsp:expr(String)values.elementAt(i)/xsp:exprxsp:logicif(i
lt; values.size()-1){/xsp:logicamp;xsp:logic}}/xsp:logic/left
/link
/content
When the sitemap is called the accentuated characters are not well displayed.
I tried different things.
1/ the search(in left tag) page is a request generator which display :
...
requestParameters
parameter name=Contenu Texte_wordindex
valueécole/value -- I should see école (without quote)
/parameter
...
2/Furthermore I tried :
!-- frame page --
map:match pattern=frame
map:generate type=serverpages src=proto/xsp/frame.xsp/
--create a link from request parameters
map:serialize type=xmltext/
/map:match
This send an answer with good characters (é, â, etc, are well displayed).
Any clue ?
Lionel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
character encoding problem with resource reader?
I'm encountering a problem where this à character in a javascript file causes illegal character exceptions when read with the resource reader, but not when I open the file up directly from the filesystem. The character occurs inside a javascript character array [Ã]. Cocoon serves an html page and the .js file is then loaded as an included, also served by Cocoon. Any tricks to using the resource reader? My map:read tag has two parameters, type=resource and src. Do I need to specify encoding or mime-type to guarantee the accurate reading of text files? -Robert Douglass - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
encoding problem with xsp pages
Title: Nachricht hi, does anyone know why when using xsp or espacially esql, all characters like ä,ö,ü etc. are turned into funny characters like Ã(ö). i am trying to firgure out why that happens, and what unicode i have to use for languages using those characters, like e.g. german. thanks
esql character encoding problem
SORRY I'VE POSTED THIS YET BUT I FORGOT THE SUBJECT
I'm using ESQL to read and write data from a MYSQL database.
When I fill a field with non US characters, I see strange characters instead of the
ones I expected.
For example, when I write the string òàù, this is written like =a?, even if when I
red it with ESQL I get back the right string.
if I manually try from mysql prompt:
INSERT INTO table VALUES ('òàù'), the data is properly stored.
I've read an article at
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=103701015026425w=2
about a similar subject, but the author speak of a request generator and an XML
serializer, while I'm using an xsp generator and an html serializer:
map:match pattern=*/*.html
map:generate type=serverpages src={1}/{2}.xsp/
map:transform src={1}/{2}.xsl/
map:serialize type=html/
/map:match
They suggest to use the SetCharacterEncodingAction, but it hasn't solved my problem.
MySQL uses the default ISO-8859-1 encoding and I've added the ISO-8859-1 encoding to
the html serializer:
map:serializer logger=sitemap.serializer.html mime-type=text/html ...
encodingISO-8859-1/encoding
buffer-size1024/buffer-size
/map:serializer
I've tried to add the same encoding element to the serverpages generator, but it
didn't work.
Any suggestion?
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: esql character encoding problem
On 18.Dec.2002 -- 05:33 PM, [EMAIL PROTECTED] wrote:
SORRY I'VE POSTED THIS YET BUT I FORGOT THE SUBJECT
I'm using ESQL to read and write data from a MYSQL database.
When I fill a field with non US characters, I see strange characters instead of the
ones I expected.
For example, when I write the string òàù, this is written like =a?, even if when
I red it with ESQL I get back the right string.
if I manually try from mysql prompt:
INSERT INTO table VALUES ('òàù'), the data is properly stored.
I've read an article at
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=103701015026425w=2
about a similar subject, but the author speak of a request generator and an XML
serializer, while I'm using an xsp generator and an html serializer:
map:match pattern=*/*.html
map:generate type=serverpages src={1}/{2}.xsp/
map:transform src={1}/{2}.xsl/
map:serialize type=html/
/map:match
They suggest to use the SetCharacterEncodingAction, but it hasn't solved my problem.
MySQL uses the default ISO-8859-1 encoding and I've added the ISO-8859-1 encoding to
the html serializer:
map:serializer logger=sitemap.serializer.html mime-type=text/html ...
encodingISO-8859-1/encoding
buffer-size1024/buffer-size
/map:serializer
I've tried to add the same encoding element to the serverpages generator, but it
didn't work.
Hi,
your JDBC driver is supposed to return unicode to the application. If
it doesn't, it is either broken or you did not tell the DBMS the
correct character encoding. IOW this problem would appear with any
java application using your data. Please check.
The esql:get-string tag accepts an additional encoding parameter to do
conversions but YMMV. Search this list, there have been some good
explanations of this recently.
Chris.
Please follow up summarizing your problem and which suggested solution
/ information worked for you when you consider your problem
solved. Add SUMMARY: to the subject line. This will make FAQ
generation and searching the list easier. In addition, it makes
helping you more fun. Thank you.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
encoding problem
Hi all, I have a mySQL database with varchar fields containing foreign characters (ex. ë) Queries in the mySQL client yield correct results. When I do a query using the SQLTransfomer or esql the non ASCII characters are not presented properly. The ë is converted to ë Here's the pipeline: map:match pattern=members/getmemberdata map:generate type=serverpages src=test/test2.xsp/ map:transform type=sql map:parameter name=use-connection value=bvar/ /map:transform map:serialize type=xml/ /map:match All the serializers have the encodingUTF-8/encoding tag. The XSP file has a ?xml version=1.0 encoding=UTF-8? header. Isn't UTF-8 the correct encoding for European characters, or is something else wrong? Bert Using Cocoon 2.1 build 5/14/2002, Tomcat 4.0.1, JDK 1.3.1_02 This mail is written in 100% recycled electrons. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
R: encoding problem
Bert, try iso-8859-1 as the default XML serializer encoding. Best regards, P.S. Search the mailing list's archive for more information on serializers' encodings. Luca Morandini [EMAIL PROTECTED] -Messaggio originale- Da: Bert Van Kets [mailto:bert;vankets.com] Inviato: venerdì 25 ottobre 2002 13.39 A: [EMAIL PROTECTED] Oggetto: encoding problem Hi all, I have a mySQL database with varchar fields containing foreign characters (ex. ë) Queries in the mySQL client yield correct results. When I do a query using the SQLTransfomer or esql the non ASCII characters are not presented properly. The ë is converted to ë Here's the pipeline: map:match pattern=members/getmemberdata map:generate type=serverpages src=test/test2.xsp/ map:transform type=sql map:parameter name=use-connection value=bvar/ /map:transform map:serialize type=xml/ /map:match All the serializers have the encodingUTF-8/encoding tag. The XSP file has a ?xml version=1.0 encoding=UTF-8? header. Isn't UTF-8 the correct encoding for European characters, or is something else wrong? Bert Using Cocoon 2.1 build 5/14/2002, Tomcat 4.0.1, JDK 1.3.1_02 This mail is written in 100% recycled electrons. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] We are protected from the virus by Norton Antivirus Corporate Edition - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
R: R: encoding problem
Bert, I can only say that I had your same problem and solved it by replacing utf-8 with iso-8859-1 in the serializers' encoding; moreover, AFAIK, the default is utf-8 (as it should be, since XML has utf-8 as default). Best regards, Luca Morandini [EMAIL PROTECTED] -Messaggio originale- Da: Bert Van Kets [mailto:bert;vankets.com] Inviato: venerdì 25 ottobre 2002 16.33 A: [EMAIL PROTECTED] Oggetto: Re: R: encoding problem Of course I checked the mail logs before bugging the list. I could not find a solution though. I did find that I need to use UTF-8 and not iso-8859-1 (the Cocoon default) Searching through the source I found that a LOT of classes and XSLTs set the encoding to iso-8859-1, so I am replacing these to UTF-8 and will recompile afterwards. Lets see what that gives. Bert At 13:55 25/10/2002 +0200, you wrote: Bert, try iso-8859-1 as the default XML serializer encoding. Best regards, P.S. Search the mailing list's archive for more information on serializers' encodings. Luca Morandini [EMAIL PROTECTED] We are protected from the virus by Norton Antivirus Corporate Edition - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem
hy Bert, we had this problem too. look, if the map:actions section contains following:map:action name="set-encoding" src="org.apache.cocoon.acting.SetCharacterEncodingAction"/ and at the beginning of a pipelinemap:act type="set-encoding"map:parameter name="form-encoding" value="UTF-8"//map:act That should work. Boris - Original Message - From: Bert Van Kets To: [EMAIL PROTECTED] Sent: Friday, October 25, 2002 1:39 PM Subject: encoding problem Hi all,I have a mySQL database with varchar fields containing foreign characters (ex. ë) Queries in the mySQL client yield correct results.When I do a query using the SQLTransfomer or esql the non ASCII characters are not presented properly. The ë is converted to ëHere's the pipeline:map:match pattern="members/getmemberdata" map:generate type="serverpages" src="test/test2.xsp"/ map:transform type="sql" map:parameter name="use-connection" value="bvar"/ /map:transform map:serialize type="xml"//map:matchAll the serializers have the encodingUTF-8/encoding tag.The XSP file has a ?xml version="1.0" encoding="UTF-8"? header.Isn't UTF-8 the correct encoding for European characters, or is something else wrong?BertUsing Cocoon 2.1 build 5/14/2002, Tomcat 4.0.1, JDK 1.3.1_02This mail is written in 100% recycled electrons.-Please check that your question has not already been answered in theFAQ before posting. http://xml.apache.org/cocoon/faq/index.htmlTo unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem
I'm using a build from 14 May 2002. This doesn't have this action yet. I'll check a recent build and try that. Do you mean that I need to add this action at the beginning of EVERY pipeline? Bert At 16:55 25/10/2002 +0200, you wrote: hy Bert, we had this problem too. look, if the map:actions section contains following: map:action name=set-encoding src=org.apache.cocoon.acting.SetCharacterEncodingAction/ and at the beginning of a pipeline map:act type=set-encoding map:parameter name=form-encoding value=UTF-8/ /map:act That should work. Boris - Original Message - From: mailto:bert;vankets.comBert Van Kets To: mailto:cocoon-users;xml.apache.org[EMAIL PROTECTED] Sent: Friday, October 25, 2002 1:39 PM Subject: encoding problem Hi all, I have a mySQL database with varchar fields containing foreign characters (ex. ë) Queries in the mySQL client yield correct results. When I do a query using the SQLTransfomer or esql the non ASCII characters are not presented properly. The ë is converted to ë Here's the pipeline: map:match pattern=members/getmemberdata map:generate type=serverpages src=test/test2.xsp/ map:transform type=sql map:parameter name=use-connection value=bvar/ /map:transform map:serialize type=xml/ /map:match All the serializers have the encodingUTF-8/encoding tag. The XSP file has a ?xml version=1.0 encoding=UTF-8? header. Isn't UTF-8 the correct encoding for European characters, or is something else wrong? Bert Using Cocoon 2.1 build 5/14/2002, Tomcat 4.0.1, JDK 1.3.1_02 This mail is written in 100% recycled electrons. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.htmlhttp://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: mailto:cocoon-users-unsubscribe;xml.apache.org[EMAIL PROTECTED] For additional commands, e-mail: mailto:cocoon-users-help;xml.apache.org[EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: R: R: encoding problem
Hmm, strange. I started having the problem when the serializers were set to iso-8859-1. More reading and testing coming up. :( Bert At 16:47 25/10/2002 +0200, you wrote: Bert, I can only say that I had your same problem and solved it by replacing utf-8 with iso-8859-1 in the serializers' encoding; moreover, AFAIK, the default is utf-8 (as it should be, since XML has utf-8 as default). Best regards, Luca Morandini [EMAIL PROTECTED] -Messaggio originale- Da: Bert Van Kets [mailto:bert;vankets.com] Inviato: venerdì 25 ottobre 2002 16.33 A: [EMAIL PROTECTED] Oggetto: Re: R: encoding problem Of course I checked the mail logs before bugging the list. I could not find a solution though. I did find that I need to use UTF-8 and not iso-8859-1 (the Cocoon default) Searching through the source I found that a LOT of classes and XSLTs set the encoding to iso-8859-1, so I am replacing these to UTF-8 and will recompile afterwards. Lets see what that gives. Bert At 13:55 25/10/2002 +0200, you wrote: Bert, try iso-8859-1 as the default XML serializer encoding. Best regards, P.S. Search the mailing list's archive for more information on serializers' encodings. Luca Morandini [EMAIL PROTECTED] We are protected from the virus by Norton Antivirus Corporate Edition - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem
I had to insert it to the recent cocoon-distribution(2.03). But it worked immeadiatly and i think it will work without rebuilt in the dev-built as well. You can add it to a action-set map:action-setsmap:action-set name="mitarbeiter"map:act type="set-encoding"map:parameter name="form-encoding" value="UTF-8"//map:actmap:act type="session-validator"/map:act action="add_mit" type="add-mitarbeiter"/map:act action="delete_mit" type="del-mitarbeiter"/map:act action="update_mit" type="upd-mitarbeiter"//map:action-set/map:action-sets I don't know if there are other possibilities. Boris - Original Message - From: Bert Van Kets To: [EMAIL PROTECTED] Sent: Friday, October 25, 2002 4:58 PM Subject: Re: encoding problem I'm using a build from 14 May 2002. This doesn't have this action yet. I'll check a recent build and try that.Do you mean that I need to add this action at the beginning of EVERY pipeline?BertAt 16:55 25/10/2002 +0200, you wrote:hy Bert,we had this problem too.look, if the map:actions section contains following:map:action name="set-encoding" src="org.apache.cocoon.acting.SetCharacterEncodingAction"/and at the beginning of a pipelinemap:act type="set-encoding" map:parameter name="form-encoding" value="UTF-8"//map:actThat should work.Boris- Original Message -From: mailto:[EMAIL PROTECTED]Bert Van KetsTo: mailto:[EMAIL PROTECTED][EMAIL PROTECTED]Sent: Friday, October 25, 2002 1:39 PMSubject: encoding problemHi all,I have a mySQL database with varchar fields containing foreign characters(ex. ë) Queries in the mySQL client yield correct results.When I do a query using the SQLTransfomer or esql the non ASCII charactersare not presented properly. The ë is converted to ëHere's the pipeline:map:match pattern="members/getmemberdata" map:generate type="serverpages" src="test/test2.xsp"/ map:transform type="sql" map:parameter name="use-connection" value="bvar"/ /map:transform map:serialize type="xml"//map:matchAll the serializers have the encodingUTF-8/encoding tag.The XSP file has a ?xml version="1.0" encoding="UTF-8"? header.Isn't UTF-8 the correct encoding for European characters, or is somethingelse wrong?BertUsing Cocoon 2.1 build 5/14/2002, Tomcat 4.0.1, JDK 1.3.1_02This mail is written in 100% recycled electrons.-Please check that your question has not already been answered in theFAQ before posting. http://xml.apache.org/cocoon/faq/index.htmlhttp://xml.apache.org/cocoon/faq/index.htmlTo unsubscribe, e-mail: mailto:[EMAIL PROTECTED][EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED][EMAIL PROTECTED]-Please check that your question has not already been answered in theFAQ before posting. http://xml.apache.org/cocoon/faq/index.htmlTo unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
Re: R: encoding problem
On Fri, 2002-10-25 at 16:33, Bert Van Kets wrote: Of course I checked the mail logs before bugging the list. I could not find a solution though. I did find that I need to use UTF-8 and not iso-8859-1 (the Cocoon default) Searching through the source I found that a LOT of classes and XSLTs set the encoding to iso-8859-1, so I am replacing these to UTF-8 and will recompile afterwards. Lets see what that gives. Bert, I cannot imagine that the above would help, nor would changing the encoding of the serializer. Both UTF-8 and ISO-8859-1 support the characters you're having problems with. My guess is that the problem is either with mysql itself or with the mysql jdbc driver. Maybe your mysql client inserts the data incorrectly in the database? Try using a Java-based mysql (jdbc) client to insert the data into the database (or write a small java-prog). I'm also running mysql over here with cocoon etc (all in linux) and have no problems with special characters. But of course that doesn't help you ;-) Regards. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Encoding problem with HTML-serializer and URLs
Hello, doing the following I do not get the expected results. The german umlaut with ISO-8859-1 converts magically to UTF-8. All encodings (html-/xml-serializers, xml-files, xsl-files) are set to ISO-8859-1 src.xml: html head ... a href=dest?selection=öö/ (ö = german umlaut for oe) ... /html Sitemap snippet: ... map:generate type=file src=src.xml / map:serialize type=html / ... Produced output: ... a href=dest?selection=%C3%B6ouml;/a ... If I click the link I see the same selection-string in the Browser URL. I did expect the destination dest restoring the same character with the same encoding. dest.xml ... dest Selection= /dest ... dest.xsl ... dest xsl:value-of select=dest / xsl:value-of select=$selection / /dest ... the sitemap ends with a xml-serializer Output -- destHi=an A with a tilde on top/dest This funny character is an ö (ouml;) in UTF-8. I did try some proposals like setting encoding in an action (request.setCharacterEncoding). Nothing works for me. Any ideas? I have to send selection-criteria for a database as URL-parameters. Regards Stefan -- Stefan Riegel TELIG GmbH Ziegelstraße 27 D-71063 Sindelfingen GERMANY Phone: +49-7031-79433-30 Fax:+49-7031-79433-43 Mobile: +49-174-4025031 - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem with HTML-serializer and URLs
Try this in your sitemap: map:action name=set-character-encoding src=org.apache.cocoon.acting.SetCharacterEncodingAction/ and map:act type=set-character-encoding map:parameter name=form-encoding value=your-encoding/ /map:act --- Stefan Riegel [EMAIL PROTECTED] wrote: Hello, doing the following I do not get the expected results. The german umlaut with ISO-8859-1 converts magically to UTF-8. All encodings (html-/xml-serializers, xml-files, xsl-files) are set to ISO-8859-1 src.xml: html head ... a href=dest?selection=öö/ (ö = german umlaut for oe) ... /html Sitemap snippet: ... map:generate type=file src=src.xml / map:serialize type=html / ... Produced output: ... a href=dest?selection=%C3%B6ouml;/a ... If I click the link I see the same selection-string in the Browser URL. I did expect the destination dest restoring the same character with the same encoding. dest.xml ... dest Selection= /dest ... dest.xsl ... dest xsl:value-of select=dest / xsl:value-of select=$selection / /dest ... the sitemap ends with a xml-serializer Output -- destHi=an A with a tilde on top/dest This funny character is an ö (ouml;) in UTF-8. I did try some proposals like setting encoding in an action (request.setCharacterEncoding). Nothing works for me. Any ideas? I have to send selection-criteria for a database as URL-parameters. Regards Stefan -- Stefan Riegel TELIG GmbH Ziegelstraße 27 D-71063 Sindelfingen GERMANY Phone: +49-7031-79433-30 Fax:+49-7031-79433-43 Mobile: +49-174-4025031 - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SunShine-InsertTransformer: encoding problem
Hi Alex, I just checked in a fix for the namespace problem - now it works for me - could you please check - if everything is working for you, too. Thanks Carsten -Original Message- From: Alex Romayev [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 1:12 PM To: [EMAIL PROTECTED] Subject: RE: SunShine-InsertTransformer: encoding problem --- Carsten Ziegeler [EMAIL PROTECTED] wrote: Alex Romayev wrote: This is currently hard coded into the transformer(!) which means you can't do anything against it... The InsertTransformer has been merged with the SourceWritingTransformer in 2.1-dev - the SourceWritingTransformer can be configured to what encoding should be used. I did a quick search for ISO-8859-1 in source files and nothing related to InsertTransformer came up. Is there a workaround you could suggest until 2.1 comes out? By the way, is there a rough timeline for this release? It's not directly in the transformer. The transformer uses a component called ResourceConnector and this does the saving. The connector uses org.apache.cocoon.xml.XMLUtils.defaultSerializeToXMLFormat to serialize the XML and there you will find this setting. A rough time line for 2.1 is end of this year, I guess +/- 1 or 2 months... The namespaces in content/news.xml. By the way, I've raised this problem with SourceWriting transformer as well and haven't seen it in the recent bug-list e-mail. I'm just thinking that if the two got merged, the problem might still be there. Can you give a complete test case for this? (Sitemap snippet plus the two xml files) - If you can provide this I will try to find the bug as soon as I have time. Carsten Sure, here is the sitemap: map:match pattern=admin/add-news map:act type=sunShine-session/ map:generate src=resources/sunshine/admin/add-news-item.xml/ map:transform type=sunShine/ map:transform type=sunShineInsert/ map:serialize type=xml/ /map:match And I've attached the two files (slightly simplified). Cheers, -Alex - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SunShine-InsertTransformer: encoding problem
--- Carsten Ziegeler [EMAIL PROTECTED] wrote: Alex Romayev wrote: This is currently hard coded into the transformer(!) which means you can't do anything against it... The InsertTransformer has been merged with the SourceWritingTransformer in 2.1-dev - the SourceWritingTransformer can be configured to what encoding should be used. I did a quick search for ISO-8859-1 in source files and nothing related to InsertTransformer came up. Is there a workaround you could suggest until 2.1 comes out? By the way, is there a rough timeline for this release? It's not directly in the transformer. The transformer uses a component called ResourceConnector and this does the saving. The connector uses org.apache.cocoon.xml.XMLUtils.defaultSerializeToXMLFormat to serialize the XML and there you will find this setting. A rough time line for 2.1 is end of this year, I guess +/- 1 or 2 months... The namespaces in content/news.xml. By the way, I've raised this problem with SourceWriting transformer as well and haven't seen it in the recent bug-list e-mail. I'm just thinking that if the two got merged, the problem might still be there. Can you give a complete test case for this? (Sitemap snippet plus the two xml files) - If you can provide this I will try to find the bug as soon as I have time. Carsten Sure, here is the sitemap: map:match pattern=admin/add-news map:act type=sunShine-session/ map:generate src=resources/sunshine/admin/add-news-item.xml/ map:transform type=sunShine/ map:transform type=sunShineInsert/ map:serialize type=xml/ /map:match And I've attached the two files (slightly simplified). Cheers, -Alex - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ?xml version=1.0 encoding=UTF-8? addnews xmlns:sunshine=http://cocoon.apache.org/sunshine/1.0; xmlns:pub=http://www.romayev.com/publication/1.0; xmlns:i18n=http://apache.org/cocoon/i18n/2.0; sunshine:insert sunshine:filecontent/news.xml/sunshine:file sunshine:path/news/sunshine:path sunshine:fragment item id=test titleHello1/title pub:publication pub:publishedDate2002-12-01/pub:publishedDate /pub:publication /item /sunshine:fragment sunshine:replaceitem[@id='test']/sunshine:replace /sunshine:insert /addnews ?xml version=1.0 encoding=ISO-8859-1? news xmlns:pub=http://www.romayev.com/publication/1.0; item id=N100AE date2001-11-26/date title test /title description test description /description pub:publication pub:publishedDate2001-11-26/pub:publishedDate /pub:publication /item /news - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SunShine-InsertTransformer: encoding problem
Sorry for the re-post, but there have been some mail problems on Friday when I posted it and I haven't heard from anyone since then. I'm still struggling with both problems, so any help would be greatly appreciated. Alex --- Alex Romayev [EMAIL PROTECTED] wrote: Sorry the C is supposed to read as (I'm separating with spaces) # 1 0 5 7 ;, the browser displays it as a letter C. --- Alex Romayev [EMAIL PROTECTED] wrote: Hi, I'm trying my way around SunShine and running into 2 problems: 1) I have an existing XML file with UTF-8 encoding. I use InsertTransformer to add a new record. It does so correctly, but changes the file encoding to ISO-8859-1 and replaces all non-English text with Ñs and alike. 2) I have namespace declarations at the root elemet of the file. After running it through the transformer, the namespace declarations disappear. Here is my sitemap: map:match pattern=admin/add-news map:act type=set-character-encoding map:parameter name=form-encoding value=UTF-8/ /map:act map:act type=sunShine-session/ map:generate src=resources/sunshine/admin/add-news-item.xml/ map:transform type=sunShine/ map:transform type=sunShineInsert/ map:serialize type=xml/ /map:match And add-news-item.xml: ?xml version=1.0 encoding=UTF-8? addnews xmlns:sunshine=http://cocoon.apache.org/sunshine/1.0; sunshine:insert sunshine:filecontent/news.xml/sunshine:file sunshine:path/news/sunshine:path sunshine:fragment item id=test titleHello1/title /item /sunshine:fragment sunshine:replaceitem[@id='test']/sunshine:replace /sunshine:insert /addnews Any ideas on what I'm doing wrong? Thanks, -Alex - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SunShine-InsertTransformer: encoding problem
Alex Romayev wrote: Hi, I'm trying my way around SunShine and running into 2 problems: 1) I have an existing XML file with UTF-8 encoding. I use InsertTransformer to add a new record. It does so correctly, but changes the file encoding to ISO-8859-1 and replaces all non-English text with Qs and alike. This is currently hard coded into the transformer(!) which means you can't do anything against it... The InsertTransformer has been merged with the SourceWritingTransformer in 2.1-dev - the SourceWritingTransformer can be configured to what encoding should be used. 2) I have namespace declarations at the root elemet of the file. After running it through the transformer, the namespace declarations disappear. ... And add-news-item.xml: ?xml version=1.0 encoding=UTF-8? addnews xmlns:sunshine=http://cocoon.apache.org/sunshine/1.0; sunshine:insert sunshine:filecontent/news.xml/sunshine:file sunshine:path/news/sunshine:path sunshine:fragment item id=test titleHello1/title /item /sunshine:fragment sunshine:replaceitem[@id='test']/sunshine:replace /sunshine:insert /addnews Any ideas on what I'm doing wrong? Which namespace information do you mean? The sunshine namespace in your add-news-item.xml or a namespace contained in your content/news.xml? Carsten - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SunShine-InsertTransformer: encoding problem
--- Carsten Ziegeler [EMAIL PROTECTED] wrote: Alex Romayev wrote: Hi, I'm trying my way around SunShine and running into 2 problems: 1) I have an existing XML file with UTF-8 encoding. I use InsertTransformer to add a new record. It does so correctly, but changes the file encoding to ISO-8859-1 and replaces all non-English text with Qs and alike. This is currently hard coded into the transformer(!) which means you can't do anything against it... The InsertTransformer has been merged with the SourceWritingTransformer in 2.1-dev - the SourceWritingTransformer can be configured to what encoding should be used. I did a quick search for ISO-8859-1 in source files and nothing related to InsertTransformer came up. Is there a workaround you could suggest until 2.1 comes out? By the way, is there a rough timeline for this release? 2) I have namespace declarations at the root elemet of the file. After running it through the transformer, the namespace declarations disappear. ... And add-news-item.xml: ?xml version=1.0 encoding=UTF-8? addnews xmlns:sunshine=http://cocoon.apache.org/sunshine/1.0; sunshine:insert sunshine:filecontent/news.xml/sunshine:file sunshine:path/news/sunshine:path sunshine:fragment item id=test titleHello1/title /item /sunshine:fragment sunshine:replaceitem[@id='test']/sunshine:replace /sunshine:insert /addnews Any ideas on what I'm doing wrong? Which namespace information do you mean? The sunshine namespace in your add-news-item.xml or a namespace contained in your content/news.xml? The namespaces in content/news.xml. By the way, I've raised this problem with SourceWriting transformer as well and haven't seen it in the recent bug-list e-mail. I'm just thinking that if the two got merged, the problem might still be there. Similar question, would you suggest any workaround before 2.1 release comes out? Thanks for you help Carsten, -Alex Carsten - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SunShine-InsertTransformer: encoding problem
Alex Romayev wrote: This is currently hard coded into the transformer(!) which means you can't do anything against it... The InsertTransformer has been merged with the SourceWritingTransformer in 2.1-dev - the SourceWritingTransformer can be configured to what encoding should be used. I did a quick search for ISO-8859-1 in source files and nothing related to InsertTransformer came up. Is there a workaround you could suggest until 2.1 comes out? By the way, is there a rough timeline for this release? It's not directly in the transformer. The transformer uses a component called ResourceConnector and this does the saving. The connector uses org.apache.cocoon.xml.XMLUtils.defaultSerializeToXMLFormat to serialize the XML and there you will find this setting. A rough time line for 2.1 is end of this year, I guess +/- 1 or 2 months... The namespaces in content/news.xml. By the way, I've raised this problem with SourceWriting transformer as well and haven't seen it in the recent bug-list e-mail. I'm just thinking that if the two got merged, the problem might still be there. Can you give a complete test case for this? (Sitemap snippet plus the two xml files) - If you can provide this I will try to find the bug as soon as I have time. Carsten - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SunShine-InsertTransformer: encoding problem
Hi, I'm trying my way around SunShine and running into 2 problems: 1) I have an existing XML file with UTF-8 encoding. I use InsertTransformer to add a new record. It does so correctly, but changes the file encoding to ISO-8859-1 and replaces all non-English text with #1057;s and alike. 2) I have namespace declarations at the root elemet of the file. After running it through the transformer, the namespace declarations disappear. Here is my sitemap: map:match pattern=admin/add-news map:act type=set-character-encoding map:parameter name=form-encoding value=UTF-8/ /map:act map:act type=sunShine-session/ map:generate src=resources/sunshine/admin/add-news-item.xml/ map:transform type=sunShine/ map:transform type=sunShineInsert/ map:serialize type=xml/ /map:match And add-news-item.xml: ?xml version=1.0 encoding=UTF-8? addnews xmlns:sunshine=http://cocoon.apache.org/sunshine/1.0; sunshine:insert sunshine:filecontent/news.xml/sunshine:file sunshine:path/news/sunshine:path sunshine:fragment item id=test titleHello1/title /item /sunshine:fragment sunshine:replaceitem[@id='test']/sunshine:replace /sunshine:insert /addnews Any ideas on what I'm doing wrong? Thanks, -Alex - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SunShine-InsertTransformer: encoding problem
Sorry the C is supposed to read as (I'm separating with spaces) # 1 0 5 7 ;, the browser displays it as a letter C. --- Alex Romayev [EMAIL PROTECTED] wrote: Hi, I'm trying my way around SunShine and running into 2 problems: 1) I have an existing XML file with UTF-8 encoding. I use InsertTransformer to add a new record. It does so correctly, but changes the file encoding to ISO-8859-1 and replaces all non-English text with Ñs and alike. 2) I have namespace declarations at the root elemet of the file. After running it through the transformer, the namespace declarations disappear. Here is my sitemap: map:match pattern=admin/add-news map:act type=set-character-encoding map:parameter name=form-encoding value=UTF-8/ /map:act map:act type=sunShine-session/ map:generate src=resources/sunshine/admin/add-news-item.xml/ map:transform type=sunShine/ map:transform type=sunShineInsert/ map:serialize type=xml/ /map:match And add-news-item.xml: ?xml version=1.0 encoding=UTF-8? addnews xmlns:sunshine=http://cocoon.apache.org/sunshine/1.0; sunshine:insert sunshine:filecontent/news.xml/sunshine:file sunshine:path/news/sunshine:path sunshine:fragment item id=test titleHello1/title /item /sunshine:fragment sunshine:replaceitem[@id='test']/sunshine:replace /sunshine:insert /addnews Any ideas on what I'm doing wrong? Thanks, -Alex - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
Let me be more specific and also simplify the example:
Works:
xsl:param name=city select='Delhi'/
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a href=city-detail=DelhiDelhi/a
Does not work:
xsl:param name=city select='Äåëè'/
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a
href=city-detail=%D0%94%D0%B5%D0%BB%D0%B8Äåëè/a
--- Alex Romayev [EMAIL PROTECTED] wrote:
Hello,
I'm having what seems to be an encoding problem --
not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already
been answered in the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
maybe :
a href=city-detail={$city}xsl:value-of
select=$city//a
try to use Russian-compatible output encoding rather than utf-8 ?
- Original Message -
From: Alex Romayev [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 12:53 PM
Subject: Re: Encoding problem
Let me be more specific and also simplify the example:
Works:
xsl:param name=city select='Delhi'/
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a href=city-detail=DelhiDelhi/a
Does not work:
xsl:param name=city select='Äåëè'/
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a
href=city-detail=%D0%94%D0%B5%D0%BB%D0%B8Äåëè/a
--- Alex Romayev [EMAIL PROTECTED] wrote:
Hello,
I'm having what seems to be an encoding problem --
not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already
been answered in the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
--- Barbara Post [EMAIL PROTECTED] wrote:
maybe :
a href=city-detail={$city}xsl:value-of
select=$city//a
Sorry, just a typo in my e-mail, I did actually use
{$city}.
try to use Russian-compatible output encoding rather
than utf-8 ?
The site is multi-lingual, so I have to use utf-8
- Original Message -
From: Alex Romayev [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 12:53 PM
Subject: Re: Encoding problem
Let me be more specific and also simplify the
example:
Works:
xsl:param name=city select='Delhi'/
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a href=city-detail=DelhiDelhi/a
Does not work:
xsl:param name=city select='Äåëè'/
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a
href=city-detail=%D0%94%D0%B5%D0%BB%D0%B8Äåëè/a
--- Alex Romayev [EMAIL PROTECTED] wrote:
Hello,
I'm having what seems to be an encoding problem
--
not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a
href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not
in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already
been answered in the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check that your question has not already
been answered in the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check that your question has not already
been answered in the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
Alex Romayev wrote:
Let me be more specific and also simplify the example:
...
Does not work:
xsl:param name=city select='Äåëè'/
Are these funny characters above in UTF-8? Does your XSL has
encoding=UTF-8 on the top?
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a
href=city-detail=%D0%94%D0%B5%D0%BB%D0%B8Äåëè/a
What's serializer configuration? Does it have proper encoding set?
Vadim
--- Alex Romayev [EMAIL PROTECTED] wrote:
Hello,
I'm having what seems to be an encoding problem --
not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
--- Vadim Gritsenko [EMAIL PROTECTED]
wrote:
Alex Romayev wrote:
Let me be more specific and also simplify the
example:
...
Does not work:
xsl:param name=city select='Äåëè'/
Are these funny characters above in UTF-8? Does your
XSL has
encoding=UTF-8 on the top?
Yes. Also, note that this only happens to the href
attribute, the value of the a element comes out
correctly.
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a
href=city-detail=%D0%94%D0%B5%D0%BB%D0%B8Äåëè/a
What's serializer configuration? Does it have proper
encoding set?
I'm using the default, i.e., I haven't changed
anything since installation.
Vadim
--- Alex Romayev [EMAIL PROTECTED] wrote:
Hello,
I'm having what seems to be an encoding problem --
not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not
in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already
been answered in the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
Alex Romayev wrote:
--- Vadim Gritsenko [EMAIL PROTECTED]
wrote:
Alex Romayev wrote:
Let me be more specific and also simplify the
example:
...
Does not work:
xsl:param name=city select='Äåëè'/
Are these funny characters above in UTF-8? Does your
XSL has
encoding=UTF-8 on the top?
Yes. Also, note that this only happens to the href
attribute, the value of the a element comes out
correctly.
Then what do you want? It works correctly. See
http://www.w3.org/Addressing/rfc1738.txt
Vadim
...
a href=city-detail=$cityxsl:value-of
select=$city//a
After transformation I get:
a
href=city-detail=%D0%94%D0%B5%D0%BB%D0%B8Äåëè/a
What's serializer configuration? Does it have proper
encoding set?
I'm using the default, i.e., I haven't changed
anything since installation.
Vadim
--- Alex Romayev [EMAIL PROTECTED] wrote:
Hello,
I'm having what seems to be an encoding problem --
not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not
in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
--- Vadim Gritsenko [EMAIL PROTECTED]
wrote:
Alex Romayev wrote:
--- Vadim Gritsenko [EMAIL PROTECTED]
wrote:
Alex Romayev wrote:
Let me be more specific and also simplify the
example:
...
Does not work:
xsl:param name=city select='Äåëè'/
Are these funny characters above in UTF-8? Does
your
XSL has
encoding=UTF-8 on the top?
Yes. Also, note that this only happens to the href
attribute, the value of the a element comes out
correctly.
Then what do you want? It works correctly. See
http://www.w3.org/Addressing/rfc1738.txt
Vadim
Good point, I may have a problem in another stylesheet
(part of the pipeline that responds to the url in
question):
This parameter is set by the href:
xsl:param name=city/
This should match and does it correctly when 'Delhi'
is passed, but does not match when I pass 'Äåëè':
xsl:apply-templates select=//city[name=$city]/
-Alex
...
a href=city-detail?city=$cityxsl:value-of
select=$city//a
After transformation I get:
a
href=city-detail?city=%D0%94%D0%B5%D0%BB%D0%B8Äåëè/a
What's serializer configuration? Does it have
proper
encoding set?
I'm using the default, i.e., I haven't changed
anything since installation.
Vadim
--- Alex Romayev [EMAIL PROTECTED] wrote:
Hello,
I'm having what seems to be an encoding problem
--
not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a
href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not
in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already
been answered in the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
Alex Romayev wrote: --- Vadim Gritsenko [EMAIL PROTECTED] wrote: Alex Romayev wrote: --- Vadim Gritsenko [EMAIL PROTECTED] wrote: ... Good point, I may have a problem in another stylesheet (part of the pipeline that responds to the url in question): This parameter is set by the href: xsl:param name=city/ This should match and does it correctly when 'Delhi' is passed, but does not match when I pass 'Äåëè': xsl:apply-templates select=//city[name=$city]/ Check what encoding is used to decode URL. It should be container encoding, but you need UTF-8. I'm using tomcat4.0.4, do you know how to change it of the top of your head? I've not played with encoding of the URL itself, but about request parameters see below... PS In any case, non US-ASCII symbols in URL is not a good idea. What would be an alternative? Basically, I need to search agains an XML file, which has city as one of the elements, and return all records related to the sity. On the page, there is a list of 'favourite city' links. Also, I'm about to try recording information using Cocoon, so I haven't tried to use forms yet, but wouldn't I run into the same problem? Ok, UTF symbols should be fine in the forms (GET or POST) if you to: (1) Serialize HTML form as UTF-8 (or any other encoding), and (2) set request encoding: request.setEncoding(UTF-8) (or any other encoding, same as in (1)) *before* any access to the request parameters. This can be done from an action. After that, request.getParameter() should work Ok, and if you to get request parameter in the sitemap and pass it to the XSLT, it also should work ok. BTW, this was already answered today. Vadim Vadim -Alex ... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem
--- Vadim Gritsenko [EMAIL PROTECTED] wrote: Alex Romayev wrote: --- Vadim Gritsenko [EMAIL PROTECTED] wrote: Alex Romayev wrote: --- Vadim Gritsenko [EMAIL PROTECTED] wrote: ... Good point, I may have a problem in another stylesheet (part of the pipeline that responds to the url in question): This parameter is set by the href: xsl:param name=city/ This should match and does it correctly when 'Delhi' is passed, but does not match when I pass 'Äåëè': xsl:apply-templates select=//city[name=$city]/ Check what encoding is used to decode URL. It should be container encoding, but you need UTF-8. I'm using tomcat4.0.4, do you know how to change it of the top of your head? I've not played with encoding of the URL itself, but about request parameters see below... PS In any case, non US-ASCII symbols in URL is not a good idea. What would be an alternative? Basically, I need to search agains an XML file, which has city as one of the elements, and return all records related to the sity. On the page, there is a list of 'favourite city' links. Also, I'm about to try recording information using Cocoon, so I haven't tried to use forms yet, but wouldn't I run into the same problem? Ok, UTF symbols should be fine in the forms (GET or POST) if you to: (1) Serialize HTML form as UTF-8 (or any other encoding), and (2) set request encoding: request.setEncoding(UTF-8) (or any other encoding, same as in (1)) *before* any access to the request parameters. This can be done from an action. Thanks, I'll try that. After that, request.getParameter() should work Ok, and if you to get request parameter in the sitemap and pass it to the XSLT, it also should work ok. BTW, this was already answered today. Sorry, I should have caught it;) Thanks for your help... Vadim Vadim -Alex ... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Encoding problem
Hello,
I'm having what seems to be an encoding problem -- not
sure it's related to Cocoon, but... ;)
xsl:for-each select=//city-name
a href=city-detail?city-name={.}xsl:value-of
select=.//abr/
/xsl:for-each
All my xml is UTF-8, it work in English, but not in
Russian. Any ideas?
Thanks,
-Alex
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
Hello Thorsten,
there was a bug in Xalan with URL encoding more than a half year ago, but I
don't know what's the current status.
xsl:template match='c[@color=blue]'
xsl:element name=a
xsl:attribute name=href
frameset.xsp?filename=xsl:value-of
select=@sourcefile/amp;searchstring=xsl:value-of
disable-output-escaping=yes select=./
/xsl:attribute
xsl:value-of select=./
/xsl:element
/xsl:template
xsl:stylesheet
You can remove disable-output-escaping, because it has no effect in Cocoon
and should not been used generally, because it's an optional function in XSLT.
Furthermore you can rewrite your code as
a href=frameset.xsp?filename={@sourcefile}amp;searchstring={.}
xsl:value-of select=./
/a
It's maybe more readable.
output:
a href=frameset.xsp?filename=foo.xmlsearchstring=Integrations%C3%A4mter
Integrationsauml;mter
/a .
It looks not really bad to me. I don't know exactly to which %XX the a
umlaut should be transformed correctly and whether to one %XX or two, but it
looks not wrong.
desired output:
a href=frameset.xsp?filename=foo.xmlsearchstring=Integrationsauml;mter
Integrationsauml;mter
/a .
This is definitely not correct. You can't use a entity in URL.
- using the disable-output-escaping attribute in the xsl: value-of ...
element - no success
deactivated in Cocoon
-setting the encoding in the xsl:output ... element - no success
deactivated in Cocoon, you do this in the sitemap as you did it correctly
-setting the encoding in the sitemap map:transformer ... - no success
Definitely not at map:transformer, but map:serializer. What I don't know
is, whether it works at the pipe or only at map:serializer in map:components
-spelling the string 'iso-8859-1' in uppercase and lowerscase letters
makes no difference, at least with Xalan.
Is there any possibility generating the desired output using the current
version of cocoon?
Thanks in advance,
Thorsten
Regards,
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: encoding problem with xslt
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]] desired output: a href=frameset.xsp?filename=foo.xmlsearchstring=Integrations auml;mter Integrationsauml;mter /a . This is definitely not correct. You can't use a entity in URL. Of course you can, although that should be (replacing the '' with amp;) a href=frameset.xsp?filename=foo.xmlamp;searchstring=Integrationsauml;m ter Integrationsauml;mter /a Cheers, Manos - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
Manos Batsis wrote: From: Joerg Heinicke [mailto:[EMAIL PROTECTED]] desired output: a href=frameset.xsp?filename=foo.xmlsearchstring=Integrations auml;mter Integrationsauml;mter /a . This is definitely not correct. You can't use a entity in URL. Of course you can, although that should be (replacing the '' with amp;) a href=frameset.xsp?filename=foo.xmlamp;searchstring=Integrationsauml;m ter Integrationsauml;mter /a Still no. Of course you can write this in your XML input, but in the serialized output a valid URL has to be written. And auml; is not valid, the is reserved for concatenating request parameters. If this is working in some browsers, then they have some intelligence to fix developer errors. A XSLT processor should not output such errors. Regards, Joerg Cheers, Manos -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: encoding problem with xslt
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]] Still no. Of course you can write this in your XML input, but in the serialized output a valid URL has to be written. And auml; is not valid, the is reserved for concatenating request parameters. My apologies, I should have read the message more carefully. The transformation output will of course contain the expanded entities. I had the same problem once; the solution was to check attribute values for the entity substring (using an applet, the transformation was on the client side) and replace it with my own entity, something like _%foo; then add yet another step after the transformation to replace that with the normal entity. Not nice but it worked... Cheers, Manos - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
If anyone has some more ideas on this topic (non-ISO-8859-1 characters within URIs), I would greatly appreciate some more input. Conclusion for me is to avoid such characters in URIs. But this does not get easily into the heads of our customers and users. (e.g. file names) According to the old Xalan bug, we used forms with javascript. But this doesn't solve the problem generally, only our special use case. Joerg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
- Original Message - From: Vadim Gritsenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 12, 2002 4:36 PM Subject: RE: encoding problem with xslt From: Jens Lorenz [mailto:[EMAIL PROTECTED]] ... If anyone has some more ideas on this topic (non-ISO-8859-1 characters within URIs), I would greatly appreciate some more input. IMHO, non-ascii characters in URIs should be avoided by all means possible. Less issues for you *and* for visitors of your site. Issues with non-ascii characters in URIs are endless (I bet you have not thought about visitors of your site exchanging bookmarks/URIs, and their systems have different encodings) Vadim Thanks for you input Vadim. But do not only think of web sites. But also of web applications. Think of a web cms for maintaining html content. Avoiding non-ISO characters ist impossible for non-english web sites. Fortunately POST method is immune to such issues. So the only option is to carry these characters via POST back to Cocoon. Jens -- jens.lorenz at interface-projects dot de interface:projects GmbH \\|// Tolkewitzer Strasse 49 (o o) 01277 Dresden oOOo~(_)~oOOo Germany - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
- Original Message - From: Joerg Heinicke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 12, 2002 4:45 PM Subject: Re: encoding problem with xslt If anyone has some more ideas on this topic (non-ISO-8859-1 characters within URIs), I would greatly appreciate some more input. Conclusion for me is to avoid such characters in URIs. But this does not get easily into the heads of our customers and users. (e.g. file names) According to the old Xalan bug, we used forms with javascript. But this doesn't solve the problem generally, only our special use case. Joerg Joerg, which Xalan bug are you referring to ? I browsed the list of open bugs, but only found related bugs. IMHO this is not a bug, but a lack of specification. W3C has a draft about an IRI (internationalized URI), but until this gets adopted and implemented we'll have to deal with the mess. Jens -- jens.lorenz at interface-projects dot de interface:projects GmbH \\|// Tolkewitzer Strasse 49 (o o) 01277 Dresden oOOo~(_)~oOOo Germany - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: encoding problem with xslt
From: Jens Lorenz [mailto:[EMAIL PROTECTED]] - Original Message - From: Vadim Gritsenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 12, 2002 4:36 PM Subject: RE: encoding problem with xslt From: Jens Lorenz [mailto:[EMAIL PROTECTED]] ... If anyone has some more ideas on this topic (non-ISO-8859-1 characters within URIs), I would greatly appreciate some more input. IMHO, non-ascii characters in URIs should be avoided by all means possible. Less issues for you *and* for visitors of your site. Issues with non-ascii characters in URIs are endless (I bet you have not thought about visitors of your site exchanging bookmarks/URIs, and their systems have different encodings) Vadim Thanks for you input Vadim. But do not only think of web sites. But also of web applications. Think of a web cms for maintaining html content. Avoiding non-ISO characters ist ^^^ :) impossible for non-english web sites. Fortunately POST method is immune to such issues. So the only option is to carry these characters via POST back to Cocoon. It is also the safest way and compatible among all browsers/platforms (if platform supports this encoding, of course). Take care, Vadim Jens -- jens.lorenz at interface-projects dot de interface:projects GmbH \\|// Tolkewitzer Strasse 49 (o o) 01277 Dresden oOOo~(_)~oOOo Germany - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
Hmm, I didn't test it a long time and didn't find a correlating bug by a short view on Xalan bug list. It was a bug in our application that mü was transformed to mü. (For people with different encoding: u umlaut == A+~ and 1/4.) I had in mind (and written in our bugzilla) that it was a Xalan bug, maybe that's wrong. It sounds a bit like the description of the original post on this thread. At least we solved it with POST form. Joerg Jens Lorenz wrote: - Original Message - From: Joerg Heinicke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 12, 2002 4:45 PM Subject: Re: encoding problem with xslt If anyone has some more ideas on this topic (non-ISO-8859-1 characters within URIs), I would greatly appreciate some more input. Conclusion for me is to avoid such characters in URIs. But this does not get easily into the heads of our customers and users. (e.g. file names) According to the old Xalan bug, we used forms with javascript. But this doesn't solve the problem generally, only our special use case. Joerg Joerg, which Xalan bug are you referring to ? I browsed the list of open bugs, but only found related bugs. IMHO this is not a bug, but a lack of specification. W3C has a draft about an IRI (internationalized URI), but until this gets adopted and implemented we'll have to deal with the mess. Jens -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
- Original Message - From: Vadim Gritsenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 12, 2002 5:05 PM Subject: RE: encoding problem with xslt snip/ Thanks for you input Vadim. But do not only think of web sites. But also of web applications. Think of a web cms for maintaining html content. Avoiding non-ISO characters ist ^^^ :) Ooops. This happens when somebody near you forces you to think in two languages at once (one written, one spoken) ... sorry. But now you know the german equivalent for is (if you didn't know yet). impossible for non-english web sites. Fortunately POST method is immune to such issues. So the only option is to carry these characters via POST back to Cocoon. It is also the safest way and compatible among all browsers/platforms (if platform supports this encoding, of course). Take care, Vadim Jens -- jens.lorenz at interface-projects dot de interface:projects GmbH \\|// Tolkewitzer Strasse 49 (o o) 01277 Dresden oOOo~(_)~oOOo Germany - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encoding problem with xslt
- Original Message - From: Joerg Heinicke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 12, 2002 5:23 PM Subject: Re: encoding problem with xslt Hmm, I didn't test it a long time and didn't find a correlating bug by a short view on Xalan bug list. It was a bug in our application that mü was transformed to mü. (For people with different encoding: u umlaut == A+~ and 1/4.) I had in mind (and written in our bugzilla) that it was a Xalan bug, maybe that's wrong. It sounds a bit like the description of the original post on this thread. At least we solved it with POST form. Joerg Thank you very much Joerg. This smells a lot like UTF-8 encoding. java String s = new String(mü); byte[] data = s.getBytes(ISO-8859-1); String decoded = new String(data,UTF-8); System.out.println(decoded); /java gives mü. So Xalan encoded your string UTF-8. This is the recommend encoding for URIs (see RFC 2718). So this is no bug of Xalan. And this leads to the real problem. URL being encoding UTF-8 and servlet container encoding being ISO-8859-1. Solution: ? Jens -- jens.lorenz at interface-projects dot de interface:projects GmbH \\|// Tolkewitzer Strasse 49 (o o) 01277 Dresden oOOo~(_)~oOOo Germany - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
encoding problem
Hi all, I have a small encoding problem in cocoon 2.0.2. I have a utf-8 encoded text that is transformed to html with an xsl stylesheet. After the processing the unicode characters aren't displayed properly. When I looked at the page source my characters were hardcoded in html entities like Aumlaut; when it should have been an a with a macron. When I processed the xml source and the stylesheet by xalan it worked fine. Furthermore some of the unicode characters in hyperlinks are displayed properly in the status bar at the bottom of my browser but aren't in the main browser window. This led me to conclude that the problem most be somewhere internally in cocoon. When I looked through the log files I couldn't find any noticable exceptions. Could somebody please help me out? I have a sdk 1.3.1 on a SuSE linux 8.0 box and cocoon 2.0.2 is running on tomcat 4.0.1 regards sjoerd - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/cocoon encoding problem
Hi Michael, Did you set the proper encoding for used cocoon's components (generator, transformer and so on)? I imagine that serializer has it because you wrote that the result XML encoding is ok. What about other components? Roman Michael Mangeng wrote: That didn´t do it ;-( *searching* thanx anywaymike - Original Message - From: Jan Uyttenhove To: [EMAIL PROTECTED] Sent: Friday, June 07, 2002 5:30 PM Subject: RE: Tomcat/cocoon encoding problem Try to start the jvm (tomcat startup) with property -Dfile.encoding=ISO8859_1Maybe you should choose another encoding, I used ISO8859_1 to solve a similar problem with french characters.Hope this helps.Greetz,Janvisit us @ http://www.xume.be -Original Message- From: Michael Mangeng [mailto:[EMAIL PROTECTED]] Sent: vrijdag 7 juni 2002 16:47 To: [EMAIL PROTECTED] Subject: Tomcat/cocoon encoding problem Hi I´ve set the encoding of both the xsp and the xml serializer correctly. After i request the xml i get the right encoding - ISO-8859-1 in the ?xml ... ? tag but german umlaut´s like äöü are replaced by '?'. I´ve noticed the same problem when i use beans on my JSP Pages (without cocoon; only tomcat)(Using äöü on a jsp works - but as soon as i set the data in a bean and then request it back - i have äöü instead of the umlauts in my string). I´m using linux 2.4.17, jdk1.3.1, tomcat 4.1.2alpha and cocoon2.0.2. So... Is there a anywhere a setting for the jvm, tomcat or cocoon that the umlauts are correctly displayed ? greetingsmike - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/cocoon encoding problem
Hi thanx for your help but i´ve already solved the problem with the help of Jan Uyttenhove. My locale settings on the linux box had to be changed too. I´ve written this points together: (hope they help if sombody get the same probs): -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- How to use german umlauts on english *nix systems: Set *nix locale to de_AT (or de_DE): localedef -c -i de_AT -f ISO-8859-1 de_AT Set LANG (system environment var) to de_AT (or de_DE) export LANG='de_AT' Before starting Tomcat set: $CATALINA_OPTS to '-Dfile.encoding=ISO8859_1' sitemap.xmap: Use encodingISO-8859-1/encoding in the according (e.g. html) map:serializer tag. XML/XSP: Use: ?xml version=1.0 encoding=ISO-8859-1? -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- greetings mike - Original Message - From: KOZLOV Roman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 10, 2002 9:17 AM Subject: Re: Tomcat/cocoon encoding problem Hi Michael, Did you set the proper encoding for used cocoon's components (generator, transformer and so on)? I imagine that serializer has it because you wrote that the result XML encoding is ok. What about other components? Roman Michael Mangeng wrote: That didn´t do it ;-( *searching* thanx anywaymike - Original Message - From: Jan Uyttenhove To: [EMAIL PROTECTED] Sent: Friday, June 07, 2002 5:30 PM Subject: RE: Tomcat/cocoon encoding problem Try to start the jvm (tomcat startup) with property -Dfile.encoding=ISO8859_1Maybe you should choose another encoding, I used ISO8859_1 to solve a similar problem with french characters.Hope this helps.Greetz,Janvisit us @ http://www.xume.be -Original Message- From: Michael Mangeng [mailto:[EMAIL PROTECTED]] Sent: vrijdag 7 juni 2002 16:47 To: [EMAIL PROTECTED] Subject: Tomcat/cocoon encoding problem Hi I´ve set the encoding of both the xsp and the xml serializer correctly. After i request the xml i get the right encoding - ISO-8859-1 in the ?xml ... ? tag but german umlaut´s like äöü are replaced by '?'. I´ve noticed the same problem when i use beans on my JSP Pages (without cocoon; only tomcat)(Using äöü on a jsp works - but as soon as i set the data in a bean and then request it back - i have äöü instead of the umlauts in my string). I´m using linux 2.4.17, jdk1.3.1, tomcat 4.1.2alpha and cocoon2.0.2. So... Is there a anywhere a setting for the jvm, tomcat or cocoon that the umlauts are correctly displayed ? greetingsmike - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/cocoon encoding problem
There is another solution (when using Tomcat) which is independent of a system locale - to use default (UTF-8) encoding for cocoon's components and in client's browser. The main problem which I've faced implementing the UTF-8 solution is decoding request parameters. However it is easy to fix it just using Tomcat's filters (see CATALINA_HOME\webapps\examples\WEB-INF\classes\filters\SetCharacterEncodingFilter.*). Roman Michael Mangeng wrote: Hi thanx for your help but i´ve already solved the problem with the help of Jan Uyttenhove. My locale settings on the linux box had to be changed too. I´ve written this points together: (hope they help if sombody get the same probs): -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- How to use german umlauts on english *nix systems: Set *nix locale to de_AT (or de_DE): localedef -c -i de_AT -f ISO-8859-1 de_AT Set LANG (system environment var) to de_AT (or de_DE) export LANG='de_AT' Before starting Tomcat set: $CATALINA_OPTS to '-Dfile.encoding=ISO8859_1' sitemap.xmap: Use encodingISO-8859-1/encoding in the according (e.g. html) map:serializer tag. XML/XSP: Use: ?xml version=1.0 encoding=ISO-8859-1? -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- greetings mike - Original Message - From: KOZLOV Roman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 10, 2002 9:17 AM Subject: Re: Tomcat/cocoon encoding problem Hi Michael, Did you set the proper encoding for used cocoon's components (generator, transformer and so on)? I imagine that serializer has it because you wrote that the result XML encoding is ok. What about other components? Roman Michael Mangeng wrote: That didn´t do it ;-( *searching* thanx anywaymike - Original Message - From: Jan Uyttenhove To: [EMAIL PROTECTED] Sent: Friday, June 07, 2002 5:30 PM Subject: RE: Tomcat/cocoon encoding problem Try to start the jvm (tomcat startup) with property -Dfile.encoding=ISO8859_1Maybe you should choose another encoding, I used ISO8859_1 to solve a similar problem with french characters.Hope this helps.Greetz,Janvisit us @ http://www.xume.be -Original Message- From: Michael Mangeng [mailto:[EMAIL PROTECTED]] Sent: vrijdag 7 juni 2002 16:47 To: [EMAIL PROTECTED] Subject: Tomcat/cocoon encoding problem Hi I´ve set the encoding of both the xsp and the xml serializer correctly. After i request the xml i get the right encoding - ISO-8859-1 in the ?xml ... ? tag but german umlaut´s like äöü are replaced by '?'. I´ve noticed the same problem when i use beans on my JSP Pages (without cocoon; only tomcat)(Using äöü on a jsp works - but as soon as i set the data in a bean and then request it back - i have äöü instead of the umlauts in my string). I´m using linux 2.4.17, jdk1.3.1, tomcat 4.1.2alpha and cocoon2.0.2. So... Is there a anywhere a setting for the jvm, tomcat or cocoon that the umlauts are correctly displayed ? greetingsmike - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/cocoon encoding problem
From: Michael Mangeng [mailto:[EMAIL PROTECTED]] Hi thanx for your help but i´ve already solved the problem with the help of Jan Uyttenhove. My locale settings on the linux box had to be changed too. I´ve written this points together: (hope they help if sombody get the same probs): As of Cocoon 2.0.3 (which has some XSP fixes) it should work like this: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- How to use german umlauts on english *nix systems: sitemap.xmap: Use encodingISO-8859-1/encoding in the according (e.g. html) map:serializer tag. XML/XSP: Use: ?xml version=1.0 encoding=ISO-8859-1? -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- If you have time, try it. Regards, Vadim greetings mike - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/cocoon encoding problem
Try to start the jvm (tomcat startup) with property -Dfile.encoding=ISO8859_1 Maybe you should choose another encoding, I used ISO8859_1 to solve a similar problem with french characters. Hope this helps. Greetz, Jan visit us @ http://www.xume.be -Original Message-From: Michael Mangeng [mailto:[EMAIL PROTECTED]]Sent: vrijdag 7 juni 2002 16:47To: [EMAIL PROTECTED]Subject: Tomcat/cocoon encoding problem Hi I´ve set the encoding of both the xsp and the xml serializer correctly. Afteri requestthe xml i get the right encoding - ISO-8859-1 in the ?xml ... ? tag but german umlaut´s like äöü are replacedby '?'. I´ve noticed the same problem when i use beans on my JSP Pages (without cocoon; only tomcat) (Using äöü on a jsp works - but as soon as i set the data in a bean and then request it back - i have äöü instead of the umlauts in my string). I´m using linux 2.4.17, jdk1.3.1, tomcat 4.1.2alpha and cocoon2.0.2. So... Is there a anywhere a setting for the jvm, tomcat or cocoonthatthe umlauts arecorrectly displayed ? greetings mike
Re: Tomcat/cocoon encoding problem
That didn´t do it ;-( *searching* thanx anyway mike - Original Message - From: Jan Uyttenhove To: [EMAIL PROTECTED] Sent: Friday, June 07, 2002 5:30 PM Subject: RE: Tomcat/cocoon encoding problem Try to start the jvm (tomcat startup) with property -Dfile.encoding=ISO8859_1 Maybe you should choose another encoding, I used ISO8859_1 to solve a similar problem with french characters. Hope this helps. Greetz, Jan visit us @ http://www.xume.be -Original Message-From: Michael Mangeng [mailto:[EMAIL PROTECTED]]Sent: vrijdag 7 juni 2002 16:47To: [EMAIL PROTECTED]Subject: Tomcat/cocoon encoding problem Hi I´ve set the encoding of both the xsp and the xml serializer correctly. Afteri requestthe xml i get the right encoding - ISO-8859-1 in the ?xml ... ? tag but german umlaut´s like äöü are replacedby '?'. I´ve noticed the same problem when i use beans on my JSP Pages (without cocoon; only tomcat) (Using äöü on a jsp works - but as soon as i set the data in a bean and then request it back - i have äöü instead of the umlauts in my string). I´m using linux 2.4.17, jdk1.3.1, tomcat 4.1.2alpha and cocoon2.0.2. So... Is there a anywhere a setting for the jvm, tomcat or cocoonthatthe umlauts arecorrectly displayed ? greetings mike
Tomcat/cocoon encoding problem
Hi I´ve set the encoding of both the xsp and the xml serializer correctly. Afteri requestthe xml i get the right encoding - ISO-8859-1 in the ?xml ... ? tag but german umlaut´s like äöü are replacedby '?'. I´ve noticed the same problem when i use beans on my JSP Pages (without cocoon; only tomcat) (Using äöü on a jsp works - but as soon as i set the data in a bean and then request it back - i have äöü instead of the umlauts in my string). I´m using linux 2.4.17, jdk1.3.1, tomcat 4.1.2alpha and cocoon2.0.2. So... Is there a anywhere a setting for the jvm, tomcat or cocoonthatthe umlauts arecorrectly displayed ? greetings mike
JSPGenerator encoding problem
Hi all! My JSPGenerator or jasper-compiler don't supported KOI8-R charset encoding. What is me do? Instructions llike ?xml version=1.0 encoding=KOI8-R? in header jsp page or map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator in sitemap.xmap Don't solved my problem Instruction like %@ page language=java encoding=KOI8-R% in jsp page is not valid I have use jasper-compiler.jar from /CATALINA_HOME/jasper dir Cocoon don't compiled without this library in WEB-INF/lib dir my jsp page. Can anyone help me with this problem? Thanx Yury. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSPGenerator encoding problem
From: yuryx [mailto:[EMAIL PROTECTED]] Thanx for ideas ,Vadim. But I can't undestand how declare JSP encoding. Try to read JSP specification. Vadim instead of %out.println(?xml version='1.0' encoding='koi8-r'?);% I try ?xml version='1.0' encoding='KOI8-R'? in sample.jsp but again it doesn't work :( Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
From: yuryx [mailto:[EMAIL PROTECTED]] Thanx for ideas ,Vadim. But I can't undestand how declare JSP encoding. Try to read JSP specification. The correct declaration is: %@ page language=java import=java.text.SimpleDateFormat,java.util.* pageEncoding=KOI8-R%?xml version='1.0' encoding=KOI8-R? Note, that your XML to be parsed you should put ?xml ...? declaration on the same line as %@ page ..., otherwise an empty line is added at the beginning of the page and this causes parsing error. Regards, Konstantin P.S. I've already sent the corrected file off-list. Vadim instead of %out.println(?xml version='1.0' encoding='koi8-r'?);% I try ?xml version='1.0' encoding='KOI8-R'? in sample.jsp but again it doesn't work :( Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSPGenerator encoding problem
From: yuryx [mailto:[EMAIL PROTECTED]] Hi all! My JSPGenerator or jasper-compiler don't supported KOI8-R charset encoding. What is me do? Use UTF-8 or Win-1251 which are (IIRC) supported. Vadim Instructions llike ?xml version=1.0 encoding=KOI8-R? in header jsp page or map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator in sitemap.xmap Don't solved my problem Instruction like %@ page language=java encoding=KOI8-R% in jsp page is not valid I have use jasper-compiler.jar from /CATALINA_HOME/jasper dir Cocoon don't compiled without this library in WEB-INF/lib dir my jsp page. Can anyone help me with this problem? Thanx Yury. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
From: yuryx [mailto:[EMAIL PROTECTED]] Hi all! My JSPGenerator or jasper-compiler don't supported KOI8-R charset encoding. What is me do? Use UTF-8 or Win-1251 which are (IIRC) supported. KOI8-R is supported too. I've just checked. Vadim Instructions llike ?xml version=1.0 encoding=KOI8-R? in header jsp page or map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator in sitemap.xmap Don't solved my problem Instruction like %@ page language=java encoding=KOI8-R% in jsp page is not valid I have use jasper-compiler.jar from /CATALINA_HOME/jasper dir Cocoon don't compiled without this library in WEB-INF/lib dir my jsp page. Can anyone help me with this problem? Thanx Yury. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
Shes live!!! :) Thanx for Piroumian, Konstantin and Vadim Gritsenko Also thanx for all I try %@ page language=java import=java.text.SimpleDateFormat,java.util.* _/*pageEncoding=KOI8-R*/_% in my jsp page and this solve problem. following line in sitemap map:serialize type=html encodingKOI8-R/encoding /map:serialize for encoding on generation part do nothig... Thanx all again! Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSPGenerator encoding problem
Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(paraÐÒÉ×ÅÔ!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
Is it the problem of JSPGenerator or maybe this happens during transformation or serialization? Try to remove the transformer from the pipeline or replace JSPGenerator with FileGenerator and use static content in KOI8-r to find out what is the cause of the problem. Regards, Konstantin Piroumian - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 7:50 PM Subject: JSPGenerator encoding problem Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(paraÐÒÉ×ÅÔ!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
Without transformation I have page content paraETH;Ograve;Eacute;times;Aring;Ocirc;!/para /content /page Problem with generation, I know... Piroumian, Konstantin wrote: Is it the problem of JSPGenerator or maybe this happens during transformation or serialization? Try to remove the transformer from the pipeline or replace JSPGenerator with FileGenerator and use static content in KOI8-r to find out what is the cause of the problem. Regards, Konstantin Piroumian - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 7:50 PM Subject: JSPGenerator encoding problem Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(paraÐÒÉ×ÅÔ!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSPGenerator encoding problem
Your JSP is not valid. It does not declares JSP encoding as it should. Obviously JSP runtime is unable to read characters correctly. Regards, Vadim -Original Message- From: yuryx [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 1:06 PM To: [EMAIL PROTECTED] Subject: Re: JSPGenerator encoding problem Without transformation I have page content paraETH;Ograve;Eacute;times;Aring;Ocirc;!/para /content /page Problem with generation, I know... Piroumian, Konstantin wrote: Is it the problem of JSPGenerator or maybe this happens during transformation or serialization? Try to remove the transformer from the pipeline or replace JSPGenerator with FileGenerator and use static content in KOI8-r to find out what is the cause of the problem. Regards, Konstantin Piroumian - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 7:50 PM Subject: JSPGenerator encoding problem Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(paraÐÒÉ×ÅÔ!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
Thanx for ideas ,Vadim. But I can't undestand how declare JSP encoding. instead of %out.println(?xml version='1.0' encoding='koi8-r'?);% I try ?xml version='1.0' encoding='KOI8-R'? in sample.jsp but again it doesn't work :( Yury Vadim Gritsenko wrote: Your JSP is not valid. It does not declares JSP encoding as it should. Obviously JSP runtime is unable to read characters correctly. Regards, Vadim -Original Message- From: yuryx [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 1:06 PM To: [EMAIL PROTECTED] Subject: Re: JSPGenerator encoding problem Without transformation I have page content paraETH;Ograve;Eacute;times;Aring;Ocirc;!/para /content /page Problem with generation, I know... Piroumian, Konstantin wrote: Is it the problem of JSPGenerator or maybe this happens during transformation or serialization? Try to remove the transformer from the pipeline or replace JSPGenerator with FileGenerator and use static content in KOI8-r to find out what is the cause of the problem. Regards, Konstantin Piroumian - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 7:50 PM Subject: JSPGenerator encoding problem Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(paraÐÒÉ×ÅÔ!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
Another idea: %@ page language=java encoding=koi8-r% or something like %@ page language=java % % response.setContentType(text/xml; charset=KOI8-r); % If you can send your JSP page to me I can take a look at it. - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 08, 2002 9:46 AM Subject: Re: JSPGenerator encoding problem Thanx for ideas ,Vadim. But I can't undestand how declare JSP encoding. instead of %out.println(?xml version='1.0' encoding='koi8-r'?);% I try ?xml version='1.0' encoding='KOI8-R'? in sample.jsp but again it doesn't work :( Yury Vadim Gritsenko wrote: Your JSP is not valid. It does not declares JSP encoding as it should. Obviously JSP runtime is unable to read characters correctly. Regards, Vadim -Original Message- From: yuryx [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 1:06 PM To: [EMAIL PROTECTED] Subject: Re: JSPGenerator encoding problem Without transformation I have page content paraETH;Ograve;Eacute;times;Aring;Ocirc;!/para /content /page Problem with generation, I know... Piroumian, Konstantin wrote: Is it the problem of JSPGenerator or maybe this happens during transformation or serialization? Try to remove the transformer from the pipeline or replace JSPGenerator with FileGenerator and use static content in KOI8-r to find out what is the cause of the problem. Regards, Konstantin Piroumian - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 7:50 PM Subject: JSPGenerator encoding problem Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(paraÐÒÉ×ÅÔ!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
Hi Peter! I try your recomendation but it don't solved my problem :( Encoding problem in Generator , or, maybe, in jasper compiller... Yury Peter Schwenke wrote: Hi Yury, Have you tried map:serializers default=html map:serializer name=links src=org.apache.cocoon.serialization.LinkSerializer/ map:serializer name=xmlmime-type=text/xml src=org.apache.cocoon.serialization.XMLSerializer pool-max=32 pool-min=16 pool-grow=4/ map:serializer name=html mime-type=text/html src=org.apache.cocoon.serialization.HTMLSerializer encodingkoi8-r/encoding That is, put the koi8-r encoding here /map:serializer ...Peter yuryx writes: Without transformation I have page content paraETH;Ograve;Eacute;times;Aring;Ocirc;!/para /content /page Problem with generation, I know... Piroumian, Konstantin wrote: Is it the problem of JSPGenerator or maybe this happens during transformation or serialization? Try to remove the transformer from the pipeline or replace JSPGenerator with FileGenerator and use static content in KOI8-r to find out what is the cause of the problem. Regards, Konstantin Piroumian - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 7:50 PM Subject: JSPGenerator encoding problem Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(para!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSPGenerator encoding problem
Piroumian, Konstantin wrote: Another idea: %@ page language=java encoding=koi8-r% Hi Konstantin! with this idea I have next exception /org.apache.cocoon.ProcessingException: ServletException in JspGenerator.generate()/ or something like %@ page language=java % % response.setContentType(text/xml; charset=KOI8-r); % If you can send your JSP page to me I can take a look at it. My simple jsp page: ?xml version='1.0' encoding=KOI8-R? %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content % out.println(paraÐÒÉ×ÅÔ!/para); % /content /page - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 08, 2002 9:46 AM Subject: Re: JSPGenerator encoding problem Thanx for ideas ,Vadim. But I can't undestand how declare JSP encoding. instead of %out.println(?xml version='1.0' encoding='koi8-r'?);% I try ?xml version='1.0' encoding='KOI8-R'? in sample.jsp but again it doesn't work :( Yury Vadim Gritsenko wrote: Your JSP is not valid. It does not declares JSP encoding as it should. Obviously JSP runtime is unable to read characters correctly. Regards, Vadim -Original Message- From: yuryx [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 1:06 PM To: [EMAIL PROTECTED] Subject: Re: JSPGenerator encoding problem Without transformation I have page content paraETH;Ograve;Eacute;times;Aring;Ocirc;!/para /content /page Problem with generation, I know... Piroumian, Konstantin wrote: Is it the problem of JSPGenerator or maybe this happens during transformation or serialization? Try to remove the transformer from the pipeline or replace JSPGenerator with FileGenerator and use static content in KOI8-r to find out what is the cause of the problem. Regards, Konstantin Piroumian - Original Message - From: yuryx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 7:50 PM Subject: JSPGenerator encoding problem Hello all! I have following problem. JSPGenerator doesn't normally encoding non english characters. Simple sample: sample.jsp: %out.println(?xml version='1.0' encoding='koi8-r'?);% %@ page language=java import=java.text.SimpleDateFormat,java.util.*,java.sql.*% page content %out.println(paraÐÒÉ×ÅÔ!/para);% /content /page sample.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=page html head title xsl:value-of select=title/ /title /head body bgcolor=white alink=red link=blue vlink=blue xsl:apply-templates/ /body /html /xsl:template xsl:template match=para bxsl:value-of select=.//b /xsl:template /xsl:stylesheet I have following line in sitemap: map:generator name=jsp src=org.apache.cocoon.generation.JspGenerator logger=sitemap.generator.jsp label=content,data encodingKOI8-R/encoding /map:generator ...and... map:match pattern=sample-jsp map:generate type=jsp src=/statesql/sample.jsp/ map:transform src=statesql/sample.xsl/ map:serialize type=html/ /map:match After generation I have next: html head meta http-equiv=Content-Type content=text/html; charset=UTF-8 title/title /head body vlink=blue link=blue alink=red bgcolor=white content ???bETH;Ograve;Eacute;times;Aring;Ocirc;!/b ??? /content /body /html Can anyone help me? Thanx Yury - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Encoding problem
Hello, In order to try to understand cocoon, I am currentlyplayingwith the "SamplesForms"examples : When I add a new employee with the name "André Testeur" , the database packagesend it with the wrong char encoding to the db In order to correct this I patched org.apache.cocoon.acting.AbstractDatabaseAction.setColumn(PreparedStatement statement, int position, Request request, Configuration entry, String param, Object value, int rowIndex) Is there a cleaner way to do it ? Thanks in advance, Christophe Rykiel
Re: urgent encoding problem...
Hi karl,
In cocoon 1.8.2 there is no XMLSerializer
ot HTMLSerializer .. can you tell which are the files which does the work of
these in 1.8.2 please
reg
Arun.N
- Original Message -
From:
Karl Øie
To: [EMAIL PROTECTED]
Sent: Wednesday, December 12, 2001 6:33
PM
Subject: RE: urgent encoding
problem...
erm... that code snipple was from the XMLSerializer,
not the HTMLSerializer as i wrote, but the approach should be the same..
sorry!
mvh
karl øie
-Original Message-From: Karl Øie
[mailto:[EMAIL PROTECTED]]Sent: 12. desember 2001 13:51To:
[EMAIL PROTECTED];
Arun.NSubject: RE: urgent encoding
problem...
the increasing page size does not concern me (:-)
because the serializer should write directly to the
response.getPrintWriter(). Then again, the serializer does not flush before
the end of the page, so users must wait till the page is
finished.
when it comes to the missing characters. you could
try to create your own serializer, let's take a look at the code for the
HTMLSerializer
(org.apache.cocoon.serialization.XMLSerializer);
the method for the outputstream uses javax.xml to
set the transformers properties
public void
setOutputStream(OutputStream out)
{ try
{
super.setOutputStream(out);
this.handler =
getTransformerFactory().newTransformerHandler();
format.put(OutputKeys.METHOD,"xml");
handler.setResult(new
StreamResult(this.output));
handler.getTransformer().setOutputProperties(format);
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e)
{
getLogger().error("XMLSerializer.setOutputStream()",
e);
throw new
RuntimeException(e.toString());
} }
if
you here force the transformer to use your encoding like
this;
public void
setOutputStream(OutputStream out)
{ try
{
super.setOutputStream(out);
this.handler =
getTransformerFactory().newTransformerHandler();
format.put(OutputKeys.METHOD,"xml");
format.put(OutputKeys.ENCODING,"SHIFT_JIS"); - add
this
handler.setResult(new
StreamResult(this.output));
handler.getTransformer().setOutputProperties(format);
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e)
{
getLogger().error("XMLSerializer.setOutputStream()",
e);
throw new
RuntimeException(e.toString());
} }
and then recompile cocoon, now try to your page and
tell me what happens. please also read this note from the xalan
faq
http://xml.apache.org/xalan-j/usagepatterns.html#outputencoding
mvh karl øie
-Original Message-From: Arun.N
[mailto:[EMAIL PROTECTED]]Sent: 12. desember 2001
13:33To: [EMAIL PROTECTED];
[EMAIL PROTECTED]Subject: Re: urgent encoding
problem...
Thank you karl.
I have fixed that problem and i have followed the
method which you have said.
every thing is being displayed
properly but there is still a problem in the source code.
if the string
contains
‚±‚¿‚ç‚É–|–óŒã‚Ì•¶Í‚ª•\Ž¦‚³‚ê‚Ü‚·B
it is priniting
こちらに翻訳後の文章が表示されます。
but when i look into the source
of the output html it is showing
#12371;#12385;#12425;#12395;#32763;#35379;#24460;#12398;#25991;#31456;#12364;#34920;#31034;#12373;#12428;#12414;#12377;#12290;
if the source has characters
like this also ‚±‚¿‚ç‚É–|–óŒã‚Ì•¶Í‚ª•\Ž¦‚³‚ê‚Ü‚·Bit willwork
fine and out put japanese characters will be the same . but why is cocoon
processor replacing everything into numbers. My concern here is, it is
increasing the page size.
any comments in this regard
???
Thankx in advance,
Arun.N
- Original Message -
From:
Karl Øie
To: [EMAIL PROTECTED]
; Arun.N
Sent: Wednesday, December 12, 2001
5:44 PM
Subject: RE: urgent encoding
problem...
it's not that people don't bother to answer you
but a lot of people here don't have any experience with shift-jis
encoding. as a Norwegian I have the same problem, non Scandinavians can
hardly reproduce problems revolving
Scandinavian-characters.
when it comes to your string problem there can be several
sources. first of all you can test the dom by feeding it a string that
has been created with a declared encoding, like :
new String("æ e trønder æ å" ); will not work on
all jdks/platforms
Encoding problem with dynamic content in XSP
Hello from a new XSP user. I ask advice and suggestions on how to get dynamic content in UTF-8 encoding correctly through XSP. I am using Cocoon 1.8.2 with Tomcat 3.2.3 and Apache 1.3.14, running on Suse Linux 7.1. I have made an xsp:pagesearch pagethat retrieves data from the dbXML database (soon to be Apache Xindice) and integrates this with static XML content. dbXML has a java interface and the results from database queries are delivered and insertedas DOM nodes: xsp:exprXSPUtil.cloneNode(fetchedDoc, document)/xsp:expr where fetchedDoc is the node that resulted from the database query. Static content is decoded correctly, but the dynamically fetched documents are not. Everything in my page and XSL stylesheet is UTF-8, as indicated in the xml declarations: ?xml version="1.0" encoding="UTF-8"? Everything in the dbXML data store is UTF-8 as well. XSP and the html formatter has been set up to deliver UTF-8 in cocoon.properties: processor.xsp.encoding = UTF-8 ... formatter.text/html.encoding = UTF-8 The problem arises with multi-byte characters being delivered in the DOM nodes from dbXML. They are fetched correctly with the correct multi-byte contents, but somewhere in the processing pipeline each byte is being treated as a single character and rendered as such in the XSL transformation. If you save the output as ISO-8859-1 and then read it into an UTF-8 editor, the result is correct. So, somehow the interpretation of dynamic and static content gets out of sync concerning the encoding. The problemdoes not seem to be the XSLT however, as you get the same result with the text/plain formatter. How to fix this?Many thanks for your attention. Anders Anders Conrad Det Danske Sprog- og LitteraturselskabIT-redaktør, cand.mag. Christians Brygge 1E-mail: [EMAIL PROTECTED] 1219 København K Tlf. 33 13 06 60
Re: urgent encoding problem...
Hi all, First of all i thank everybody for not bothering to reply. I corrected the second and the third problem. If the list is still alive and anyone cares to give me solution for thefirst problemplease do reply. thankx, Arun.N - Original Message - From: Arun.N To: [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 1:31 PM Subject: urgent encoding problem... Hi all, I have some problems with the xsp pages and encoding. When i try to display Shift_JIS encoded characters it is not displaying properly. when i hard code the japnese characters it is working properly. for example in this xsp page ?xml version="1.0" encoding="Shift_JIS"? ?cocoon-process type="xsp"? ?cocoon-process type="xslt"? ?xml-stylesheet href="xsl/viewMail-to-html.xsl" type="text/xsl" ? xsp:page language="java" encoding="Shift_JIS" xmlns:xsp="http://www.apache.org/1999/XSP/Core" xmlns:request="http://www.apache.org/1999/XSP/Request" xmlns:util="http://www.apache.org/1999/XSP/Util" pagetitlemelpo View Mail/title body label‚‚È‚½‚ÌPC‚Ì’†‚̃[ƒ‹ƒNƒ‰ƒCƒAƒ“ƒg‚ªÄŠJ‚³‚ê‚Ü‚µ‚½B /label /body /xsp:page the display html is working fine and the characters are working properly .. but the source of the html shows html body #12354;#12394;#12383;#12398;PC#12398;#20013;#12398;#12513;#12540;#12523;#12463;#12521;#12452;#12450;#12531;#12488;#12364;#20877;#38283;#12373;#12428;#12414;#12375;#12383;#12290; /body /html !-- This page was served in 2278 milliseconds by Cocoon 1.8.2 -- but why is the characters converted into numbers. the problem i have here is this consumes more bytes .. so if the device has some size limitations of the source of the pagethen it is a problem. if the characters are left same way then it would consume less bytes for the source page. The second problem is, wheni dynamically includexml in my xsp it is not working. But the same stringwhen hardcode in the xsp page it is working fine. ?xml version="1.0" encoding="Shift_JIS"? ?cocoon-process type="xsp"? ?cocoon-process type="xslt"? ?xml-stylesheet href="xsl/viewMail-to-html.xsl" type="text/xsl" ? xsp:page language="java" encoding="Shift_JIS" xmlns:xsp="http://www.apache.org/1999/XSP/Core" xmlns:request="http://www.apache.org/1999/XSP/Request" xmlns:util="http://www.apache.org/1999/XSP/Util" pagetitlemelpo View Mail/title body xsp:logic String xml = (String) request.getAttribute(xml); xsp:content util:include-exprutil:exprxml/util:expr/util:include-expr // this will append an xml string like label‚‚È‚½‚ÌPC‚Ì’†‚̃[J‚³‚ê‚Ü‚µ‚½B /label /xsp:content /xsp:logic /body /xsp:page i am getting an error org.xml.sax.SAXException: An invalid XML character (Unicode: 0x13) was found in the element content of the document. [FATAL ERROR] [File: "null" Line: 1 Column: 109] (nested exception: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x13) was found in the element content of the document.) But the string i am getting if hardcoded itzworking fine. because whrn i hardcode it, the xsp page when getting compiled, it is converting all the characters to those numbers. and whenever the string is dynamically included the it is not working.. and the third problem is , when i load a string to a dom andthen get back the string the encoding information is gone.The characers displayed are ??? String fullXml = "?xml version=\"1.0\" encoding=\"Shift_JIS\"?ResponseMessageMail Client in your PC has been ƒƒOƒAƒEƒg Restarted ƒGƒLƒTƒCƒg : –|–ó„—˜—p‹K–ñ xxx /Message/Response"; DOMParser parser = new DOMParser();InputStream is = new ByteArrayInputStream(fullXml.getBytes());InputSource isource=new InputSource(is);parser.parse(isource);Document xmlDoc= parser.getDocument();//created an dom doing some manipulation -- OutputFormat format = new OutputFormat( xmlDoc ); //Serialize DOM StringWriter stringOut = new StringWriter(); //Writer will be a String XMLSerializer serial = new XMLSerializer( stringOut, format ); serial.asDOMSerializer(); // As a DOM Serializer serial.serialize( xmlDoc.getDocumentElement() ); String returnXML = stringOut.toString(); // got back the xml as String. now if i display the string " returnXML " all the japanese characters are gone. the output is only "???" Can any of you please give a solution for these problems, as it is very urgent for me. I have been trying to solve theses isuues from past 2 days and have searched mail archives i was not able to find a solution. Thankx in Advance regards, Arun.N,
RE: urgent encoding problem...
it's
not that people don't bother to answer you but a lot of people here don't have
any experience with shift-jis encoding. as a Norwegian I have the same problem,
non Scandinavians can hardly reproduce problems revolving
Scandinavian-characters.
when
it comes to your string problem there can be several sources. first of all you
can test the dom by feeding it a string that has been created with a declared
encoding, like :
new String("æ e trønder æ å" ); will not work on all
jdks/platforms
new String("æ e trønder æ å", "UTF-16" ); will work
on most sane jdks/platforms
try to
create all your strings with shift_jis forced, just in case. second find out
weither StringWriter does support shift_jis, as far as i know StringWriter are
working on chars and strings and should support shift_jis if all strings fed to
it is shift_jis created. lastly there is some problems regarding the PrintWriter
that the servlet api are using to return serialized content to the browser, try
to serialize to a file instead of to the browser, if the file accepts shift_jis
then you should look up fixes/gotchas regarding shift_jis and jsp as cocoon are
using the jsp mechanism to send the response back to the user.
the best
place to start looking is the xalan faqs and docs because if you use the xml or
html serializer it's using the xalan implementations.
mvh karl
øie
-Original Message-From: Arun.N
[mailto:[EMAIL PROTECTED]]Sent: 12. desember 2001
12:48To: [EMAIL PROTECTED]Subject: Re: urgent
encoding problem...
Hi all,
First of all i thank everybody for not
bothering to reply. I corrected the second and the third problem. If the list
is still alive and anyone cares to give me solution for thefirst
problemplease do reply.
thankx,
Arun.N
- Original Message -
From:
Arun.N
To: [EMAIL PROTECTED]
Sent: Tuesday, December 11, 2001 1:31
PM
Subject: urgent encoding
problem...
Hi all,
I
have some problems with the xsp pages and encoding. When i try to display
Shift_JIS encoded characters it is not displaying properly.
when i hard code the japnese
characters it is working properly. for example in this xsp page
?xml version="1.0"
encoding="Shift_JIS"?
?cocoon-process
type="xsp"?
?cocoon-process
type="xslt"?
?xml-stylesheet
href="xsl/viewMail-to-html.xsl" type="text/xsl" ?
xsp:page
language="java" encoding="Shift_JIS" xmlns:xsp="http://www.apache.org/1999/XSP/Core"
xmlns:request="http://www.apache.org/1999/XSP/Request"
xmlns:util="http://www.apache.org/1999/XSP/Util"
pagetitlemelpo View
Mail/title
body
label‚‚È‚½‚ÌPC‚Ì’†‚̃[ƒ‹ƒNƒ‰ƒCƒAƒ“ƒg‚ªÄŠJ‚³‚ê‚Ü‚µ‚½B
/label
/body
/xsp:page
the display html is working fine
and the characters are working properly .. but the source of the html shows
html
body
#12354;#12394;#12383;#12398;PC#12398;#20013;#12398;#12513;#12540;#12523;#12463;#12521;#12452;#12450;#12531;#12488;#12364;#20877;#38283;#12373;#12428;#12414;#12375;#12383;#12290;
/body
/html
!-- This page was served in
2278 milliseconds by Cocoon 1.8.2 --
but why is the characters
converted into numbers. the problem i have here is this consumes more bytes
.. so if the device has some size limitations of the source of the
pagethen it is a problem. if the characters are left same way then it
would consume less bytes for the source page.
The second problem is,
wheni dynamically includexml in my xsp it is not working. But
the same stringwhen hardcode in the xsp page it is working
fine.
?xml version="1.0"
encoding="Shift_JIS"?
?cocoon-process
type="xsp"?
?cocoon-process
type="xslt"?
?xml-stylesheet
href="xsl/viewMail-to-html.xsl" type="text/xsl" ?
xsp:page
language="java" encoding="Shift_JIS" xmlns:xsp="http://www.apache.org/1999/XSP/Core"
xmlns:request="http://www.apache.org/1999/XSP/Request"
xmlns:util="http://www.apache.org/1999/XSP/Util"
pagetitlemelpo View
Mail/title
body
xsp:logic
String
xml = (String) request.getAttribute(xml);
xsp:content
util:include-exprutil:exprxml/util:expr/util:include-expr
// this will append an xml string like
label‚‚È‚½‚ÌPC‚Ì’†‚̃[J‚³‚ê‚Ü‚µ‚½B
/label
/xsp:content
/xsp:logic
/body
/xsp:page
i am getting an error
org.xml.sax.SAXException: An invalid XML character (Unicode: 0x13)
was
Re: urgent encoding problem...
Thank you karl.
I have fixed that problem and i have followed the method which you have said.
every thing is being displayed
properly but there is still a problem in the source code.
if the string
contains ‚±‚¿‚ç‚É–|–óŒã‚Ì•¶Í‚ª•\Ž¦‚³‚ê‚Ü‚·B
it is priniting
こちらに翻訳後の文章が表示されます。
but when i look into the source of
the output html it is showing
#12371;#12385;#12425;#12395;#32763;#35379;#24460;#12398;#25991;#31456;#12364;#34920;#31034;#12373;#12428;#12414;#12377;#12290;
if the source has characters like
this also ‚±‚¿‚ç‚É–|–óŒã‚Ì•¶Í‚ª•\Ž¦‚³‚ê‚Ü‚·Bit willwork fine and
out put japanese characters will be the same . but why is cocoon processor
replacing everything into numbers. My concern here is, it is increasing the page
size.
any comments in this regard
???
Thankx in advance,
Arun.N
- Original Message -
From:
Karl Øie
To: [EMAIL PROTECTED] ; Arun.N
Sent: Wednesday, December 12, 2001 5:44
PM
Subject: RE: urgent encoding
problem...
it's
not that people don't bother to answer you but a lot of people here don't have
any experience with shift-jis encoding. as a Norwegian I have the same
problem, non Scandinavians can hardly reproduce problems revolving
Scandinavian-characters.
when
it comes to your string problem there can be several sources. first of all you
can test the dom by feeding it a string that has been created with a declared
encoding, like :
new String("æ e trønder æ å" ); will not work on all
jdks/platforms
new String("æ e trønder æ å", "UTF-16" ); will
work on most sane jdks/platforms
try to
create all your strings with shift_jis forced, just in case. second find out
weither StringWriter does support shift_jis, as far as i know StringWriter are
working on chars and strings and should support shift_jis if all strings fed
to it is shift_jis created. lastly there is some problems regarding the
PrintWriter that the servlet api are using to return serialized content to the
browser, try to serialize to a file instead of to the browser, if the file
accepts shift_jis then you should look up fixes/gotchas regarding shift_jis
and jsp as cocoon are using the jsp mechanism to send the response back to the
user.
the
best place to start looking is the xalan faqs and docs because if you use the
xml or html serializer it's using the xalan implementations.
mvh
karl øie
-Original Message-From: Arun.N
[mailto:[EMAIL PROTECTED]]Sent: 12. desember 2001
12:48To: [EMAIL PROTECTED]Subject: Re:
urgent encoding problem...
Hi all,
First of all i thank everybody for not
bothering to reply. I corrected the second and the third problem. If the
list is still alive and anyone cares to give me solution for thefirst
problemplease do reply.
thankx,
Arun.N
- Original Message -
From:
Arun.N
To: [EMAIL PROTECTED]
Sent: Tuesday, December 11, 2001 1:31
PM
Subject: urgent encoding
problem...
Hi all,
I have some problems with the xsp pages and encoding. When i try to
display Shift_JIS encoded characters it is not displaying
properly.
when i hard code the japnese
characters it is working properly. for example in this xsp
page
?xml version="1.0"
encoding="Shift_JIS"?
?cocoon-process
type="xsp"?
?cocoon-process
type="xslt"?
?xml-stylesheet
href="xsl/viewMail-to-html.xsl" type="text/xsl" ?
xsp:page
language="java" encoding="Shift_JIS" xmlns:xsp="http://www.apache.org/1999/XSP/Core"
xmlns:request="http://www.apache.org/1999/XSP/Request"
xmlns:util="http://www.apache.org/1999/XSP/Util"
pagetitlemelpo View
Mail/title
body
label‚‚È‚½‚ÌPC‚Ì’†‚̃[ƒ‹ƒNƒ‰ƒCƒAƒ“ƒg‚ªÄŠJ‚³‚ê‚Ü‚µ‚½B
/label
/body
/xsp:page
the display html is working
fine and the characters are working properly .. but the source of the html
shows
html
body
#12354;#12394;#12383;#12398;PC#12398;#20013;#12398;#12513;#12540;#12523;#12463;#12521;#12452;#12450;#12531;#12488;#12364;#20877;#38283;#12373;#12428;#12414;#12375;#12383;#12290;
/body
/html
!-- This page was served in
2278 milliseconds by Cocoon 1.8.2 --
but why is the characters
converted into numbers. the problem i have here is this consumes more
bytes .. so if the device has some size limitations of the source of the
pagethen it is a problem. if the characters are left same way then
it would consume less bytes for the source page.
RE: urgent encoding problem...
erm...
that code snipple was from the XMLSerializer, not the HTMLSerializer as i wrote,
but the approach should be the same.. sorry!
mvh
karl øie
-Original Message-From: Karl Øie
[mailto:[EMAIL PROTECTED]]Sent: 12. desember 2001 13:51To:
[EMAIL PROTECTED]; Arun.NSubject: RE: urgent encoding
problem...
the
increasing page size does not concern me (:-) because the serializer should
write directly to the response.getPrintWriter(). Then again, the serializer
does not flush before the end of the page, so users must wait till the page is
finished.
when
it comes to the missing characters. you could try to create your own
serializer, let's take a look at the code for the HTMLSerializer
(org.apache.cocoon.serialization.XMLSerializer);
the
method for the outputstream uses javax.xml to set the transformers
properties
public void
setOutputStream(OutputStream out)
{ try
{
super.setOutputStream(out);
this.handler =
getTransformerFactory().newTransformerHandler();
format.put(OutputKeys.METHOD,"xml");
handler.setResult(new
StreamResult(this.output));
handler.getTransformer().setOutputProperties(format);
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e)
{
getLogger().error("XMLSerializer.setOutputStream()",
e);
throw new
RuntimeException(e.toString());
} }
if
you here force the transformer to use your encoding like
this;
public void
setOutputStream(OutputStream out)
{ try
{
super.setOutputStream(out);
this.handler =
getTransformerFactory().newTransformerHandler();
format.put(OutputKeys.METHOD,"xml");
format.put(OutputKeys.ENCODING,"SHIFT_JIS"); - add
this
handler.setResult(new
StreamResult(this.output));
handler.getTransformer().setOutputProperties(format);
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e)
{
getLogger().error("XMLSerializer.setOutputStream()",
e);
throw new
RuntimeException(e.toString());
} }
and
then recompile cocoon, now try to your page and tell me what happens. please
also read this note from the xalan faq
http://xml.apache.org/xalan-j/usagepatterns.html#outputencoding
mvh
karl øie
-Original Message-From: Arun.N
[mailto:[EMAIL PROTECTED]]Sent: 12. desember 2001
13:33To: [EMAIL PROTECTED];
[EMAIL PROTECTED]Subject: Re: urgent encoding
problem...
Thank you karl.
I have fixed that problem and i have followed the method
which you have said.
every thing is being displayed
properly but there is still a problem in the source code.
if the string
contains ‚±‚¿‚ç‚É–|–óŒã‚Ì•¶Í‚ª•\Ž¦‚³‚ê‚Ü‚·B
it is priniting
こちらに翻訳後の文章が表示されます。
but when i look into the source
of the output html it is showing
#12371;#12385;#12425;#12395;#32763;#35379;#24460;#12398;#25991;#31456;#12364;#34920;#31034;#12373;#12428;#12414;#12377;#12290;
if the source has characters like
this also ‚±‚¿‚ç‚É–|–óŒã‚Ì•¶Í‚ª•\Ž¦‚³‚ê‚Ü‚·Bit willwork fine
and out put japanese characters will be the same . but why is cocoon
processor replacing everything into numbers. My concern here is, it is
increasing the page size.
any comments in this regard
???
Thankx in advance,
Arun.N
- Original Message -
From:
Karl Øie
To: [EMAIL PROTECTED] ; Arun.N
Sent: Wednesday, December 12, 2001
5:44 PM
Subject: RE: urgent encoding
problem...
it's not that people don't bother to answer you
but a lot of people here don't have any experience with shift-jis
encoding. as a Norwegian I have the same problem, non Scandinavians can
hardly reproduce problems revolving
Scandinavian-characters.
when it comes to your string problem there can be several sources.
first of all you can test the dom by feeding it a string that has been
created with a declared encoding, like :
new String("æ e trønder æ å" ); will not work on all
jdks/platforms
new
String("æ e trønder æ å",
"UTF-16" ); will work on most sane
jdks/platforms
try to create all your strings with shift_jis
forced, just in case. second find out weither StringWriter does support
shift_jis, as far as i know StringWriter are working on chars and strings
and should support shift_jis if all strings fed to it is shift_jis
created. lastly there is some problems regarding the PrintWriter that the
servlet api are using to return serialized content to the browser, try to
serialize to a file instead of to the browser, if the file accepts
sh
urgent encoding problem...
Hi all, I have some problems with the xsp pages and encoding. When i try to display Shift_JIS encoded characters it is not displaying properly. when i hard code the japnese characters it is working properly. for example in this xsp page ?xml version="1.0" encoding="Shift_JIS"? ?cocoon-process type="xsp"? ?cocoon-process type="xslt"? ?xml-stylesheet href="xsl/viewMail-to-html.xsl" type="text/xsl" ? xsp:page language="java" encoding="Shift_JIS" xmlns:xsp="http://www.apache.org/1999/XSP/Core" xmlns:request="http://www.apache.org/1999/XSP/Request" xmlns:util="http://www.apache.org/1999/XSP/Util" pagetitlemelpo View Mail/title body label‚‚È‚½‚ÌPC‚Ì’†‚̃[ƒ‹ƒNƒ‰ƒCƒAƒ“ƒg‚ªÄŠJ‚³‚ê‚Ü‚µ‚½B /label /body /xsp:page the display html is working fine and the characters are working properly .. but the source of the html shows html body #12354;#12394;#12383;#12398;PC#12398;#20013;#12398;#12513;#12540;#12523;#12463;#12521;#12452;#12450;#12531;#12488;#12364;#20877;#38283;#12373;#12428;#12414;#12375;#12383;#12290; /body /html !-- This page was served in 2278 milliseconds by Cocoon 1.8.2 -- but why is the characters converted into numbers. the problem i have here is this consumes more bytes .. so if the device has some size limitations of the source of the pagethen it is a problem. if the characters are left same way then it would consume less bytes for the source page. The second problem is, wheni dynamically includexml in my xsp it is not working. But the same stringwhen hardcode in the xsp page it is working fine. ?xml version="1.0" encoding="Shift_JIS"? ?cocoon-process type="xsp"? ?cocoon-process type="xslt"? ?xml-stylesheet href="xsl/viewMail-to-html.xsl" type="text/xsl" ? xsp:page language="java" encoding="Shift_JIS" xmlns:xsp="http://www.apache.org/1999/XSP/Core" xmlns:request="http://www.apache.org/1999/XSP/Request" xmlns:util="http://www.apache.org/1999/XSP/Util" pagetitlemelpo View Mail/title body xsp:logic String xml = (String) request.getAttribute(xml); xsp:content util:include-exprutil:exprxml/util:expr/util:include-expr // this will append an xml string like label‚‚È‚½‚ÌPC‚Ì’†‚̃[J‚³‚ê‚Ü‚µ‚½B /label /xsp:content /xsp:logic /body /xsp:page i am getting an error org.xml.sax.SAXException: An invalid XML character (Unicode: 0x13) was found in the element content of the document. [FATAL ERROR] [File: "null" Line: 1 Column: 109] (nested exception: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x13) was found in the element content of the document.) But the string i am getting if hardcoded itzworking fine. because whrn i hardcode it, the xsp page when getting compiled, it is converting all the characters to those numbers. and whenever the string is dynamically included the it is not working.. and the third problem is , when i load a string to a dom andthen get back the string the encoding information is gone.The characers displayed are ??? String fullXml = "?xml version=\"1.0\" encoding=\"Shift_JIS\"?ResponseMessageMail Client in your PC has been ƒƒOƒAƒEƒg Restarted ƒGƒLƒTƒCƒg : –|–ó„—˜—p‹K–ñ xxx /Message/Response"; DOMParser parser = new DOMParser();InputStream is = new ByteArrayInputStream(fullXml.getBytes());InputSource isource=new InputSource(is);parser.parse(isource);Document xmlDoc= parser.getDocument();//created an dom doing some manipulation -- OutputFormat format = new OutputFormat( xmlDoc ); //Serialize DOM StringWriter stringOut = new StringWriter(); //Writer will be a String XMLSerializer serial = new XMLSerializer( stringOut, format ); serial.asDOMSerializer(); // As a DOM Serializer serial.serialize( xmlDoc.getDocumentElement() ); String returnXML = stringOut.toString(); // got back the xml as String. now if i display the string " returnXML " all the japanese characters are gone. the output is only "???" Can any of you please give a solution for these problems, as it is very urgent for me. I have been trying to solve theses isuues from past 2 days and have searched mail archives i was not able to find a solution. Thankx in Advance regards, Arun.N,
