commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <>
Subject [jira] Commented: (CODEC-95) Base64: optionally allow strict parsing of base64 strings
Date Wed, 26 Jan 2011 13:07:43 GMT


Gary Gregory commented on CODEC-95:

My preference would be to stop growing the API with ctors for optional attributes: The ctors
for this class builds objects with parameters that are required (if any as defined by the
RFC), thats's it . Exceptions are be made for common options. Perhaps line length and EOL
are such common settings, you mileage may vary. I never change those.

For optional and non-standard (per the RFC) settings, the values are set via setters.

No need for config objects, IMO, which end up feeling more like structs and feel less OO,
less thought out: oh let's hide all this and dump it in a config object.

If it makes sense for the impl or OO design we can have subclass like Base64StrictInputStream
that carries the extra settings and logic. Otherwise, we can leave it all in one class.

> Base64: optionally allow strict parsing of base64 strings
> ---------------------------------------------------------
>                 Key: CODEC-95
>                 URL:
>             Project: Commons Codec
>          Issue Type: Improvement
>    Affects Versions: 1.4
>            Reporter: Adam Rabung
>            Priority: Minor
>         Attachments:
> Currently, Codec skips base64 characters that are outside of the encode table.  I realize
this is perfectly to spec, but I wonder if other users might appreciate a "strict" mode that
throws an exception when one of these illegal characters are encountered.  For example, I
would love an exception to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message