Jon Stevens wrote:
> The old result of SHA+Old Turbine Base64 returned this string for the sha
> encode/base64 of the String "1"...
>
> NWoZK3kTsExUV00Ywo1G5jlU
>
> Now, with the commons Base64, I get this:
>
> NWoZK3kTsExUV00Ywo1G5jlUKKs=
>
> As you can see, it has a few characters tacked onto the end of it.
>
> So, is the bug in the old Base64 implementation or in the Common's base64
> implementation?
Base64 takes 3 bytes (24 bits) at a time and maps them into 4 base64 "digits".
Thus each base64 digit represents 6 bits. If the bytes in the original data
isn't a multiple of 3, padding is used on the last group (= is the pad
character). Thus, the size of the original data is always going to be:
(base64 size * (6/8)) - pad length
In the first example, the base64 string is 24 characters, and there is no
padding. Therefore, the original data must be 18 bytes:
(24 * (6/8)) - 0 = 18
The second example (commons base64) is 28 characters with one pad character, so
the original data must be 20 bytes:
(28 * (6/8)) - 1 = 20
Since a SHA hash is always 20 bytes in size, it looks like the commons
implementation is getting it right, and there clearly has to be a bug in the
original base64 encoder you were using.
Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
