Interesting. I would vote for raising an exception any time a character is ignored.
With respect to my real problem - it absolutely is the client and not Codec. However, a strict mode would have saved me some time figuring that out! Thanks for all of the feedback. BTW, I did log a bug for this: https://issues.apache.org/jira/browse/CODEC-95 On Fri, Dec 4, 2009 at 1:11 PM, Julius Davies <[email protected]> wrote: >> >> On Fri, Dec 4, 2009 at 10:24 AM, Adam Rabung <[email protected]> wrote: >>> Julius, >>> My particular problem was the client was not encoding url-safe, and >>> then sending over http. The result was I was trying to decode " " >>> where the client had encoded "+" - so I wasn't get a "+" OR a "-". A >>> strict Base64 would have caught this immediately. I'm not very >>> familiar w/ the base 64 spec, so your #1 concerns me a little. Would >>> it be reasonable for strict mode to reject "abc def", where that space >>> is literally ascii 32 space? >>> > > > I don't know if that would be reasonable! I think this is the > pertinent info from the spec: > --- > In base64 data, characters other than (those in Table 1, line breaks, > and other white space) probably indicate a transmission error > --- > > I wouldn't vote against rejecting "abc def". But I wouldn't vote for > it, either. > > > In your particular situation the real problem is probably a bug in > your client's code. Maybe you can get your client to use the > commons-codec-1.4 Base64.encodeBase64URLSafe() method? > > > By the way, you may find this method useful: > > Base64.isArrayByteBase64() > > Unfortunately it treats whitespace as valid. > > > > -- > yours, > > Julius Davies > 250-592-2284 (Home) > 250-893-4579 (Mobile) > http://juliusdavies.ca/logging.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
