4 ms·
So I guess the bank was just too lazy to provide the character conversion before storing to EBCDIC, made cheap excuses and is now forced by GDPR? Good!
by high_5 3y ago
So I guess the bank was just too lazy to provide the character conversion before storing to EBCDIC, made cheap excuses and is now forced by GDPR? Good!
- thesnide 3y agoProper encoding of your data is key indeed. I mean, user data should be treated as binary anyway. And then hashing it to whatever makes sense for performance. But still binary comparing for accuracy.
- corbezzoli 3y ago> user data should be treated as binary anyway I don't know about that, there still needs to be some validation. Is your legal name really "Bobby $@134 Tables"? In this case validation comes in the form of "is every character EBCDIC-compatible?"
- fyrn_ 3y agoWhat does "store as binary" even mean in this instance, binary is just ones and zeros. You have to decode it somehow for it to carry meaning. Maybe you meant opaque, but even that would the prevent normal display the data to the user. The user is not going to accept a hexadecimal binary form of their name, you can't sidestep Having to deal with encodings by just not specifying one. Also good moment to point out the you can't do a binary comparison of unicode strings, you need a unicode library that handles normalization.
- JimDabell 3y agoThat would mean that Zoë (spelt with U+0065 Latin Small Letter E followed by U+0308 Combining Diaeresis) wouldn’t match Zoë (spelt with U+00EB Latin Small Letter E with Diaeresis) even though they are the same name that just happen to be typed in on different platforms. Names exist at a different level of abstraction to binary and it’s a mistake to treat them as binary.