Re: Problem with rendering of &#160

   610 my $xml_tmp=Win32::OLE->new($MSXML);
   611 $xml_tmp->{async}=0;
   612 $xml_tmp->{validateOnParse}=$validate;
   613 $xml_tmp->setproperty('SelectionLanguage','XPath');
   614 $xml_tmp->setproperty('SelectionNamespaces',
   615 'xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"
   616 xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
   617 xmlns:rs="urn:schemas-microsoft-com:rowset"
   618 xmlns:z="#RowsetSchema"');
<snip/>.....
   714 $rs->Save($xml_tmp,1)   # 1 => adPersistADO

Is this likely to be a similar default encoding problem
and could I fix this by specifying an encoding on my target XML object?

From: Richard.McMillian@xxxxxxxx [mailto:Richard.McMillian@xxxxxxxx]

This thread addressed the problem back in 2002. Has anyone come across a better solution?

http://www.biglist.com/lists/xsl-list/archives/200211/msg00172.html

Sure, Julian Reschke posted it earlier today.  The MS component always
generates utf-16 when you use it to create strings instead of objects.
Thus there ends up being a mismatch between the declared encoding and
the actual encoding.

This is pretty much a FAQ by now, but until you posted your code no one
could tell what you were invoking the problem.

The solution is not to futz around with the meta element and trying to
trick the browser, but the generate the output using objects instead of
strings.

Once the encoding discrepancy is fixed, the presence of the meta element
will not cause any problems and could even be beneficial (as when the
document is loaded from a file, and thus has no headers to state the
encoding).

Cheers,

Tom P

--
Datalucid Limited
8 Eileen Road
South Norwood
London SE25 5EJ
/ tel :0208-239-6810
mob: 0794-725-9760
email: mike.trotman@xxxxxxxxxxxxx
/
UK Co. Reg:   	4383635
VAT Reg.:   	798 7531 60