Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.3
-
None
Description
Regular Base64 uses + and / for code point 62 and 63. URL-Safe Base64 uses - and _ instead. Also, URL-Safe base64 omits the == padding to help preserve space.
http://en.wikipedia.org/wiki/Base64#URL_applications
Approach:
decode() should be able to seamlessly handle either situation. This means interpreting +- and /_ as equivalents at any time during the decode. decode() also needs to be more robust against missing padding characters.
encode() should either emit +/ or -_ depending on a mode set during Base64 construction.
Since URL-SAFE is all about URL's (e.g. HTTP GET) and most browsers are limited to 1KB of query string, I do not think we need to bother making the URL-MODE available in the stream-oriented classes. (Nonetheless, the streams should be able to decode URL-SAFE, but I don't think they should produce it).
—
Some background information: I'm putting together a webapp that integrates with MS Active Directory. Users and Groups are keyed of objectGUID with is a 128 bit int. Would be nice to get some support for this kind of thing:
"Click to view the profile of <a href='?u=_3-PwBzbRxqMi1qTBhg_6A'>Julius Davies</a>."
Right now I'm using Hex:
"Click to view the profile of <a href='?u=ff7f8fc01cdb471a8c8b5a9306183fe8'>Julius Davies</a>."
Current Base64 class would output this, and I suspect the + would screw things up:
"Click to view the profile of <a href='?u=/3+PwBzbRxqMi1qTBhg/6A=='>Julius Davies</a>."
Attachments
Attachments
Issue Links
- incorporates
-
WICKET-2171 Base64UrlSafe claims to be RFC 3548 compliant, but isn't
- Resolved
- is duplicated by
-
CODEC-36 [codec] Support of Base 64 Encoding with URL and Filename Safe Alphabet
- Closed
- relates to
-
CODEC-160 Base64.encodeBase64URLSafeString doesn't add padding characters at the end.
- Closed