I have just recently resolved a problem with fragment identifiers in URLs for pages that are served-up by Cocoon in UTF-8 to IE 6 on the PC.
My sitemap was set-up to deliver XHTML in UTF-8 and IE understood this. However, if I sent a request that had a fragment identifier on the end: http://myserver/document/path/document.html#SL12345 IE ignored #SL12345 and did not scroll the page to the single instance of the specified id in the target document. But, when I followed the instructions in: http://wiki.apache.org/cocoon/RequestParameterEncoding regarding explicitly setting the Servlet container-encoding in Cocoon's web.xml it all worked happily :) I just thought people should know this. Should I add it to the afore mentioned wiki? Regards Phil Fennell -----Original Message----- From: Kees van Dieren [mailto:[EMAIL PROTECTED] Sent: 29 October 2004 06:38 To: Fennell, Philip, EMP-UK Subject: Re: Encoding problems, still! In mozilla Firefox, when you open the right-click menu and choose "View page Info" what is the value for Encoding there? The serializer still seems to use ISO-8859 (e.g. not UTF-8)(according to the link problem)? The serializer add's the encoding type to the resulting html page, just behind the <head> tag. It should add something like: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8> What is the charset in the resulting html page there? Encoding could also be sent within the headers. You can use WGet to view the headers (google for it to download it). with wget -d http://address/ you might see the encoding type specified in the content-type header. Is it correct there? Kind regards > On Thu, 28 Oct 2004, Joerg Heinicke wrote: > >> On 28.10.2004 21:35, Tuomo L wrote: >> >>> We're having some serious encoding problems. This happens only with >>> the @href attributes in html, when using characters like �, � and � >>> (in Finnish alphabet). Form encoding works just fine. I've gone >>> through all the threads concerning encoding (other people having >>> encoding problems too). No luck so far. Is this still an issue in >>> Cocoon? Could someone please tell what's wrong? >> >> What's the page encoding? Forms work like expected? Just the links >> don't work? This normally points to a different page encoding than >> UTF-8 as link requests are encoded in UTF-8 while form requests are >> encoded in page encoding. I don't think it is a Cocoon issue. >> >> Joerg > > Thanks Joerg, > > According to IE, the page encoding is set to UTF-8. The > container-encoding and form-encoding in web.xml (Tomcat) are set to > UTF-8. HTMLSerializer is set to use UTF-8 (mime-type="text/html; > charset=utf-8") and has the parameter <encoding>UTF-8</encoding>. The > xsl stylesheets use ISO-8859-1, though. I've also tried setting > everything to ISO-8859-1, but the problem with the href-attributes in > html remains. Mozilla Firefox shows the characters correctly when > doing "view source", but if I save the document on disk and open with > ASCII-editor, the encoding is wrong there with both IE and Mozilla. So > maybe it's not a browser problem? > > Here's an example: > > <a href="��" foo="��">��</a> > > becomes: > > <a href="%C3%A4%C3%B6" foo="äö">äö</a> > > when it should read (I think): > > <a href="äö" foo="äö">äö</a> > > > What's happening? > > -Tuomo > >> >> --------------------------------------------------------------------- >> 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] --------------------------------------------------------------------- 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]
