Wiki Page name cannot contain special characters when created using UI, but can contain special charterers when created using code

Question

I am facing this strange problem inside my enterprise wiki site collection inside sharepoint enterprise server 2013.

now when i try to create a new wiki page using the UI , and i enter some special characters such as & or * inside the Name field, i will get the following error :-

Page name cannot contain any of the following characters: " # % & * : < > ? \ / { } ~ |

as follow:-

but i have an event receiver where i am programmatically creating wiki pages inside the same site collection and the same library. and inside the event receiver i am able to create wiki page which contain special characters inside their wiki page name , here is the code i am using to create wiki pages:-

PublishingSite pSite = new PublishingSite(properties.Site);
SPContentType ctype = pSite.ContentTypes["Enterprise Wiki Page"];
PageLayoutCollection pageLayouts = pSite.GetPageLayouts(ctype, true);
PageLayout pageLayout = pageLayouts["EnterpriseWiki.aspx"];
PublishingWeb pWeb = PublishingWeb.GetPublishingWeb(properties.Web);

///First page
PublishingPageCollection pPages = pWeb.GetPublishingPages();
string itemTitle = properties.ListItem.Title.Trim();
PublishingPage pPage = pPages.Add(itemTitle + ".aspx", pageLayout);

and the generated URL for the wiki page will be as follow inside the browser (where the itemTitle variable will be "L & F"):-

/Pages/L%20＆%20F.aspx

here is a screen shot from my browser:-

so can anyone advice on this and where the problem is? i mean is it a limitation inside the UI which prevent us from adding some special characters inside the wiki pages names? or the problem is within the server side API which is not returning any error when the page name contain these special characters ? i am a bit confused on how i need to appraoch this? should i for example check the page name for these special characters before adding it inside my event receiver ?

Answer 1

There are differences between UI and API and more than one. I would go with the lowest common denominator so if something is forbidden in UI try not to change it (as general rule) and apply same restrictions on any automation you are implementing. With SP 2016 ampersand is no longer limitation so API may be a bit ahead.