Re: encoding problem

2002-10-25 Thread Boris Althaus



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

2002-10-25 Thread Bert Van Kets
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: encoding problem

2002-10-25 Thread Boris Althaus



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: Encoding problem with HTML-serializer and URLs

2002-10-14 Thread Alex Romayev

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: Encoding problem

2002-09-18 Thread Alex Romayev

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

2002-09-18 Thread Barbara Post

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

2002-09-18 Thread Alex Romayev


--- 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

2002-09-18 Thread Vadim Gritsenko

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

2002-09-18 Thread Alex Romayev


--- 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

2002-09-18 Thread Vadim Gritsenko

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

2002-09-18 Thread Alex Romayev


--- 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

2002-09-18 Thread Vadim Gritsenko

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

2002-09-18 Thread Alex Romayev


--- 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]




Re: encoding problem with xslt

2002-07-12 Thread Joerg Heinicke

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

2002-07-12 Thread Manos Batsis


 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

2002-07-12 Thread Joerg Heinicke

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

2002-07-12 Thread Manos Batsis


 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

2002-07-12 Thread Joerg Heinicke

 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

2002-07-12 Thread Jens Lorenz

- 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

2002-07-12 Thread Jens Lorenz

- 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

2002-07-12 Thread Vadim Gritsenko

 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

2002-07-12 Thread Joerg Heinicke

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

2002-07-12 Thread Jens Lorenz

- 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

2002-07-12 Thread Jens Lorenz

- 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]