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

Escaping Special Characters in UpdateListItems

Jul 7, 2011 at 10:32 PM
Edited Jul 7, 2011 at 11:24 PM

I use UpdateListItems pretty regularly, and I'm often trying to update a field with user input.  This leads to a failure when the user input field contains an ampersand or other XML special characters.  Do you think you could add a replace statement to escape these special characters similar to the following (edit: for string type fields)?

I was able to temporarily solve this issue with modifying the follow line:


SOAPEnvelope.payload += "<Field Name='" + opt.valuepairs[i][0] + "'>" + opt.valuepairs[i][1] + "</Field>";


to this:


SOAPEnvelope.payload += "<Field Name='" + opt.valuepairs[i][0] + "'>" + opt.valuepairs[i][1].replace(/&/g,"&amp;").replace(/</g,"&lt;") + "</Field>";



What do you think?

Oh, and thanks for the countless hours saved with this library.  Amazing work.

Jul 8, 2011 at 3:32 AM

I implemented basically what you're looking for in v0.6.2. See Let me know if this doesn't fully cover what you want.

And you're welcome!


Jul 8, 2011 at 3:58 AM

What will this fix do, if you are already using a function to escape the characters, like STSHtmlEncode?  I haven't used the latest version heavily, but I'm thinking an upgrade would cause problems with some of

our larger scripts.  You may need yet ANOTHER disclaimer on this site Marc that no one else reads. :P

As always, Marc you are the best...


Jul 8, 2011 at 4:03 AM

My change in v0.6.2 shouldn't hurt any values which are already encoded (or else it's a bug). The regex checks for things which *aren't* already encoded but need to be and encodes them. It's not just a blind encoding.

Thanks go to thestevo for handing over the regex; as you know, I abhor regex. I like what it does for me, but I really don't like writing it.


Jul 8, 2011 at 3:27 PM

Sorry I didn't search hard enough to find that thread.   I still think this solution misses the < character, which causes the same failure.  I've found a more elegant way (imo) to solve this issue by using the following check:

if(typeof(opt.valuepairs[i][1]) == 'string'){
	opt.valuepairs[i][1] = "<![CDATA["+opt.valuepairs[i][1]+"]]>";
} (from what I can tell, the & and < symbols are the only two that will cause the issue).

This of course will be an issue for those already using a function to escape like mentioned above, so maybe best to leave it the way it is...  But at least I got rid of the regex :)