On Sunday 06 October 2002 12:12 pm, Christopher H. Laco wrote: Well....
>From my reading of AxKit code and docs, plus what I know about HTTP etc: AxKit (and perl in general, esp 5.7.x and above) internally uses 100% UTF-8. In other words no matter what the encoding specified on your input documents, EVERYTHING is translated to UTF-8 before any processing happens, PERIOD. In any case, the XML declaration's specification of character set has NOTHING to do with what the output character set would be expected to be, it simply tells the processor reading the file that the INPUT is in a particular character set. Since UTF-8 is used internally, and ANY character can be represented in UTF-8, effectively the declaration just tells the XML parser how translate to UTF-8. On the OUTPUT side its pretty clear that AxKit attempts to translate the output to one of the character sets in the client's HTTP header "Accept-Charset: ". It may actually instead use UTF-8, either if the client does not specify a character set, or possibly (Matt would have to comment here...) if there were characters in the output that could not be represented in the target charset (IE ISO-8859-1 lacks "Klingon" characters, but UTF-8 has them, so I believe AxKit would fall back to UTF-8 to output Klingon, even if the client wanted ISO-8859-1). I have right this minute only the one sample of my own system for reference to the meta tag issue. When I load pages with Mozilla 1.0.1 I always get back a meta tag proclaiming UTF-8 as the encoding. I didn't have the time and energy to set up a packet sniffer to actually let me see what the Accept-Charset: was and how the two correlated, but setting the 'character encoding' options on both Mozilla and Konqueror produced no effect. I guess the real question now is, 'does AxKit actually adapt to the requested character set or not?' and 'does the meta tag it generates correspond to the character set it actually outputs?", more code analysis no doubt... > Sorry, I should've been more clear. > > The error itself is from the W3C validator. > While the pages are declared as being ISO-8859-1 in both the xsp/xml/xsl > source as well as in the meta tags (<meta http-equiv="Content-Type" > content="text/html; charset=ISO-8859-1" />), the output from Apache/AxKit > still has the Content-Type header set to UTF-8. > > All XSP/XSL pages are declared as encoding="ISO-8859-1", and the pages are > physically the ANSI code set w/ Unix line feeds. > > The base flow of the site is: > > XSP page -> Global Stylesheet (LibXSLT) -> to_xhtml styleshet (LibXSLT) > and out the door. > > > > In the last exciting episode of Das Internet, Piers Harding sent forth the > > following words of wisdom: > > Hmm - this is very strange - are you sure that the AxKit is producing > > this error, as I just grep'ed all the source code for it, and I couldn't > > find it? What other things are using - an XSLT processor etc. ? > > > > Cheers. > > > > On Sun, Oct 06, 2002 at 11:36:17AM -0400, Christopher H. Laco wrote: > >> Well, it made sense, but it doesn't change anything. > >> > >> I added this to httpd.conf: > >> > >> AxTranslateOutput On > >> AxOutputCharset ISO-8859-1 > >> > >> killed apache, cleared the cache directory, and restarted apache. Same > >> result as before... > >> > >> --- > >> * Warning: Character Encoding mismatch! The character encoding > >> specified in the HTTP header (�utf-8�) is different from the one > >> specified in the META element (�iso-8859-1�). I will use �utf-8� for > >> this validation. > >> --- > >> > >> So clearly , the solution is to change everything to declare UTF-8 > >> instead :-) > >> > >> > >> > >> In the last exciting episode of Das Internet, Christopher H. Laco sent > >> > >> forth the following words of wisdom: > >> > I'll bet money that is exactly the problem. Although, this sorta > >> > >> makes me ask; doesn't this make the process of specifying encoding > >> in all the xml/xsl docs pointless? > >> > >> > In case anyone is curious... http://today.icantfocus.com/ > >> > It's not much yet, but it's built entirely in AxKit. > >> > > >> > -=Chris > >> > >> --------------------------------------------------------------------- > >> 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]
