[ https://issues.apache.org/jira/browse/CODEC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875013#action_12875013 ]
Jochen Wiedmann commented on CODEC-91: -------------------------------------- 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 > 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.