Is the behaviour of the binary_from_base64 intended?
Hello! I've run into a strange problem with encoding/decoding base64. Let's have a look at the following code: ///////////////////////////////////////////////////////// #include "boost/archive/iterators/base64_from_binary.hpp" #include "boost/archive/iterators/binary_from_base64.hpp" #include "boost/archive/iterators/transform_width.hpp" #include <string> #include <iostream> using namespace std; 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; int main() { string str("Hello, world!"); cout << str << endl; // This works quite well. string enc(base64_t(str.begin()), base64_t(str.end())); cout << enc << endl; // The following call throws an exception about unacceptable // base64 character in the stream. Probably a bug? //string dec(binary_t(enc.begin()), binary_t(enc.end())); // Hackish workaround: string dec( binary_t(enc.begin()), binary_t(enc.begin() + enc.length() - 1) ); cout << dec << endl; return 0; } ////////////////////////////////////////////////////////////// Does those transforming iterators work as expected? Why the tailoring zero is included in the transformation process? Is there a better way to workaround the problem? Thanks in advance! -- Anatoli Sakhnik.
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 Anatoli Sakhnik wrote:
Does those transforming iterators work as expected? Why the tailoring zero is included in the transformation process? Is there a better way to workaround the problem?
Thanks in advance!
-- Anatoli Sakhnik.
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 <boost/test/test_tools.hpp> #include <boost/archive/iterators/transform_width.hpp> #include <string> #include <vector> using namespace std; using namespace boost::archive::iterators; typedef transform_width<string::const_iterator, 6, 8> ForwardT; typedef transform_width<string::const_iterator, 8, 6> 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 <ramey@rrsd.com> 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
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,
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,
participants (1)
-
Anatoli Sakhnik -
Jeffrey -
Robert Ramey