[
https://issues.apache.org/jira/browse/CODEC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874355#action_12874355
]
Sebb commented on CODEC-91:
---------------------------
OK, but it's still possible to have PAD after a single input character, so
maybe your patch needs to allow for this, even if the final if clause does not
need to.
However, I'm now wondering whether it makes sense to treat PAD differently from
non-alphabet data.
Why should a single PAD restart the decoding? Was that how 1.3 behaved?
> 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
> 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.
