The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
As a main rule, I write software to handle any name etc. in two forms: One "internal", technical, which may be restricted in use of encoding, special characters including space, lenght etc. This is the true identifier for an object, or whatever.
The other is an arbitrary length "User friendly" name which may contain arbitrary characters, and it may even be replaced with another name depending on the UI language; it is used in all user dialogs.
The "disadvantage" is that the application code very much leaves this name to be controlled by the user. So e.g. uniqueness cannot be guaranteed. Sure, the code could have refused to accept a duplicate name, but that would restrict the UI naming. (UI names can originate from different sources, so who has "the highest right" to use a given name?) In an interactive UI both matches can be presented, with additional metadata for the user to select.
For non-interactive applications, I always make a fallback to the internal name (which is not at all "secret"), so that batch files / scripts may uniquely identify an object no matter what the user friendly names are. (But for that reason, some resemblance with the user friendly name turns out to be "user friendly" )
This is very much in the style of database identification of tuples: Selection may be based on one or more user specified values, or on some tuple ID defined as a primary key if no (combination of) user attributes are suitable.
I have followed this naming philosophy, with a restricted syntax "internal" name and a free syntax "external" name for a handful systems, and I am so satisfied with it that I will continue to do it that way in future projects whenever it fits in among other requirements.