|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: base64 byte-length formulaThe difference between our formulas is that I (mistakenly) took 1 digit as a possible string (or 5, 9 etc.) For those you need the +3 TERM. For all the good length 2,3,4 6,7,8 etc the two formulas are equivalent. Julo
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
Home Last updated: Wed Jun 12 20:18:49 2002 10740 messages in chronological order |