3 ms·
I don't disagree with the idea that a relatively complicated base64 API seems painful but... > Normally I agree with explicit being better than implicit, but I
by masklinn 3y ago
I don't disagree with the idea that a relatively complicated base64 API seems painful but...
> Normally I agree with explicit being better than implicit, but I don't see the harm here. If there's no specific interoperability requirements, explicitly choosing a configuration isn't particularly important.
Pretty much the entire point of base64 is interop, so there would always be specific interop requirements.
And since a base64 library tends to be reflexive, a library's default tends to either "way too strict to consume any base64 you can find in the wild" or "so loose you can get a carrier strike group through" e.g. Ruby and Python will strip out any invalid character from the input before attempting a parse, python requires padding to be present but I'm not sure there's any way to make ruby's decode64 fail as long as you give it a string since it does not.
- riffraff 3y agoI am not sure what you are looking for, but ruby has strict_decode64 which does fails on invalid characters and invalid encodings, and urlsafe_decode64, which relies on that too. I think they've been there for a few years.
- masklinn 3y agoI’m not looking for anything, just pointing out that defaults are insanely variable, and people use them because they are the default. If you don’t know and don’t care and need to generate base64 you’ll use decode64 because that’s the default and it worked fine. And if I have to interact with that, it’s an interop issue