-
What kind of idiot uses varchar instead of nvarchar (i.e UTF16) for place names?
-
it's not a massive ask to change these characters to something less problematic on submission
What, automatically, and thus store a different password from what the user supplied?
I was thinking for a moment that you were saying the user should just retype without those 'problematic' characters...
-
The fail could be at any of the many layers of the stack, from stupid restriction by front-end designer on down. I worked on an early PaaS system where the terribly clever logging framework failed on non-Latin characters, unlike every other part of the system. Since they'd been extra clever, failure of the logging component broke the system (real talent, there).
that said, it's not a massive ask to change these characters to something less problematic on submission.
In the case, as here, of a city name in an app explicitly designed for non-UK citizens, you'd expect that to be being stored plain-text in a database. If the database schema didn't allow for UTF here, the designers are morons. This is a data driven app and the bounds of that data should be communicated all the way up the stack. There shouldn't be anything problematic about non-Latin characters going straight all the way back down the stack, either.
Edit: Yes, this one shouldn't be stored, doh. But since they will have to be processing lots of non-latin character set data for the applicants anyway, any Latin-only restrictions are pants.
You are reading a single comment by @deleted and its replies.
Click here to read the full conversation.
Emyr
chez_jay
itsbruce
@deleted
More often than not, these sort of things are thrown up because the back end system the form is writing to only accepts certain characters, that said, it's not a massive ask to change these characters to something less problematic on submission.