Hi, Robert! Yes, the question was about the end iterator while decoding from base64. As I understand now, the problem refers to the transform_width iterator rather to the binary_from_base64. The former feeds another unnnecessary byte, which by the fact is equal 0, to the latter. And fixing something in the binary_from_base64 would be wrong. I've written a little test to show this: /////////////////////////////////////////////////////////////////////////////// #include #include #include <string> #include <vector> using namespace std; using namespace boost::archive::iterators; typedef transform_width ForwardT; typedef transform_width BackwardT; int test_main(int, char*[]) { string str("Hello, world!"); string enc(ForwardT(str.begin()), ForwardT(str.end())); string dec(BackwardT(enc.begin()), BackwardT(enc.end())); BOOST_CHECK_EQUAL(dec.length(), str.length()); BOOST_CHECK_EQUAL_COLLECTIONS(str.begin(), str.end(), dec.begin()); return 0; } ////////////////////////////////////////////////////////////////////////////// It's evident, that it should pass, isn't it? But it fails, the lengths of dec and str differ. Can the problem be solved? -- Anatoli Sakhnik. On 12/04/07, Robert Ramey wrote:

I'm not sure I understood the question - but that won't inhibit me from commenting.

I had a lot of problem with this due to the fact that number of bas 64 octets didn't always come out to an integral number of bytes. I think i had to avoid the usage of an end iterator to make things work as I wanted. Sorry I don't know what more I could tell you.

Robert Ramey

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,