You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by ying lcs <yi...@gmail.com> on 2007/08/19 02:33:47 UTC

Base 64 encoding in Jakarta commons

Hi,

I know Jakarta commons has a Base 64 encoding.  But does it supports a
'modified Base64 for URL'?

>From here:
http://en.wikipedia.org/wiki/Base64

For this reason, a modified Base64 for URL variant exists, where no
padding '=' will be used, and the '+' and '/' characters of standard
Base64 are respectively replaced by '*' and '-', so that using URL
encoders/decoders is no longer necessary and has no impact on the
length of the encoded value, leaving the same encoded form intact for
use in relational databases, web forms, and object identifiers in gen


Thank you.

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


Re: [codec] Base 64 encoding in Jakarta commons

Posted by simon <sk...@apache.org>.
On Sat, 2007-08-18 at 19:33 -0500, ying lcs wrote:
> Hi,
> 
> I know Jakarta commons has a Base 64 encoding.  But does it supports a
> 'modified Base64 for URL'?
> 
> >From here:
> http://en.wikipedia.org/wiki/Base64
> 
> For this reason, a modified Base64 for URL variant exists, where no
> padding '=' will be used, and the '+' and '/' characters of standard
> Base64 are respectively replaced by '*' and '-', so that using URL
> encoders/decoders is no longer necessary and has no impact on the
> length of the encoded value, leaving the same encoded form intact for
> use in relational databases, web forms, and object identifiers in gen

This email is about the [codec] library within commons, so it needs to
have that in the subject line (I've fixed the subject for this reply).

I see that codec has the BCodec class that takes an arbitrary charset
string as constructor. The javadoc isn't very clear here, but I presume
this is the set of chars that input is mapped into. In this case, I
presume the url-safe version can be implemented simply by passing the
right string here.

If BCodec doesn't work for this, then it sounds like a good idea to
extend codec somehow to support these url-safe encodings.

Regards,

Simon


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