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. ---START--- using namespace boost::archive::iterators; typedef base64_from_binary< transform_width<string::const_iterator, 6, 8> > base64_t; typedef transform_width< binary_from_base64<string::const_iterator>, 8, 6 > binary_t; ---END--- Please consider the goal of most programmers! Python does this admirably, and generally boost as well. Thanks, Federico -------------------------- Author: Robert Ramey Date: 2007-04-13 23:51 -400 To: boost-users Subject: Re: [Boost-users] Is the behaviour of the binary_from_base64intended? 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 you 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. Robert Ramey Jeffrey wrote:
Hello.
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?
Thanks,
_______________________________________________ Boost-users mailing list Boost-users@??? http://lists.boost.org/mailman/listinfo.cgi/boost-users