[ https://issues.apache.org/jira/browse/CODEC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875013#comment-12875013 ]
Sebb edited comment on CODEC-91 at 3/26/17 6:59 PM: ---------------------------------------------------- I'm clearly in favour of the current behaviour: Any non-blank characters following the *proper* number of pad characters indicates a broken data stream. Note, that the user is able to achieve his strange wish by parsing the data stream with a simpe regex before handling it over to commons codec. For example (not verified, in particular not for performance, just to give an impression): {code} String base64String = "Y29tbW9ucwo=Y29tbW9ucwo="; Pattern p = Pattern.compile("\\=([^\\=\\s])"); for (;;) { Matcher m = p.matcher(base64String); while (m.find()) { base64String = m.replaceFirst(m.group(1)); } } {code} was (Author: joc...@apache.org): I'm clearly in favour of the current behaviour: Any non-blank characters following the *proper* number of pad characters indicates a broken data stream. Note, that the user is able to achieve his strange wish by parsing the data stream with a simpe regex before handling it over to commons codec. For example (not verified, in particular not for performance, just to give an impression): String base64String = "Y29tbW9ucwo=Y29tbW9ucwo="; Pattern p = Pattern.compile("\\=([^\\=\\s])"); for (;;) { Matcher m = p.matcher(base64String); while (m.find()) { base64String = m.replaceFirst(m.group(1)); } } > Handling of embedded padding in base64 encoded data changed in 1.4 > ------------------------------------------------------------------ > > Key: CODEC-91 > URL: https://issues.apache.org/jira/browse/CODEC-91 > Project: Commons Codec > Issue Type: Bug > Affects Versions: 1.4 > Reporter: Chris Pimlott > Assignee: Julius Davies > Fix For: 1.x > > Attachments: codec-91-actually-works-and-tests-yay.patch > > > 1.4 changed the way that embedded padding characters (i.e. "=") were handled > when decoding base64 data. Previously, the decoder ignored them and decoded > all the data. Now it stops upon encountering the first padding byte. This > breaks compatibility with previous versions. > For example, in 1.4, > b64.decode("Y29tbW9ucwo=".getBytes()); > gives the same result as > b64.decode("Y29tbW9ucwo=Y29tbW9ucwo=".getBytes()); -- This message was sent by Atlassian JIRA (v6.3.15#6346)