commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Davies <juliusdav...@gmail.com>
Subject Re: [codec] Base64 with specified encode/decode alphabets and PAD?
Date Tue, 29 Jan 2013 22:22:46 GMT
Just to be clear, commons-codec doesn't support ORDERED.... yet....

But thought I'd mention it just in case your own data sources are using it.


yours,

Julius




On Tue, Jan 29, 2013 at 1:43 PM, Steve Grennan <sgrennan@yahoo-inc.com> wrote:
> 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.
>
> Steve
>
> ________________________________
> From: Julius Davies <juliusdavies@gmail.com>
> To: Commons Developers List <dev@commons.apache.org>
> Cc: Steve Grennan <stevegrennan@ymail.com>
> 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.
>
>
>
> yours,
>
> Julius
>
>
>
>
> On Tue, Jan 29, 2013 at 11:05 AM, Gary Gregory <garydgregory@gmail.com>
> wrote:
>> Patches and unit tests welcome! Make sure you start from trunk.
>>
>> Gary
>>
>>
>> On Tue, Jan 29, 2013 at 1:47 PM, Steve Grennan
>> <stevegrennan@ymail.com>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: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> yours,
>
> Julius Davies
> 604-222-3310 (Home)
>
> $ sudo apt-get install cowsay
> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> http://juliusdavies.ca/cowsay/
>
>



-- 
yours,

Julius Davies
604-222-3310 (Home)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message