Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mail_mimeDecode and databases

Status
Not open for further replies.

Borvik

Programmer
Jan 2, 2002
1,392
US
Hey all,

Anyone know anything about using Mail_mimeDecode?

I'm writing an interface that reads email from a database, and am trying to support both MySQL and PostgreSQL. So far I've been concentrating on MySQL as the database backend, but just recently started to make sure the SQL scripts will work for PostgreSQL - and this is where I noticed the problem.

I got all the SQL to work, returning all the data that it should, but am having difficulty using Mail_mimeDecode to decode the information.

I do not have a problem when viewing the actual email, but the problem comes when I am viewing the list. The SQL queries grab just the headers from the mail (stored separate from the body), as I shouldn't need the body to get the From and Subject headers.

When generating the list and looping through the returned email, I run the following code:

Code:
$msgHeader              = $n['messageblk'];
$decode                 = new Mail_mimeDecode($msgHeader);
$args                   = array();
$args['include_bodies'] = true;
$args['decode_bodies']  = true;
$args['decode_headers'] = true;
$args['input']          = '';
$args['crlf']           = "\r\n";
$structure              = $decode->decode($args);
$ret_data['msg'][$i]['subject']     = $structure->headers['subject'];
$ret_data['msg'][$i]['from']        = $structure->headers['from'];

That is in a loop grabbing all the messages to be displayed.

It works fine when pulling data from MySQL (ie the Subject and From gets populated correctly), but when the database is PostgreSQL it doesn't decode properly. I've verified that the data is actually pulling from the database (using print_r($n); exit();), it just doesn't seem to be decoding (which does work fine, when the body is included during the view email process).

Sorry for the long-winded post, I just wanted to include enough information.

Thanks.
 
Do you have the same message stored in both databases? Perhaps you could compare the two encoded forms to see what's triping up your decode function.



Want the best answers? Ask the best questions! TANSTAAFL!
 
Yes the same message is in both database (I exported the data from MySQL to PostgreSQL).

I noticed in the file used to do the importing that line breaks were represented as \n (or was it \r). Anyway I modified the entire file and replace all of the single instances of \n or \r with \r\n. Previously I also tried varying the value for $args['crlf'] - I also tried a simple str_replace on the header to make sure I was grabbing the correct \ tag, and I had found only the one.

The funny thing is though, when combined with the body of the email - the decoding works just fine (on either MySQL or PostgreSQL). It just seems to be when I try decoding the headers as a separate entity that I'm seeing the problem.
 
I don't know how your data was encoded, but SMTP headers generally aren't. It's only the body of a message that may be encoded.



Want the best answers? Ask the best questions! TANSTAAFL!
 
Ah....


No the headers are not encoded per se (base64), but by running it through the decoder it does separate the headers into the $structure->headers['subject'] format - which it isn't doing.
 
I found the difficulty after replacing after running the following on both the MySQL result, and the PostgreSQL result:

Code:
$msgHeaders = str_replace("\r", "\\r", $msgHeaders);
$msgHeaders = str_replace("\n", "\\n\n", $msgHeaders);
echo "<pre>$msgHeaders</pre>";
exit();

I found that the MySQL database was properly returning the extra \n that were after the headers, while PostgreSQL seemed to want to trim those results.

The solution was to add \n\n to the end of $msgHeaders, which didn't interfere with the MySQL results, but cause the PostgreSQL results to work.

Cheers!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top