Okay, I started messing with the source, and found something rather 
puzzling.

If I add a line

            this.inputSource.setEncoding("UTF-8");

just above

            parser = (SAXParser)this.manager.lookup(SAXParser.ROLE);
            parser.parse(this.inputSource, super.xmlConsumer);

...nothing happens.

If I change "UTF-8" to "ISO-8859-1", the output is borked in exactly the 
same way -- nothing changes.

IOW, it appears that this.inputSource.setEncoding doesn't actually *do* 
anything.

Any clues?

/Petteri

Petteri Sulonen wrote:
> Trouble is I'm not sending the XML from a servlet; I'm sending it from 
> a browser. I've tried forcing a Content-Type header 
> "application/x-www-form-urlencoded; charset=utf-8" but the charset 
> part doesn't appear to do anything (and I'd prefer not to have to mess 
> with headers on the browser side, since this can lead to all kinds of 
> cross-browser pain). The pipeline breaks if I bork the header 
> altogether (e.g., I put in "this/is/junk; charset=utf-8"), but 
> changing the charset part to iso-8859-1 or this-is-not-an-encoding 
> doesn't make any difference.
>
> By the way, the stream generator sample at  
> [COCOON_HOME]/samples/stream/uploadstring breaks the same way when my 
> form-encoding is set to UTF-8, so it's not anything special about the 
> app I'm working on. If I change  <ShipName>Thoms White</ShipName> to 
> <ShipName>Thöms White</ShipName> and submit, I get back 
> <ShipName>Thöms White</ShipName>.
>
> Thanks anyway; I'll keep working on it. At least the StreamGenerator 
> source code is beautifully clear and well commented so if all else 
> fails I can patch it so it takes a sitemap parameter that forces the 
> encoding I want.
>
> /Petteri
>
> Víctor Pergolesi wrote:
>> Hi Peter:
>> generally when I send xml from a servlet to cocoon y set the 
>> ContentType to avoid this problem:
>>
>> protected void processRequest(HttpServletRequest request, 
>> HttpServletResponse response)
>>    throws ServletException, IOException {
>> ...
>> response.setContentType("text/xml; charset=UTF-8");
>> ...
>> }
>>
>> I hope this help you.
>>
>>
>> Victor Pergolesi
>>
>>   _____ 
>> From: Petteri Sulonen [mailto:Petteri.Sulonen@avaintec.com]
>> To: users@cocoon.apache.org
>> Sent: Wed, 18 Mar 2009 13:50:03 +0000
>> Subject: Stream generator encoding problem with Cocoon 2.1.11
>>
>> I'm in the process of moving a large Cocoon application from Cocoon   
>> 2.1.4 to 2.1.11 (LTTP, I know).
>>     * Platform: Ubuntu, Java 5, Jetty 6.1.15.
>>   * In web.xml, container-encoding set to ISO-8859-1, form-encoding 
>> UTF-8.
>>     Problem: when I POST form data to a stream generator, it behaves 
>> as if   the data was encoded in ISO-8859-1, even though it's encoded 
>> in UTF-8 as   intended (e.g. umlauted characters come back as two 
>> letters).
>>     However, when I bounce back the data using the request generator, 
>> the   encodings work as intended.
>>     This worked fine on 2.1.4.
>>     This borks the encodings:
>>           <map:match pattern="stream.xml">
>>           <map:generate type="stream">
>>             <map:parameter name="form-name" value="message"/>
>>           </map:generate>
>>           <map:serialize type="xml"/>
>>         </map:match>
>>     This doesn't bork them (but obviously I don't get the data as a 
>> SAX   stream, which is what I want):
>>           <map:match pattern="request.xml">
>>           <map:generate type="request"/>
>>           <map:serialize type="xml"/>
>>         </map:match>
>>           Input data is the same in both cases.
>>     On the client side, I'm dealing with two situations, regular POST 
>>   requests done via HTML forms, and dojo.xhrPost requests. (Currently 
>>   using Dojo 1.0.2, intending to migrate to Dojo 1.2 or 1.3 in the 
>> near   future), so I would much prefer a server-side solution if one 
>> is available.
>>     Any help would be much appreciated.
>>     /Petteri Sulonen
>>     
>> ---------------------------------------------------------------------
>>   To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>   For additional commands, e-mail: users-help@cocoon.apache.org
>>      
>>
>> Este mensaje y sus adjuntos contienen información confidencial y son 
>> para uso exclusivo del destinatario. Si hubiese recibido este mensaje 
>> por error, o contuviera información que Ud. no desea recibir, por 
>> favor le agradecemos nos lo haga saber y lo elimine de su sistema. 
>> Cualquier inconveniente, enviarlo a librodequejas@codimat.com.ar.
>> Este correo ha sido chequeado por el servidor de Codimat S.A. 
>> www.codimat.com.ar
>>
>>   
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org