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 <sgren...@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 <juliusdav...@gmail.com> > To: Commons Developers List <dev@commons.apache.org> > Cc: Steve Grennan <stevegren...@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 <garydgreg...@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 >> <stevegren...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
