Programmatically creating readable internal names for new SharePoint fields

This post was most recently updated on September 30th, 2022.

3 min read.

This post is about a small programmatic workaround to creating new SPFields for SPLists in SharePoint with human-readable internal names. This is mainly a usability improvement for your editors (and doesn’t change your life that much), but they should appreciate it at the very least!

In short, I’ll show you how to avoid SharePoint’s dirty encoding (like replacing a space with “_x0020_”). This applies when you’re using server-side code to generate fields.

Problem: non-readable internal names for SharePoint list fields

Table of Contents

When you create a new field in SharePoint, SharePoint accepts the following syntax:

string internalName = list.Fields.Add("Field name - in a readable way.", SPFieldType.Text, false);

However, this will result in the internal name to be something like “Field_x0020_name_x0020__x002d__x“. That’s not super readable, but rather quite horrible to look at, or use anywhere at all. It mostly consists of dirtily encoded characters, automatically generated by SharePoint.

The issue is even worse if you use some non-Latin character set. Kanji or Katakana – or even just scandic characters – will produce quite a mess.

The worst part is that all of this actually doesn’t only mess up the internal names of fields created programmatically. Also when creating fields using the SharePoint GUI, you get the same kind of malformed internal names.

These horrible internal names will haunt you in all reports, when doing things programmatically, using CAML, or configuring things. Not good! Not fun.

Luckily, there’s a nice and straightforward way to solve this issue and produce nice and readable internal names for SharePoint list fields!

SharePoint List Field Name creation dialog - the internal names for created fields are generated from the display name, and often end up being quite messy! — SharePoint List Field Name creation dialog – the internal names for created fields are generated from the display name, and often end up being quite messy!

Solution

If you need to get readable internal names (like when your editors actually use the internal names for something) for your fields, you can use a code similar to this:

// This row only simulates the field name, that in this case was in reality supplied by an editor-level end-user.
string userInput = "Field name - in a readable way.";

Regex rgx = new Regex("[^a-z0-9_ ]");
// we are truncating the user input, because who knows who long text they could input? 
// The name of the field will be truncated in any case! 
// Regex will also be slightly faster for a shorter text.
int maxLength = 32; 
TextInfo textInfo = new CultureInfo("en-US", false).TextInfo;

// Here we'll change a few culture-spesific characters to a more readable form, before we strip any unwanted ones from the 
// these you'll need to figure out yourself, because they depend on your localization and preferences!
string simpleName =
   userInput.Substring(0, userInput.Length > maxLength ? maxLength : userInput.Length).ToLowerInvariant()
                .Replace('ä', 'a')
                .Replace('ö', 'o')
                .Replace('å', 'o')
                .Replace(' ', '_');
simpleName = textInfo.ToTitleCase(rgx.Replace(simpleName, ""));

// create the field
string internalName = secHtrList.Fields.Add(simpleName, SPFieldType.Text, false);
SPField field = secHtrList.Fields.GetFieldByInternalName(internalName);

// update field
field.Title = userInput; // set the "displayname" back to original
field.Update();

That’s it! This code will leave the field’s title, and therefore the display name, to the actual user input, whereas the internal name will be something like “Field_Name_In_A_Readable_Way“. This should please at least some editors… :) In any case, it’s way better, than the mangled version (shown first) which consisted mostly of “_x0020_” or similar word vomit.

Now, there may be numerous scenarios, where the display name (or to be more precise, the schema of the field) might not update despite you changing the title programmatically. It’s kind of a trainwreck, really! But we’ll have to cover those in another blog entry.

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)