Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 63156 invoked from network); 16 Jan 2006 18:15:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Jan 2006 18:15:10 -0000 Received: (qmail 71507 invoked by uid 500); 16 Jan 2006 18:15:04 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 71428 invoked by uid 500); 16 Jan 2006 18:15:03 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 71413 invoked by uid 99); 16 Jan 2006 18:15:03 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2006 10:15:03 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of ottosmops@gmail.com designates 64.233.162.202 as permitted sender) Received: from [64.233.162.202] (HELO zproxy.gmail.com) (64.233.162.202) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2006 10:15:02 -0800 Received: by zproxy.gmail.com with SMTP id x7so1156877nzc for ; Mon, 16 Jan 2006 10:14:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type; b=qSR1j7cZVSasIB1H7NM3hVWHjsFXwS1QaWWThA6VVmlpiSg2XWEfQgRb0zBizZnMUJwJQh10qTvPzK2Qr9j2C/RRPPLRgyEeeDhrEtDJinrdIaZY51jyeRFWBbkbMIiibDaYy38bk4aNqsxuvAYJgnP6rPANXRo33gyg53EY1ho= Received: by 10.36.67.12 with SMTP id p12mr5214412nza; Mon, 16 Jan 2006 10:14:42 -0800 (PST) Received: from ?192.168.2.32? ( [213.160.80.6]) by mx.gmail.com with ESMTP id 15sm1071160nzp.2006.01.16.10.14.40; Mon, 16 Jan 2006 10:14:41 -0800 (PST) Message-ID: <43CBE33B.7090402@gmail.com> Date: Mon, 16 Jan 2006 19:17:31 +0100 From: christian bindeballe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: users@cocoon.apache.org Subject: Re: XML-Serializer encoding References: <87ad5ee90601160408n74be6399m@mail.gmail.com> <43CBCBFB.2000906@outerthought.org> In-Reply-To: <43CBCBFB.2000906@outerthought.org> Content-Type: multipart/mixed; boundary="------------000204000701020907040801" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --------------000204000701020907040801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Marc, Marc Portier schrieb: > never change your container-encoding unless you have a servlet container > of which you can specify the used encoding applied in decoding of url's > and request parameters > > (if you don't understand what I just said: that translates to simply > "never") I think I got it :) It also said that in the comments of the web.xml - file, as to never change it unless the servlet-container is buggy (which I suppose Tomcat 5.0.28 is not), but I thought I might give it a shot. But since that didn't help I changed it back to the original setting > like where? I just did a rough scan but couldn't find any 'multiple byte > for single character' occurances OK, so I belive I got something wrong. These characters that I thought to be Unicode-Characters are rather XML-Interpretations? There are often Chars like ” in the feeds. Since these aren't translated properly and they are not part of Latin-1 I thought they must be UTF-8, which they obviously aren't, or are they? >>$ wget -q -O - http://www.industrial-technology-and-witchcraft.de/index.php/ITW/itw-rss20/ | grep '&#' > > > are all punctuation chars that seem to be correctly applied see above :) you're more than probably right > I have never used coplets, nor even looked at them (deeply sorry) > but I would certainly check the way these feeds are interpreted in the > first place (rather then how they are serialized) > > if that is bad, then nothing furtheron in the pipe will be able to > produce decent characterstreams regardless of encoding scheme's you're > trying out on the serializer This is the relevant part of my sitemap: So my next thought was that it is the XSL that is messing up the RSS. So I edited the XSL and added this line after the but it didn't help either. Maybe someone would like to take a look at the xsl I attached to see whether there is something wrong with it? > > on the side: you don't need to set your serializer specific encoding if > you have set the form-encoding init param in the web.xml to utf-8 (which > I would suggest at all times) done. and thanks a lot for your effort, everybody. I really appreciate that :) best regards, christian --------------000204000701020907040801 Content-Type: text/xml; name="rss2html.xsl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rss2html.xsl"
 ()
 
  
--------------000204000701020907040801 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org For additional commands, e-mail: users-help@cocoon.apache.org --------------000204000701020907040801--