MIME attachments stored in mySQL

[matt roberts]

Hello,

I am parsing a mailbox using the imap functions, pulling out images
attached and putting them into mySQL as BLOB fields. I am having
problems displaying images once they are stored in mySQL, and I think
it may be related to the way I store them.

The following line of code is called after an attachment has been
identified as a GIF attachment:

$rawimage = addslashes(imap_fetchbody($mbox,$m,$part_c));
....where $mbox is the imap link and so forth.

Testing to make sure I am actually pulling info out, a debug line like:
print_r($rawimage);

....displays a bunch of chars that are the image attachment data, and a
line like:

print_r(base64_decode($rawimage));

....displays other, different chars.
Looks good so far - I'm definitely pulling images out as raw data.

So I INSERT the $rawimage into my blob field.

However, on the display page, I send the headers like:
header("Content-type: image/gif");
[get image from database and store it in a var called $image_from_db]
echo $image_from_db;

But I get a broken image...

So I try print_r($image_from_db) on this page (after removing the
header line) and it looks like the chars from the tests before - it's
the same data.

base64_decode($image_from_db) does not make the image display properly,
either, but printing it as such shows all those chars again.

I think I do not understand how base64 encoding and addslashes works
between MIME, php and mySQL. Anybody have any ideas? How should I
format the data when I pull it out of MIME (in terms of base64
decoding), how should I insert it (addslashes is correct?) and how
should I echo it when I pull it out into the displaying php image
generation page?
I have a feeling someone has had this problem before out there :)

[Kartic]

Hello Matt,

Looks like it could be an addslash problem. Here is the link for your
reference : http://us4.php.net/addslashes

If you site already has magic_quotes_gpc set (=On) in php.ini (which is
the default), your using addslashes() adds an extra set of slashes to
you already quoted data. So the data's original significance is lost.

In your code, you can check to see if the magic_quotes option is set
using get_magic_quotes_gpc() and then use addslashes().

Why don't you try your code without the addslashes()? Everything you
have described seems correct and should give you your required outcome.
If after removing addslashes(), it still does not work, try doing a
stripslashes() on the retrieved image before calling base64_decode().
Thank you,
--Kartic

[mattmattmatt]

Thanks Kartic-- but doesnt magicquotes only affect GET and POSTand
COOKIE data? This data is pulled using the imap_fetchbody()
function...

[Kartic]

Ooops...Yes, you are right.

I meant magic_quote_runtime :
http://us2.php.net/manual/en/ref.inf...quotes-runtime and
the corresponding get_magic_quotes_runtime().

Thanks,
--Kartic

[Kartic]

And also, take a peek at the user notes for
http://us4.php.net/base64_encode

There is some interesting stuff there that people had trouble with
(similar to yours)
(Look for mightymrj at hotmail dot com, entry dated 28-Oct-2004 11:35.)
Thank you,
--Kartic

[mattmattmatt]

Yes, I am missing something here...

Turned off magic_quotes_runtime per the suggestion on the base64_encode
man page.

Still corrupted images...

So I try this:
$f = fopen("...etc");
fwrite($f, base64_decode($rawimage));
fclose($f);

...and the pics are well-formed and viewable.
The answer lies in the slashes somewhere, you're right...

[Kartic]

Hello,

I found this article that does something similar to what you are trying
to do...(the article uses an image upload page).. have fun.

http://www.onlamp.com/pub/a/onlamp/2...09/webdb2.html

One more thought crosses my mind...why don't you base64_decode() your
MIME image before you store it into the database table?
Thanks,
--Kartic