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 at the very least they will probably appreciate it!
In short, I’ll show you how to avoid SharePoint’s dirty encoding (like replacing a space with “_x0020_”). This appliesto when you’re using server-side code to generate fields.
Problem: non-readable internal names for SharePoint list fields
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 actually 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 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!
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 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.
Latest posts by Antti K. Koskela (see all)
- How to fix an Office Group with no Owners - November 14, 2018
- Help! My “Content and Structure” page in SharePoint Online is gone! - November 7, 2018
- Thanks for coming to my session at SPS New England 10/20 ! - October 20, 2018
- Speaking at SPS New England on 10/20! - October 17, 2018