This project has moved and is read-only. For the latest updates, please go here.

Encoding (how to change it?)

May 24, 2011 at 4:45 PM

Hello again,


Trying various things with the various possibilities, I went into a problem:

Being frensh, the project I am working on has some é, è à and ù chars, but it seems to be a problem in between when I call and when the server recieve it:

<soap:Envelope xmlns:xsi="" xmlns:xsd="" xmlns:soap="" encoding="UTF-16">
<GetList xmlns="">
<listName>Indicateurs qualit&#65533;</listName>

Obviously, é is not char 65533, so it doesn't recognize it and pushes me an error.

I tried the escape function, doesn't work either, and putting "encoding='UTF-16'" in your soap envelope doesn't seem to help either.

Do you have any idea on how I could possibly make it work?

May 24, 2011 at 6:16 PM
Edited May 24, 2011 at 10:03 PM

Because I don't have a French instance, I can't test anything with it.

From the looks of it, though, this may be an issue with the Web Service itself, and not SPServices per se. I just pass the values you provide through to the Web Service and back again, taking care of the SOAP wrappers and such for you.

On the other hand, if you aren't getting anything back, I may not be encoding properly. Where does the error occur, and can you provide the text?

In the short term, you can use the list's GUID instead.


May 25, 2011 at 7:38 AM
Edited May 25, 2011 at 7:51 AM

What I posted was what the script sends to the server, but if you think it can help, here is the answer from the server:


<soap:Envelope xmlns:soap="" xmlns:xsi="" xmlns:xsd="">
<faultstring>Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.</faultstring>
<errorstring xmlns="">Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).</errorstring>

it is the same error when I put the name of a list that doesn't exists by the way, so the real error is that it can't find the right list (sure thing when it searches for a symbol that is not the right one)


Edit: On a side note, I didn't even think I could put the ID as the object we put it in is called listName, but it works well, so I think I will use this instead, thank.

May 25, 2011 at 2:15 PM

I'm glad the the list GUID is solving your immediate issue, but I'd still like to try to figure out where the problem lies in case it's something I can fix. Can you please post the call to GetList from your code? That way I can at least see if the right characters are getting through to the Web Service.


May 25, 2011 at 2:22 PM

		operation: "GetListItems",
		listName: "Priv�e",
		completefunc: function (xData, Status) {

oh, right, your encoding here doesn't like frensh either^^

it's "Privée"

May 25, 2011 at 2:29 PM

Darn Microsoft. :-)

I'll see if I can come up for a fix for you to try. UTF-8 characters ought to work with the Web Services, and therefore with SPServices.


May 25, 2011 at 4:43 PM

Interesting. I just created a list named Privée and this script works fine:

<script language="javascript" type="text/javascript" src="jQuery%20Libraries/jquery-1.5.min.js"></script>
<script language="javascript" type="text/javascript" src="jQuery%20Libraries/jquery.SPServices-0.6.1.min.js"></script>
<script language="javascript" type="text/javascript">
  $(document).ready(function() {
      operation: "GetListItems",
      async: false,
      listName: "Privée",
      completefunc: function (xData, Status) {
        $(xData.responseXML).find("[nodeName='z:row']").each(function() {
          var liHtml = "<li>" + $(this).attr("ows_Title") + "</li>";
<ul id="testUL"/>

I wonder what else could be causing the issue?


May 25, 2011 at 5:16 PM

No idea, but after tweaking a few things and not being able to make it work, I just used ID, which is just fine too as I always have my list ID near too (not input by an user, but rather hard coded or through a button/link)

Anyway, thank you for having looked into it, maybe the problem is related with my computer/browser (surely is) seeing you managed to make it work.

May 25, 2011 at 5:20 PM

Let me know if you have any other problems. I can't test with other languages (too many!), so unfortunately I end up just reacting to issues.


May 26, 2011 at 10:32 AM

Ok, then let's go with the next encoding one^^

I am trying to create/delete lists for a script that would create various things at Web creation, but it sounds like I have one of the encoding problems again:

createList = function(listname) {

			operation: "AddList",
			listName: listname,			
			completefunc: function(xData, Status){
				alert("creation: "+Status);

As you see, it is quite a common function, but it fails, and on the message from the server, it tells me it finds a


so I assumed it was in place of one of the > symbols.

Not knowing where it was, I wanted to test the function a little more, and found it was after the content for the templateID (and sounds like it is the closing of this one too).
As the other functions doesn't seem to have these problems and I don't find a clue on how it is possible, I wanted to ask.

Here is what is sent (fiddler got it for me):
<soap:Envelope xmlns:xsi='' xmlns:xsd='' xmlns:soap=''><soap:Body><AddList xmlns=''><listName>add</listName><description></description><templateID></templateID></AddList></soap:Body></soap:Envelope>

And the response was:

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="" xmlns:xsi="" xmlns:xsd=""><soap:Body><soap:Fault><faultcode>soap:Client</faultcode><faultstring>Server was unable to read request. ---&gt; There is an error in XML document (1, 322). ---&gt; Input string was not in a correct format.</faultstring><detail /></soap:Fault></soap:Body></soap:Envelope>

322 seems to be after the closing of templateID, but before any other closing ones.

Also, I am positive it can not be before, as adding a templateID of 3 chars makes the error goes up by 3 chars too.


Thank to you for answering all my questions so far, it helped to understand a little more.



May 26, 2011 at 4:02 PM

As an update for the encoding of the first part, it apears that I required to add


in my JS inclusion, it pretty much fixed it for other accents, so I assume it would do it too for my initial problem.

I thought it might help to know, so I post it.

May 27, 2011 at 4:49 AM

I checked with v0.6.1 in my environment, and AddList works for me. Did your listName above also contain UTF-8 characters? If so, did adding lang="fr-fr" (I wouldn't have thought of that!) solve the issue?


May 27, 2011 at 8:10 AM

No, the AddList is the only one I didn't manage to solve, and for list name I put "test" so that I don't have any problem (I hopped so, at least)

It is strange to me that only one > has a problem on all I used when it is addeed exactly the same way as the others.

May 27, 2011 at 10:57 AM

Just found out what was going wrong, or what I was doing wrong.

You NEED the template ID, as opposed to nearly everything else you don't need.

Maybe you should put the default to 100 so that it doesn't send back a strange error that makes you think it is a format error.

Anyway, problem solved, just took me some time to actually realise I was not doing it right.

May 27, 2011 at 12:20 PM

Great. Yes, the templateId is required.

When you use the Web Services, you'll always need to go by the MSDN SDK documentation. It's not always clear or sensical (and sometimes it's actually wrong!) but it is what it is.

*Generally* speaking, if the SDK doesn't say a parameter is optional, then it's required.


May 27, 2011 at 1:18 PM
Edited May 27, 2011 at 1:19 PM

Yes, but when I saw it was required, I was puttig the GUID of the template I wanted, and the error didn't change.

Damn Microsoft, giving "ID" multiple meaning in a single application (the templates do have an ID that is a GUID)


Oh, well, I guess that I must read all docs before even giving it a try now.

Again, thank you so much for your solution and your help on using it, you saved me big troubles of having to code all of this myself just for some basic uses.

May 27, 2011 at 1:21 PM

Yeah, the docs can drive you nuts, but the inconsistencies from operation to operation and across Web Services will truly put you over the edge.

I've been trying to find people at Microsoft to work with on improvements, but...