commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Grennan <>
Subject Re: [codec] Base64 with specified encode/decode alphabets and PAD?
Date Tue, 29 Jan 2013 21:43:25 GMT
Hi, Julius,

I wasn't aware of the ORDERED option, but I'll take a look at it, thanks.

I did notice that the decode list works for both (standard) encodings. I wouldn't write anything
that would change that for the existing calls.


 From: Julius Davies <>
To: Commons Developers List <> 
Cc: Steve Grennan <> 
Sent: Tuesday, January 29, 2013 12:40 PM
Subject: Re: [codec] Base64 with specified encode/decode alphabets and PAD?
Hi, Steve,

Are you thinking of doing the ordered alphabet (like iHarder's ORDERED
option supports)?   That way the encoded values maintain the same
ordering as the original binary values when sorted by byte-value.  But
it's more involved than changing the two extra characters and the
padding, since it remaps the complete Base64 alphabet (0-9 needs to
come before A-Z).

Also note, our current decode() logic handles both regular Base64 and
URL-Safe.  That way users don't have to specify in advance.   But it
doesn't auto-detect.  It just decodes + and - to the same value, as
well as / and _.   So an encoded value could even include both + and -
in the same encoding.  Our logic assumes they are equivalent.



On Tue, Jan 29, 2013 at 11:05 AM, Gary Gregory <> wrote:
> Patches and unit tests welcome! Make sure you start from trunk.
> Gary
> On Tue, Jan 29, 2013 at 1:47 PM, Steve Grennan <>wrote:
>> I know this was considered several years ago, and a simpler alternative
>> was chosen (the "urlSafe" boolean switch), but it would be helpful to some
>> of us if we could replace the standard RFC 2045 alphabets with a
>> nonstandard mapping and PAD character. There are applications where a large
>> amount of legacy code (Java and other) and stored data use an old,
>> nonstandard encoding, and it would be better to at least take advantage of
>> the Apache code, so that people aren't always rewriting it (and creating
>> new bugs) when moving to a new platform.
>> As you might expect, the nonstandard features are the last two encoding
>> chars, and the PAD char (hyphen instead of equals). If we could set those
>> three values, we could use the code. We can't just subclass Base64 because
>> the tables are private. And we'd need to adjust the decoding table, too,
>> unlike URL-safe mode, because the static table uses the RFC values.
>> Any chance of adding a constructor that would let us specify nonstandard
>> values for those things?
> --
> E-Mail: |
> JUnit in Action, 2nd Ed: <http://goog_1249600977>
> Spring Batch in Action: <>
> Blog:
> Home:
> Tweet!


Julius Davies
604-222-3310 (Home)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message