> From: owner-openssl-us...@openssl.org On Behalf Of Marc Phillips
> Sent: Tuesday, 03 August, 2010 23:48
> I'm having an issue with using base64 decode. I can encode fine,
> and can decode strings just fine, but am having an issue
> decoding (specifically) a sqlite database.
>
> Here's my encode and decode: <snip>
> As noted, encode and decode are fine on strings and some
> binary files, but
> if the string. Any decode seems to stop at the first \n.
>
I'm not sure quite what you mean here. bio_b64 by default
adds \n linebreaks every 64 chars when encoding (output)
and expects them at 80ish or less when decoding (input).
(IIRC the first PEM specs were 64 but some later specs
were higher, and this 'gap' allows OpenSSL to support all.)
Are you storing the string including the \n's, and getting it back
with them the same? Remember that if you run through C I/O,
\n gets changed to and from a possibly-different platform EOL;
in particular CRLF on MSDOS/Windows and CR on old(?) MacOS.
(And yet others on systems you are no longer likely to find.)
If you're writing/reading these strings on different systems --
perhaps because your database server is remote -- maybe some
translation happened.
I don't know what if anything sqlite does itself. If you are
encoding your OWN data to store and get back and decode later,
I would suggest not using ANY linebreaks. They sometimes confuse an
actual database, or database-related tools like report generators.
You can set BIO_FLAGS_BASE64_NO_NL, or you can (more simply) just
call EVP_{Encode,Decode}Block for memory-to-memory.
> If I encode using the above routine, I can decode the file using
> openssl enc -base64 -d
>
Yep, that expects (and -e produces) the 'standard' linebreaks.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
