So I thought, how can this problem be solved? IMHO by doing a hex representation 0x00-0xFF per char. That would also increase entropy.
MySQL and other databases would need to support hex input of passwords, also setting of hex passwords via SQL.
81–90 of 233 posts
So I thought, how can this problem be solved? IMHO by doing a hex representation 0x00-0xFF per char. That would also increase entropy.
MySQL and other databases would need to support hex input of passwords, also setting of hex passwords via SQL.
You can print apostrophes on a street sign without any database issues because a street sign doesn't interface directly with a database. At least not yet... All the technical issues here have already been solved a hundred times, there's plenty of other options. It's a little worrying that we're eliminating punctuation in real life because of issues with integrating with geographical databases.
https://news.ycombinator.com/item?id=40265929
> As far as I can tell, this isn't an issue with the specific database itself, but the standard they are required to record geographic data in, which the end of the article mentions as "BS 7666".
On the other hand, you’re naïve if you think English hasn’t already been simplified to fit on machinery such as typewriters and cheap printing presses. This process began long before computers.
Looks like a much easier solution than having a couple people learn how to escape a string and prepare a sql statement.
My local (US) county has a web service to look up property deeds and titles. They "solved" this problem by just having you enter the street name with no punctuation or suffix (ave, st, etc), and if there is a collision the form pops out a drop-down selector to have you disambiguate. It's not the cleanest solution but it works. I agree that bending the humans to serve the needs of the machine feels... Sub-optimal.
USPS APIs in general:
https://www.usps.com/business/web-tools-apis/#dev
https://www.usps.com/business/web-tools-apis/documentation-u...
The specific API:
https://www.usps.com/business/web-tools-apis/address-informa...
This seems silly for the reason they're doing it, in that a modern database should be able to handle characters with a little sanitation. However, it does seem like it could be helpful when it comes to satnav applications to remove ambiguity. Google's going to autocorrect most of the time anyway, but this way, you're less likely to run into an issue where it takes you to Kings Landing in the wrong town because you di…
Earlier quoted context omitted.
I would argue if you sanitize your input you are already doing it wrong, you should parameterize queries and send the data entirely separately from code.
from a certain perspective, parameterization could be seen as sanitation, no?
Earlier quoted context omitted.
When a word ends with an s, the use of an apostrophe without another s is valid English. Thomas’ and Thomas’s are the same thing.
lol no. arguably the word ain't is more proper English than Chris' or boss'
However, it's English: there isn't just one rule, another rule can also be valid and might be the one you're familiar with on a day to day basis. That doesn't mean any other way to say or write the same thing is wrong, it's just a pattern you never saw. Like someone going "lol snuck isn't a real word, it's sneaked!" and then you hand them a dictionary and they learn something new about their own language.
[1] https://www.ox.ac.uk/sites/files/oxford/media_wysiwyg/Univer...
Just yesterday I generated a 64 char length mysql password, which had \ and ` and '. I couldn't properly escape it, to pass via argv, so I had to truncate it and remove all those symbols. So I thought, how can this problem be solved? IMHO by doing a hex representation 0x00-0xFF per char. That would also increase entropy. MySQL and other databases would need to support hex input of passwords, also setting of hex passw…
As if database were not able to del with apostrophes or other special characters... Yes you have to sanitize your queries, but you have to do it anyway. Client applications will of course have to be smarter
As someone with an apostrophe in my name, it has been my experience whenever I come across this sort of thing, you can be sure the project is crap.
That should break untold numbers of systems.
I have a street in a town near me which grammatically should be called St. Thomas' road. However, the street signs call it St. Thomas road at the north end and St. Thomas's road at the south end.
Thomas' is not grammatically correct in any version of English that I know. It's not plural. There is no special rule for that. Both the street signs you mentioned are at least grammatically coherent
Earlier quoted context omitted.
As always, the problem is always the underlying issue, even though the surface one is pretty ridiculous. If the council doesn't understand how to sanitise database input, imagine just how bad they are at the stuff that's mildly difficult or worse. Do NOT give any sensitive data to them, whatever you do!
I'm sure that IT working in the council understand input sanitisation and escape sequences, but they're working to a broken standard.