|
Summary
...and the answer to why it sometimes appears that MSXML completely ignores the
This is an FAQ, asked in many newsgroups and discussions lists on almost a weekly (if not daily) basis...
In an ASP page using MSXML (3 or 4) the transformation result is returned as UTF-16 despite the fact that a <xsl:output encoding=.../> has been specified in the stylesheet. This is invariably down to the use of the .transformNode() method being used, e.g.
Response.write(MyDom.transformNode(MyXSLDOM))
The problem with using the .transformNode() is that the model for this method is that it returns a BSTR. And a BSTR must, by its nature, be encoded as UTF-16. This is why MSXML ignores the <xsl:output encoding=.../> and always returns HTML/XML that is encoded as UTF-16 and says that it is encoded as such (either with an XML declaration or by placing a content=text/html; charset=UTF-16 in the HTML header). So it is very much a case of a square peg into a round hole - if .transformNode() returns UTF-16 (a BSTR) you cannot place another encoding into this return string.
The solution is to avoid using the .transformNode() method altogether. Instead it is better to use the .TransformNodeToObject() method - which can be used to write the transformation result directly out to a 'stream' (and a stream can be encoded in any way), e.g.
MyDom.transformNodeToObject(MyXSLDOM,Response)
The result of the transformation is then written to the ASP response object.
The other alternative is to use the IXSLTemplate and IXSLProcessor interfaces of MSXML (see your MSXML SDK for more info). The IXSLProcessor interface can also have it's .output property assigned as an object (that supports the IStream .write method - which the ASP Response object supports) prior to executing the .transform() method. The transformation result of the IXSLProcessor is then written directly out to that stream.
Cheers - Marrow
| Further additional information | |
Updating comments...
Updating comments...
|
