[#325] restore permissive base64 decoding #326
Conversation
|
This change has made the code intolerant of whitespace, which caused us some issues recently after upgrading. Base64 encoding ignores whitespace so normally anything working with it is tolerant of it. It might be good to modify this to allow for the case you are supporting without making whitespace something that isn't supported. We fixed our issues by adding a whitespace filter. I'm assuming that others will also be impacted by this. Just an FYI, if this is intentional and you feel that enforcing whitespace is the right thing to do then that's fine. However from the commit message I assume you may not have realized the impact. @laurentschoelens @lukasj Please, could your merge this PR ASAP? Regards, |
|
This need to be merged by one of the repo owner, I've only provided the actual fix in that PR @antoniosanct I'll try to reach someone if I can |
| * A benchmark showed that taking {@link String} is faster, presumably | ||
| * because JIT can inline a lot of string access (with data of 1K chars, it was twice as fast) | ||
| */ | ||
| public static byte[] _parseBase64Binary(String text) { |
There was a problem hiding this comment.
Is there a reason to not use the JDK-built in Base64 class? (avail since: 1.8)
There was a problem hiding this comment.
I should take a look but maybe base64 in jdk is more strict than here
3 participants
Fixes #325
Regression from #309 and #282
If a character is not in base64 decoding map, it's ignored into the decoding process
newlines and spaces / tabulations or just ignored.
Restore previous base64 decoding function and protect code from throwing ArrayIndexOutOfBoundsException