on 8/13/01 8:05 AM, "Dave Rolin" <[EMAIL PROTECTED]> wrote:
> 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.
Kick ass explanation and response!
Thanks!
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
