Boost Users :
Subject: Re: [Boost-users] Is the behaviour of the binary_from_base64intended?
From: F David Sacerdoti (federicosacerdoti_at_[hidden])
Date: 2008-11-01 19:18:58
I had the same problem and came on this thread. I'm sorry but Robert's
reply is missing the point: we the users want to get the job done, and
in this age base64 behavior is defined by RFC 2045 and 3548. Those
documents provide the answer to the problem you describe below, and the
accepted behavior we want.
Boost is very good, and it is unfortunate that the lines below, while
elegant and purposeful, are essentially useless.
using namespace boost::archive::iterators;
transform_width<string::const_iterator, 6, 8>
binary_from_base64<string::const_iterator>, 8, 6
Please consider the goal of most programmers! Python does this
admirably, and generally boost as well.
Author: Robert Ramey
Date: 2007-04-13 23:51 -400
Subject: Re: [Boost-users] Is the behaviour of the
Here is the problem:
Suppose you have 1 byte - that's 8 bits. Now you encode that into
3 bit octet + 3 bit octet + 2 bits. The last is extended to a byte so
have a 3 byte "file".
now you translate back into inary. Your "file" has 3 bytes. Each
byte is translated backinto binary as 3 bits + 3 bits + 3 bits - 9 bits
which turns out to be 2 bytes.
So our original bitstream has been extended from 8 bits to 16.
In the serialization library
I record first the total number of bytes and and send that first. The
iterator "stack" I use to translate is terminated by a count rather than
some special "end" iterator.
To me this problem is inherent in the base 64 encoding scheme
as I understand it.
> I am seeing the same problems. base64 encoding works for some
> input and not others.
> Does anyone know if this is fixed in RC 1_34_0 or cvs head?
Boost-users mailing list
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net