What are all of the allowable characters for people's names?

Question

There are the standard A-Z, a-z characters, but also there are hyphens, em dashes, quotes, etc.

Plus, there are all of the international characters, like umlauts, etc.

So, for an English-based system, what's the complete set? What about sets for other languages? What about UTF8, UTF16, etc?

Bonus question: How many name fields are needed, and what are their maximum lengths?

EDIT: There are definitely two different types of characters involved in people's names, those that are there as part of the context, and those that are there for structural reasons. I don't want to limit or interfere with the context characters, but I do need to deal with the structural ones.

For example, I had a name come in that was separated by an em dash, but it was hard to distinguish that from the minus character. To make the system easier for searching, I want to take all five different types of dashes, and map them onto one unique character (minus), that way the searcher doesn't need to know specifically which symbol was initially entered.

The problem exists for dashes, probably quotes as well, but also how many other symbols?

Answer 1

There's good article by the W3C called Personal names around the world that explains the problems (and possible solutions) pretty well (it was originally a two-part blog post by Richard Ishida: part 1 and part 2)

Personally I'd say: support every printable Unicode-Character and to be safe provide just a single field "name" that contains the full, formatted name. This way you can store pretty much every form of name. You might need a more structured storage, but then don't expect to be able to store every single combination in a structured form, as there are simply too many different ones.

Answer 2

Whitelisting characters that could appear in a person's name is the wrong way to go, if you ask me. Sure, [A-Za-z] is a fair starting point, but, as you said, you get problems with "European" names. So you map all the umlauts, circumflexes and those. What about Chinese names? Japanese? Indian? Hebrew? You're entering a battle against wind turbines.

If you absolutely must check the validity of someone's name, I'd suggest doing a modest blacklist of certain characters. Braces, mathematical characters, some punctuation and such might be safe to ignore. But I'd be cautious, if I were you.

It might be best to just accept whatever comes in. UTF-16 should be today's overkill character set, that should be adequate for some years to come.

Edit: As for your question about name length and amount of names. If you really want people to write their real and complete names, I guess the only foolproof answer to both of those questions would be "infinite". Not being able to whip out any real examples for human beings, but surely there are analogous examples for humans as the native name for the city of Bangkok.

Answer 3

I don't think there's a definitive answer. After all, some people have names that can't even be expressed in UTF-16...

There are some odd people out there, who will give their kids the craziest of names, including putting in weird punctuation, accents that don't exist in their own language, etc.

However, you can place arbitrary restrictions on your database. If you want to you can insist on 7 bit ASCII names. It's slightly rude to users, but they'll live with it. It certainly makes searching easier.

My colleague's daughter is named Amélie. But even some (not all!) official British government web sites ("Please enter the name exactly as shown on the birth certificate") won't accept the unicode, so he has to use 'Amelie' instead.

Answer 4

Any character that can be represented by any multiple of eight bits (greater than zero) is a possible character for a person's name. Lengths of both names and encodings are arbitrary, so no upper bound should be considered.

Just make sure you sanitize your database inputs so little Bobby Drop-tables doesn't get ya.

Answer 5

I'm making software for driving schools in the USA, so to me what matters most what the state DMV's accept as a proper name on a driver's license. In my case, it would cause problems to allow names beyond what the DMV allows, even if such names were legal because the same name must later be used for a driver's license.

From StackOverflow, I still hadn't confirmed the answer I needed. And I happen to know that in my state (Calif) they're using AS400's with software probably written in COBOL, and to the best of my knowledge, those only support an 8-bit character set. (Is it EBCDIC?) Anyway... Ugh.

So, I called the California DMV... Sure enough, their system allows A-Z and spaces and absolutely nothing else. Not even hyphens are allowed -- Hyphens are replaced with spaces. In fact, apparently just to be difficult, they only use capitals. And names such as "O'Malley" must be replaced with OMALLEY.

Leave it to government. I must say I'm thrilled not to be a developer working for DMV. (Although I could really use that kind of salary.)

Answer 6

On the issue of name fields, the WRONG answer is first name, middle initial, last name, etc. for many reasons.

1. Many people are known by their middle name, and formally use a first initial, middle name, last name format.

2. In some cultures, the surname is the first name, and the given name is the last name.

3. Multiple first and/or middle given names is getting more common. As @Dour High Arch points out, the other extreme is people with only one word in their name.

In an object-oriented database, you would store a Name object with methods to return a directory-style or signature-style name; and the backing store would contain whatever data was necessary to support those methods.

I haven't yet seen a relational database model that improves on the model of two variable-length strings for directory-style and signature-style names.

Answer 7

It really depends on what the app is supposed to be used for.

Sure, in theory it's great if you allow every script on god's green earth to be used, but if the DB is also used by support staff, are they going to be able to handle names in Japanese, Hebrew and Thai script? Can you printer, if it's used to print postage labels?

You might add an extra field "Latin Transcription", but IMO it's really OK to restrict it to ISO-8859-1 characters - People who don't use Latin characters are by now so used to having to use a transcription that they don't mind it anymore, unless they're hardcore nationalists.

Answer 8

UTF-8 should be good enough, as far as name fields, you'll want at minimum a first name and last.

Answer 9

Depending on the complexity of your name structure I could see:

1. First Name
2. Middle Initial/Middle Name
3. Last Name
4. Suffix (Jr. Sr. II, III, IV, etc.)
5. Prefix (Mr., Mrs., Ms., etc.)

Answer 10

What do you do when you have "The Artist Formerly Known as Prince". That symbol he used is not a character in the unicode set (AFAIK).

It's some levity, but at the same time, names are a rather broad concept that doesn't lend itself well to a structured format. In this case, something free-form might be most appropriate.