Comment by pyre | Hacker News Reader

Comment by pyre | Hacker News Reader

Parent Full thread

What about when your program/service is something where identity matters, like for a credit bureau, a government agency or even a retailer?

Just read the complaints here about airliners screwing up people's names by assuming that everything is ASCII/LATIN1/MISC_CHARSET. That makes a difference when you get to the airport and they won't let you on the plane because your ticket and your id don't match.

It's also an easily solvable problem. Just include a 'name' field. Make sure that it's sanitized correctly and supports UTF-8 (make sure that your database is properly set up to use UTF-8 as well, or else all manner of problems can happen, least of all queries will get bogged down as the database does charset conversions for string comparisons). If you care so little about the user's name, then why bother to have separate firstname/lastname fields?

{edit} With respect to the 'other complaints,' I was referring to the comments on this story: http://news.ycombinator.com/item?id=1438355 (The story which is what Patrick's post was in response to).

Just read the complaints here about airliners screwing up people's names by assuming that everything is ASCII/LATIN1/MISC_CHARSET.

Having worked in the airline industry, I can tell you, this is not a case of airlines making a poor assumption. Airline systems are generally incapable of dealing with ASCII, let alone Unicode text. They typically use EBCDIC. That's why you never see lower case characters in your name on a boarding pass.

That makes a difference when you get to the airport and they won't let you on the plane because your ticket and your id don't match.

Does this actually happen? Because given the fact that airlines have been incapable of printing names that don't can't be described by EBCDIC since, well, forever, I'd assume that they're willing to ignore cases where the name on your ID contains characters that their computer system literally cannot represent.

> Does this actually happen? Because given the fact that airlines have been incapable of printing names that don't can't be described by EBCDIC since, well, forever, I'd assume that they're willing to ignore cases where the name on your ID contains characters that their computer system literally cannot represent.

Do the screeners know to this? I'm willing to bet that a screener would deny you based on a name mis-match. What do the screeners know of EBCDIC?

There are two classes of people who can deny you access to aircraft: (1) airline employees (gate agents, check in agents) and (2) TSA inspectors. No one at an airport will know anything about EBCDIC, but every single airline employee will know about the fact that they're crappy mainframe system isn't smart enough to handle uppercase characters, let alone spaces, hyphens, umlauts, accents, etc.

As for TSA staff, it is important to realize that this EBCDIC issue is not a problem that only affects one airline: it affects almost every single airline, including all flag carriers that I know of. The airlines have a pretty tight working relationship with TSA; note that they send electronic messages to the TSA describing their customers when people book tickets and just before departure so as to give the TSA the opportunity to prevent them from flying. Given that tight relationship, I'm pretty sure that the TSA knows a great deal about the limitations of EBCDIC and has informed their staff about the limits of what a boarding pass name field can possibly represent.

Keep in mind that screeners will let you fly even if you have no ID on you.

Well said.

Anecdotally, I've never had issues with tickets that had my partial name on them in the past either ("Matt" vs. "Matthew") although this may have changed now that TSA requires full names and birthdays (I always use my full name now).

For what it's worth, I've been allowed on planes with misspelled tickets (multiple times).

A travel agent I asked about it once told that if the names match 80% or more of the character they assume a typo was made.

Reply on news.ycombinator.com