This is very unhappy topic <g>...

This all has to do with XML Encoding and UTF-8 and how COM handles this data. Unfortunately, VFP cannot handle Unicode data natively so we need to convert back and forth every time. When you load an XML string (ANSI) into an XML parser it will work correctly if it's in ANSI format, but will fail if it's in UTF-8 format. The browser on the other hand will fail with extended characters that are not in UTF-8 format.

In other words there's no way to serve the data in a single format and have it work both ways. There is one thing you can do to work around this. You can use STRCONV() to convert the XML string into UTF-8 if you want to display it in the browser or save it to disk.

However, on the server side you have a dilemma on how to serve that data. If you decide to serve in UTF-8 (CURSORTOXML() supports this natively) COM clients like MSXML will fail. I think that's more important than the data displaying in the browser. Problem is that some other XML clients not using COM or from a totally different platform may also fail on the XML. Once the data is in the parser it won't matter since the parser handles the encoding fixup, but getting it there is the problem.

So, to make a sad story short <g> - it will work correctly with MSXML and MSOAP - if you need to get it elsewhere you need to use STRCONV (or wwXML.EncodeXML in VFP 6 and with large strings) to fix up the string.