Thanks - that's very useful.

And I had missed the Unicode mode in the Win32::OLE documentation.

To clarify:

Part of my problem is that the MSXML XSLT transformations do NOT output the character encoding in the XML declaration.
So - $xmldoc->transformNode($xsltsheet) may output Windows-1252 encoded data - but does not contain encoding='Windows-1252' in the <!? xml version='1.0'?>
and so other parts of the process expect it to contain UTF-8.

If I turn on the Win32::OLE UTF8 code page for a Win32::OLE call to MSXML that returns a UTF-16 string (or Windows-1252)
- is the automatic conversion to UTF8 likely to be correct - or incorrect?
IE - does the automatic conversion correctly detect the CP of the OLE output?

Thanks

Jan Dubois wrote:
On Fri, 27 Apr 2007, Mike Trotman wrote:
  
I am writing a CGI application that uses WIN32::OLE to interface to
Microsoft ADO, MS Access, SQL Server and MSXML for XML documents and
XSLT transformations.

I suspect that something in the way I am passing data around (or in
the ADO implementation of 'savetoxml') is not dealing correctly with
XML document encoding declarations. The data is originally in an MS
Access database - but has been entered using copy and paste from MS
Word documents from around the world - so contains many weird and
wonderful bytes.

To help in my debugging process can anyone tell me how WIN32::OLE
deals with 'strings' returned from method calls? i.e.
- are they pure byte data as output by the method (and maybe in UTF-16)?
- or are they converted to Perl's internal format (using any current
  Perl encoding settings)?
- or does something else happen?

The problems I am having are primarily when outputting XML documents
(or HTML) to send to the browser.
e.g.my $OUTPUT=""; $OUTPUT=$xmldoc->transformNode($xsltsheet);

print $OUTPUT;
    

All string data is converted to the current system codepage by
Win32::OLE before being passed back to Perl _unless_ you switch
Win32::OLE to Unicode mode first:

    Win32::OLE->Option(CP => Win32::OLE::CP_UTF8());

After this call all strings are converted to UTF8 and marked as
such in the Perl internal flags.

Cheers,
-Jan


Message Scanned by ClamAV on datalucid.com

  

-- 
Datalucid Limited
8 Eileen Road
South Norwood
London SE25 5EJ

tel :+44-0208-239-6810

email: [EMAIL PROTECTED]
web: http://www.datalucid.com
Message Scanned by ClamAV on datalucid.com
_______________________________________________
Perl-Win32-Users mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reply via email to