>I'm not sure at which level the conversion happens to you. What I've done is this. On my web server I've created a very simple AFP page:
>
>

>< % ERROR: 
>response.ContentType = "text/xml"
>lcXML = '<?xml version="1.0" encoding="utf-8" ?>'+Chr(13)+Chr(10)+'<root><data>éeAc</data></root>"'
>lcXML = Strconv(Strconv(lcXML,1),9)
>? lcXML
> % >
>

>
>On the client I run this code:
>
>

>loHTTP.Open('GET',"http://localhost/utf8.afp",.F.)
>loHTTP.Send()
>? loHTTP.ResponseBody
>? Strconv(loHTTP.ResponseBody,11)
>

>
>The first line prints an UTF-8 encoded string, the second line correctly contains the string as I've sent it including the accented "é". IOW, for me it works. There must be some additional encoding going on on your site.

Well, here's something that is really weird.

From the command prompt, doing the following:

loHTTP=CREATEOBJECT('MSXML2.ServerXMLHTTP')
loHTTP.Open('GET',lcUrl,.F.)
loHTTP.Send()
RETURN STRCONV(loHTTP.responseText,9)

works.

However, the same lines within the Web Service generates an error on STRCONV(). This is really weird. From the Web Service environment, something seems to makes the conversion to react differently. This is where the problem is. Basically, the problem is not in the URL I am calling as manually from the command prompt it works. So, when doing more tests, I discovered that it's only when it is called from the Web Service that it cannot process to STRCONV() line. Do you have an idea what could affect the environment to cause such a behavior?