This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Problem with Chinese (Solution)
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] Problem with Chinese (Solution)
- From: "Julian Reschke" <julian dot reschke at gmx dot de>
- Date: Wed, 8 Aug 2001 09:44:40 +0200
- Reply-To: xsl-list at lists dot mulberrytech dot com
> From: owner-xsl-list@lists.mulberrytech.com
> [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of Michael
> Beddow
> Sent: Wednesday, August 08, 2001 9:37 AM
> To: xsl-list@lists.mulberrytech.com
> Subject: Re: [xsl] Problem with Chinese (Solution)
>
> ...
>
> > However !!! I did notice one interesting undesirable "feature" in the
> > MSXML. If you put in some <HEAD></HEAD> tags into the
> > above XSL, then your output HTML contains the following by
> > magic.
> >
> > <head>
> > <META http-equiv="Content-Type" content="text/html; charset=UTF-16">
> > </head>
>
> ISTR that this has been touched on here before, but since I'm not an
> intensive MSXML user I can't be sure. Rogue reversions to UTF-16 did
> occur with some earlier MS xml handling, but I thought that was now
> fixed. Do you still get this if you specify the correct output encoding
> attribute in an xsl:output element in your XSL? If so, what happens if
> you also explicitly generate an HTML HEAD that includes a META tag with
> the correct charset declaration? Does this still produce a charset value
> of UTF-16? If so, that would indeed be a bug, though I'm not convinced
> that the behaviour as you've described it is one.
This is documented (and intended) behaviour of MSXML3/4. If you obtain the result of the transformation as a COM string, it will - by definition - be encoded as UTF-16, and this is why MSXML correctly "fixes" the HTML charset declaration. If, for instance, the transformation result is written directly to a stream, MSXML will use the information from xsl:output.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list