Hacker News Reader

Comment by grey-area | Hacker News Reader

The answer is to allow a single unicode text column for names, and don't try to validate it.

That's not very hard, and is in fact easier than trying to validate or restrict names. You don't have to learn about all the different cultures etc, just don't assume they are like yours.

View on HN

Then what if someone starts putting in unicode control characters? What if you display their name as the title of a window and they made their name start with two right to left control marks, causing Windows to invert the entire window contents?

For specific uses (like output to html), you will have to escape the content, as with any other content, but you can store what the user input.

names are no different from any other form of user input in this regard. Any time you include user input in a document you should follow it with a direction override character to restore the text direction, just in case the user changed it. You could also strip these characters out, but some people really do want their name to show up backwards, and for that to be consistent across all cases.

What if you need to call out to a third party API like a payment system which requires a first name and a surname? If you've not collected those things, you're screwed.

Billing names are a separate problem from user names. If you're collecting for payment, obviously you have to conform to whatever your API requires, but often it's better to keep billing details separately.

Sorting is another area where it'll vary a lot depending on locale (perhaps you want to sort on last name for example, or not depending on your users) - it might be best to try to guess that from whatever they enter, rather than imposing a structure on them.

Personally I'd choose the simplest solution which works, so no last name/first name, just a name field for display, depending on the requirements, a website/app might need to collect more of course, but for most websites there's no reason to try to control user names or split them up into arbitrary first/last pairs.

What if their name uses non-unicode characters?

And 2048-character limit on that field ought to be enough for everyone, right?

Are there significant symbologies not contained within unicode?

Maybe Jimmy Page will change his legal name to Zoso? http://en.wikipedia.org/wiki/Jimmy_page#Interest_in_the_occu...

But that's exactly the issue here; there aren't many people with names as long as Janice's, but when these people have problems with computer systems, we get to hear about it.

What is a "non-unicode character"?

Why do you need a fixed character limit at all?

I don't know about your first question, but the reason you need a character limit is because each time a row is added to a database, enough space is set aside to contain that row.

Each row contains the same columns. For example: table Person: col1 label: name / type: text / size: 10 2 label: age / type: int / size: 3 3 label: address / type: text / size: 200

the type tells the database how to encode the data found in that column - an int takes less space than a string, so this is a space saving measure. The size refers to how many characters are allowed in that field, because that is how much space will be allocated when the row is created. If you don't need 200 characters of space, it's wasteful to allow it. But you kind of have to put a number in there, even if it's a big one.

Correct me if I'm wrong, all my knowledge comes from Dr. Marla Weston's 2nd year Databases Design course.

Not all databases store varchar differently from a text column, for example I don't think PSQL distinguishes between the two in storage and there are no performances improvements from using varchar.

http://www.postgresql.org/docs/9.3/interactive/datatype-char...

A very poor course indeed if it told you to use fixed-size data types for arbitrary string data, or implied all string types in databases were fixed-size. SQL string types like VARCHAR and TEXT are assuredly variable, using only the storage necessary to hold the actual data (plus bookkeeping overhead). CHAR is fixed-size, but I can't remember the last table I created with a CHAR column. They're quite uncommon in comparison.

> What is a "non-unicode character"?

A character with no representation in the latest Unicode standard.

> What if their name uses non-unicode characters?

Learn to fix the problems you can fix, and only the problems you can fix. Ignore the problems you cannot fix because, as per hypothesis, you cannot do anything about them.

In other words, what if you get hit by a micrometeorite on your way to the bathroom tomorrow?

Even that will fail at least point #11, and possibly point #39.

I'm not sure there's anything we can do about point #11 - do do you have a suggestion without fixing unicode? Like a few of the last points it's not possible to satisfy every possible problem, but using unicode without restrictions at least gets you most of the way there, it's better than other encodings if you need worldwide support though it has recognised issues with more complex character sets.

Reply on news.ycombinator.com