[
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)
