Re: [xsl] Problem with rendering of &#160

[Mike Trotman <mike.trotman@xxxxxxxxxxxxx>]

I have a similar (and maybe related) problem.

I am using a Perl CGI script on an IIS server with ADO and MSXML.
I perform a query on a (currently MS Access) database containing 'memo' 
fields.
when I try to persist the query result into XML

   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

I get an error as the XML is not well formed - containing illegal 
characters from the 'memo' field
(one of the ones I found was rendered as a bullet 'blob' in MS Access).

I had (optimistically) expected the ADO persistence to do any character 
conversion necessary to create a legal XML document.

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

Any help greatly appreciated.


Passin, Tom wrote:

> > 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