It's pretty well publicised knowledge that _x0020_ replaces spaces in SharePoint internal field names. When working with SharePoint web services this can be a bit of a nightmare until you write a replace rule when comparing field names.

I've just found myself another one of these "encoding exceptions" in a field called SSL2. Bizarrely the internal name ends out being _x0053_SL2. I've tried something like RRL2 which comes out as _x0052_. From this it appears that the number used in the encoding represents the ASCII value of that character. Space would likewise be _x0020_.

My question is twofold:

In this case, whats causing SharePoint to encode these
characters.

Broadly, what sort of encoding is being done and is there a general
step I can do to decode strings
rather than replacing specific
occurances which I've come across
and know to be a problem.

This is an old question, but I wanted to understand the first part of this question and it wasn't answered so here goes...

Essentially SSL2 is being encoded to _x0053_SL2 because it resembles an "A1 mode" excel cell reference ([a-zA-Z]{1,3}[0-9]{1,5}). When Sharepoint sees one of those it decides it needs to encode the first character.

This is obviously not standard XML encoding, and I'm not going to posit any theories as to why this is done, but hopefully this at least explains what the OP observed.