Re: base64 byte-length formula

[Martins Krikis <mkrikis@yahoo.com>]

Sorry, I had missed to CC the previous to the list
but I'm doing it with this. The way you understand
base64 is not the way I understand it. Can somebody
please chime in and set the record straight?

Here is the relevant text from RFC 2045, describing
the base64 encoding process. We are, of course,
talking about decoding in these length-calculation
formulas. More of my comments further down in text.

<RFC 2045 QUOTE>
  Special processing is performed if fewer 
  than 24 bits are available
  at the end of the data being encoded.  
  A full encoding quantum is
  always completed at the end of a body.  
  When fewer than 24 input bits
  are available in an input group, zero 
  bits are added (on the right)
  to form an integral number of 6-bit groups.  
  Padding at the end of
  the data is performed using the "=" character.
  Since all base64
  input is an integral number of octets, 
  only the following cases can
  arise: (1) the final quantum of encoding 
  input is an integral
  multiple of 24 bits; here, the final 
  unit of encoded output will be
  an integral multiple of 4 characters 
  with no "=" padding, (2) the
  final quantum of encoding input is 
  exactly 8 bits; here, the final
  unit of encoded output will be two 
  characters followed by two "="
  padding characters, or (3) the final 
  quantum of encoding input is
  exactly 16 bits; here, the final 
  unit of encoded output will be three
  characters followed by one "=" padding 
  character.
</RFC 2045 QUOTE>

--- Julian Satran <Julian_Satran@il.ibm.com> wrote:

> comments in text - julo
> 
> --- Julian Satran <Julian_Satran@il.ibm.com> wrote:
> 
> > Sorry - It must have stayed in my pile. Your
> formula
> > is not correct.
> > The correct one is (n*3 + 3)/4
> 
> Do you have any counterexamples to my formula?
> 
> +++ 1 b64 digit is one byte - according to you it is
> 0 +++

1 b64 digit is impossible. It would need 3 '='s
at the end and such a case is not mentioned in
the RFC. It would not describe a full byte either.

> Here are a couple for yours (unless I'm totally
> messed up and don't know how base64 encoding works):
> 
> 3 base64 digits with 1 equivalence sign at the
> end should result in a 2-byte binary string.
> According to your new formula:
> (3 * 3 + 3) / 4 = 3.
> 
> +++ 3 b64 digits (18 bits) are 3 bytes +++

No, it's case (3) in the quote from RFC I made
above, these 18 bits describe 2 full bytes,
not 3 incomplete ones. 

> 2 base64 digits with 2 equivalence signs at the
> end should result in a 1-byte binary string.
> According to your new formula:
> (2 * 3 + 3) / 4 = 2.
> 
> +++ incorrect - 2 digits is 12 bit is 2 bytes +++

No, it's case (2) in the quote from RFC I made
above, these 12 bits describe 1 full byte, not
2 incomplete ones.

You really have to imagine the encoding process
when thinking about how to decode.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and
            may not be my employer's.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com