Re: [xsl] IE error | Switch from current encoding to specified encoding not supported.
Subject: Re: [xsl] IE error | Switch from current encoding to specified encoding not supported.|
From: Nick Fitzsimons <nick@xxxxxxxxxxxxxx>
Date: Wed, 3 Oct 2007 18:51:35 +0100
On 3 Oct 2007, at 16:53, Steve wrote:
I'm confused by this error I am receiving in IE. I've never
encountered anything like it and I'm confused as to why the below
template would trigger such an error.
Strangely, the stylesheet begins with:
<?xml version='1.0' encoding="UTF-8"?>
not UTF-16 as in the error.
Switch from current encoding to specified encoding not supported.
Error processing resource 'https://server.org/private...
<?xml version="1.0" encoding="UTF-16"?><i>Not logged in</i>
This UTF-16 thing bit me few years go, and IIRC the problem is going
to be in your ASP code, not your XSLT or XML.
Would I be correct in believing that you are following the sequence of:
transform XML to result_DOMDocument;
write result_DOMDocument.xml to the Response stream?
If so, the problem is (IIRC) that, although the transformation will
correctly result in a UTF-8 document, extracting the XML from that
document as a string will get a UTF-16 string because that's the
internal default charset used by Win32. This is almost sort-of
mentioned at <http://msdn2.microsoft.com/en-us/library/ms755989.aspx>
but in such a confusing way as to be almost indecipherable: "The xml
property always returns a Unicode string", by which they mean UTF-16.
If you use the transformNodeToObject method, with the ASP Response
stream as the target object, then you will sidestep that pitfall and
should receive UTF-8 at the browser:
e.g. (in VBScript)
(Note: I don't have a Windows machine to hand to check this, so this
is based on memories from a couple of years ago. However, if I'm
correct and this solves your problem, you will get the added benefit
that this approach is much more efficient and thus more scalable than
transforming to a document and then serialising that.)