Managed Metadata Labels and the Ampersand character

I am writing an application to import/generate a number of terms in a term set. I started to get some errors about my code trying to add terms that already exist – but it does check for the existence of terms with a given name.My Code and existence check

You can see that the string comparison for the name of the existing term and the term I want to get/create returns false, and that the terms seem to be different lengths. Well, I tried looking for blank spaces, non-printing characters, carriage returns, etc., and found nothing. Then I looked really closely at the ampersand characters shown in the debugger:

Strings in the Debugger

Yup, they’re different characters. You can see a slightly different shape to each of them – one is wider.

Fine. Let’s see the ASCII code for them:


Ah. There we go, one is Unicode – despite the fact that it went in as an ASCII ampersand (character 38). So how the hell does that happen?

Well, now I knew what to Google for, I found this post about the problem. It seems David was trying to do almost exactly the same as me, and hit the same problem. He found that SharePoint replaces the ASCII & with the Unicode one – but fortunately there’s a helper method to correct this – TaxonomyItem.NormalizeName() . It says:

The name will be normalized to trim consecutive spaces into one and replace the & character with the wide character version of the character (uFF06).

So, white space removal as well, as an added bonus. Okay, I can live with that.

And if anyone want to do this through the Client Side Object Model (CSOM):

ClientResult<string> normalized = Term.NormalizeName(clientContext, termName);
string normalizedTermName = normalized.Value;


EDIT: You might be interested in the update on how to do this without CSOM – it’s much faster –

Managed Metadata Labels and the Ampersand character

One thought on “Managed Metadata Labels and the Ampersand character

  1. I was working on a project last week and was having a different but related problem. I was trying to access local properties from a term that had an ampersand in the name and could not for my life get it to work without asking by GUID. This exact thing would have solved that problem as well. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.