I'm working with emails and want to display the html in the browser, I'm not sure how to deal with the encoding. I want to extract the html to display it in the html browser. The way I plan on doing this is using an html parser on the entire email parsing the data inbetween the tags in the html section. Is there an easier/more efficient way to do this?
Here's text encoding
------=_Part_29856965_540743623.1285814590176
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Here's the html encoding
------=_Part_29856965_540743623.1285814590176
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
You can have a look at the ezComponents - Mail component. It has a lot of operations for building and using a MIME
http://ezcomponents.org/docs/tutorials/Mail
Related
Building a Raw view of text in my application, like pastebin does:
http://pastebin.com/raw.php?i=nfVT7b0Z
So, I wrote the script which just echos out the $contents, but newlines, spaces, and tabes are not being proceeded. Looking at the pastebin source above, you will notice they don't wrap the text in any HTML tags such as <pre>. How then are they getting the text to format?
Are they using some special header?
The content you see is not HTML. It's text. You can use the following header to achieve the same result with output sent by php.
Content-Type: text/plain; charset=utf-8
Example:
<?php
header('Content-Type: text/plain; charset=utf-8');
echo "First Line\nSecond Line";
?>
Curl was my friend here. I noticed in the response this header:
Content-Type: text/plain; charset=utf-8
So simply do:
header("Content-Type: text/plain; charset=utf-8");
Before outputting any text.
I have inherited a script that sends some content out in three languages (all on same content - repeated) however when recieved the content characters are broken for what i assume is a UTF-8 issue.
Am i right all i need to do is change the charset part to utf-8, or does anything else need to change like the 7bit part ?
you can see where I inserted one UTF-8 reference (not tested yet)
there was something here http://bitprison.net/php_mail_utf-8_subject_and_message which seems to reference base encoding, but I'm not sure if I need that here ?
// Contruct message body.
$body = "";
// Add message for non-mime clients.
$body .= "This is a multi-part message in MIME format.\n";
// Add text body.
$body .= "\n--$boundary\nContent-Type: text/plain; charset=UTF-8; format=flowed\nContent-Transfer-Encoding: 7bit\n\n" . $textContent;
// Add HTML body.
$body .= "\n--$boundary\nContent-Type: text/html; charset=ISO-8859-1; format=flowed\nContent-Transfer-Encoding: 7bit\n\n" . $htmlContent;
mail( $row["email"], "Update Your ArtsDB Listing", $body, $headers );
I looked on another post on here for an a example.
$body .= "\n--$boundary\nContent-Type: text/plain; charset=UTF-8; format=flowed\nContent-Transfer-Encoding: 8bit\n\n" . $textContent;
// Add HTML body.
$body .= "\n--$boundary\nContent-Type: text/html; charset=UTF-8; format=flowed\nContent-Transfer-Encoding: 8bit\n\n" . $htmlContent;
You are using Content-Type: text/plain; charset=UTF-8 to tell the mail reader that such message part uses UTF-8, which is fine, but... What does the $textContent variable contain? That's the important bit. According to Content-Transfer-Encoding: 7bit, it's a 7 bit encoding so it can't be raw UTF-8. However, you are not using any of the usual 7-bit encodings used for e-mail. Otherwise, there would be a (e.g.) Content-Transfer-Encoding: quoted-printable header.
To sum up, you need to:
Have a source string that contains valid UTF-8.
Pick a encoding for the transfer, such as quoted_printable_encode().
Add a header to tell which transfer encoding you chose.
You could also send the raw UTF-8 as-is and set Content-Transfer-Encoding: 8bit but I would not recommend it. You risk breaking the SMTP standard just by sending very long lines. Also, you have no idea of what kind of legacy programs this will go through.
E-mail is harder than it seems, that's why sooner or later you end up using a third-party library: PHP Mailer, Swift Mailer, PEAR Mail...
Content-Transfer-Encoding: 7bit
This makes no sense - there is no direct mapping between 7bit data and an 8+bit representation. You need to change the mime headers to state what encoding you are using.
For SMTP the transfer encoding should be a 7 bit ascii charset. To change your utf8 data you need to encode this - common encodings are base64 and quoted printable (PHP provides encode and decode fns for both).
Why not just use a good lib like phpmailer or swiftmailer
After mime parsing I am getting email body with duplicate entry(plain n html) and wondering how I can get the true message body. I am using php/mysql. Is there anything in php string or mysql to solve this?
email message body Sample:
testing body from hotmail. testing word can be repeated.
testing body from hotmail. testing word can be repeated.
Ok, so as I said you receive the email in double because you receive it in plain/text and text/html format.
The best way to read email from pop3 as I found until now is Manuel Lemos POP3 Access
the email formats ussualy are received in parts, for each type or image
plain/text:
------=_Part_38964_33016848.1312149074828
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
email content in text format
text/html:
------=_Part_38964_33016848.1312149074828
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
email content in html format
you will find in headers the name of the part, that unique identifier
Content-Type: multipart/alternative;
boundary="----=_Part_38964_33016848.1312149074828"
There isn't a simple way to get the real plain/text and text/html, they are most likely to be togheter if sent from a public email service. If you send email from your scripts, I don't think you'll bother to send that email in double format.
I am using PHP to send emails on demand to clients. I have a script which seemed fairly robust in testing, generating MIME-1.0 Compatible multipart/alternative emails that had a text and html version. Emails are sent as base64 encoded strings to preserve international characters (message text is usually in German).
However, it seems that certain servers, upon receiving the mail, insert a space (0x20) just before each CR-LF sequence. This doesn't break the base64, of course, but since it breaks up the CR-LF-CR-LF sequence that separates headers from messages, the messages are not parsed properly (or, at all, actually, since the secondary headers are never seen to stop).
Here is an example message as generated:
From: example#example.com
To: example#example.org
Subject: Test Message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="{$boundary}"
This is a multipart Message in MIME Format
--{$boundary}
MIME-Version: 1.0
Content-ID: <{$content_id}>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-Length: {$objlen}
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQ=
--{$boundary}
MIME-Version: 1.0
Content-ID: <{$content_id}>
Content-Type: text/html; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-Length: {$objlen}
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVI=
--{$boundary}--
Is there some way to prevent the mail server from adding these spaces?
The problem is you are not sending your email in quoted printable encoded format. I'd strong consider using a library to send the email for you to avoid all of these issues:
Email Quoted Printable Encoding
The problem has to do with certain email servers (e.g. t-online.de) treating CRLF newline sequences as less valid than LF only newlines. When newlines were changed from CRLF to LF, everything worked fine.
On the one hand, I would think this was a flagrant disregard for the standards set out in the RFCs, but on the other hand, I've had no issues with these messages since making the changes, so either (a) it doesn't matter or (b) there have been changes about which I do not know, which is always possible.
In any case, always end with LF only, I guess, if you intend to send multipart/* messages.
I have a file containing an email in "plain text MIME message format". I am not sure if this is the EML format. The email contains an attachment and I want to extract the attachment and create those files again. This is how the attachment part looks like -
...
...
Receive, deliver details
...
...
From: sac ascsac <sacsac#sacascsac.ascsac>
Date: Thu, 20 Jan 2011 18:05:16 +0530
Message-ID: <AANLkTimmSL0iGW4rA3tvSJ9M3eT5yZLTGsqvCvf2fFC3#mail.gmail.com>
Subject: Test attachments
To: ascsacsa#ascsac.com
Content-Type: multipart/mixed; boundary=20cf3054ac85d97721049a465e12
--20cf3054ac85d97721049a465e12
Content-Type: multipart/alternative; boundary=20cf3054ac85d97717049a465e10
--20cf3054ac85d97717049a465e10
Content-Type: text/plain; charset=ISO-8859-1
hello this is a test mail. It contains two attachments
--20cf3054ac85d97717049a465e10
Content-Type: text/html; charset=ISO-8859-1
hello this is a test mail. It contains two attachments<br>
--20cf3054ac85d97717049a465e10--
--20cf3054ac85d97721049a465e12
Content-Type: text/plain; charset=US-ASCII; name="simple_test.txt"
Content-Disposition: attachment; filename="simple_test.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gj5n2yx60
aGVsbG8gd29ybGQKYWMgYXNj
...
encoded things here
...
ZyBmZyAKCjIKNDIzCnQ2Mwo=
--20cf3054ac85d97721049a465e12
Content-Type: application/x-httpd-php; name="oscomm_backup_code.php"
Content-Disposition: attachment; filename="oscomm_backup_code.php"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gj5n5gxn1
PD9waHAKCg ...
...
encoded things here
...
X2xpbmsoRklMRU5BTUVfQkFDS1VQKSk7Cgo/Pgo=
--20cf3054ac85d97721049a465e12--
I can see that the part between X-Attachment-Id: f_gj5n2yx60 and ZyBmZyAKCjIKNDIzCnQ2Mwo=, both including
is the content of the first attachment. I want to parse those attachments (file names and contents and create those files).
I got this file after parsing a dbx format file using a DBX Parser class available in PHP classes.
I searched in many places and did not find much discussion regarding this here in SO other than Script to parse emails for attachments. May be I missed some terms while searching. In that answer it is mentioned -
you can use the boundries to extract
the base64 encoded information
But I am not sure which are the boundaries and how exactly to use the boundaries? There already must be some libraries or some well defined method of doing this. I guess I will commit many mistakes if I try reinventing the wheel here.
There's an PHP Mailparse extension, have you tried it?
The manual way would be, process the mail line by line. When you hit your first Content-Type header (this one in your example):
Content-Type: multipart/mixed; boundary=20cf3054ac85d97721049a465e12
You have the boundary. This string is used as the boundary between your multiple parts (that's why they call it multipart).
Everytime a line starts with the dashes and this string, a new part begin. In your example:
--20cf3054ac85d97721049a465e12
Every part will start with headers, a blank line, and content. By looking at the content-type of the headers you can determine which are attachments, what their type is and their filename.
Read the whole content, strip the spaces, base64_decode it, and you've got the binary contents of the file. Does this help?