commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jochen Wiedmann (JIRA)" <>
Subject [jira] Commented: (CODEC-91) Handling of embedded padding in base64 encoded data changed in 1.4
Date Thu, 03 Jun 2010 08:58:05 GMT


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(;

> Handling of embedded padding in base64 encoded data changed in 1.4
> ------------------------------------------------------------------
>                 Key: CODEC-91
>                 URL:
>             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.

View raw message