[
https://issues.apache.org/jira/browse/CODEC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874364#action_12874364
]
Julius Davies commented on CODEC-91:
------------------------------------
PAD after a single character should be impossible. Something bad has happened
in that case. There's no way to stuff 8 bits into a single 6 bit container.
Look at the 4 possibilities:
{code}
ABCD --> 4 * 6 = 24 bits --> 3 bytes
ABC= --> 3 * 6 = 18 bits --> 2 bytes + 2 bits of padding
AB== --> 2 * 6 = 12 bits --> 1 byte + 4 bits of padding
A=== --> 1 * 6 = 6 bits --> original byte cannot be reconstructed
{code}
A single PAD restarts the decoding, but so does the 2nd PAD if it's there.
Both restart it. Notice the 1st PAD will set modulus to 0, so the if (modulus
!= 0) branch will be skipped for the 2nd PAD.
I put the unit-test into Base64Codec13Test.java because the end result with
codec-1.3.jar is the same, although the logic is a bit different.
I will still look into what we can do for modulus==1 case, even though 2 bits
are definitely lost in that case.
> 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.
