Sending E-mail From Your MultiValue Programs - Part 5: Creating and Sending E-mails with HTML and Text Sections

Now that I have covered the basics of sending an e-mail from your MultiValue system, let's look at making the e-mail look pretty. A common question is. "how can I present my e-mailed invoices as HTML, or send a newsletter, or add a nice signature to my e-mail?"

Personally, most e-mails I send are text-only, unless I'm trying to get someone's attention, or it is better to present something is a prettier format. If you have ever looked at the International Spectrum Newsletter, there are two sections to it: HTML and Text. That way if you have preference of one over the other, or you are displaying the e-mail on a mobile device, it still displays nicely.

To add both HTML and Text to your e-mail body, you have to create what is called a multipart e-mail. Much like everything else, this is pretty easy, but is also really easy to break if you are not careful.

The first thing to understand about multipart emails, is that you can nest multipart sections within multipart sections. That is how attachments work, which we will also get into later.

The Content-Type

If you remember from the first article, I talked about the e-mail header "Content-Type". This header defines how to process the information within the body of the e-mail. When working with multipart sections, you have to specify the Content-Type as "multipart/alternative" and then supply a boundary id that our information will be in.

Boundaries can be anything you would like, but must be unique within the e-mail. That is right, within that e-mail. You can use the same boundary tag in all your e-mails if you like, but generally the boundary tag is based on the current date, time, and message Id. An example of a boundary tag is:

68734-812jasj-o871lnl8la

Does that mean anything? No. It is a bunch of random characters that are unique within the e-mail. To supply the boundary id, you add it to the end of the "Content-Type".

Content-Type: multipart/alternative; boundary="68734-812jasj-o871lnl8la"

Now, you define the boundaries sections in your e-mail, but placing a "--" in front the boundary id to start the section, define the Content-Type for that section, add a blank line, and then add your information into the boundary. To start the second section, third section, and so on, you would just repeat the process. Once you are done with all the boundaries, you place the boundary id at the end with "--" on the front and back. See figure 1 for an example.

Content-type: multipart/alternative;
boundary="68734-812jasj-o871lnl8la"

--68734-812jasj-o871lnl8la
Content-Type: text/plain

Hello, this is plain text

--68734-812jasj-o871lnl8la
content-Type: text/html

<html><body>
<p>Hello, this is Html Text</p>
</body></html>

--68734-812jasj-o871lnl8la--
Fig. 1


 

Gotchas!

There is a big gotcha here. You have to place the HTML and TEXT in the preferred order of display. What this means if you preferred the HTML to be display over the TEXT section, then you must place the HTML section as the last in the list. If you prefer the TEXT section to be display over the HTML, then that must be the last one listed.

This won't guarantee that the HTML will be displayed over TEXT, since this is a setting on the Recipient's e-mail client, but if the Recipient has not defined a preferred display type, then your preferred display method will be used.

Now why would you display TEXT over HTML? Wouldn't you want your HTML to always be preferred over the TEXT? Well… mobile phones. While a mobile phone will display HTML e-mail, most HTML emails are designed for a desktop client, not a small two-inch screen. If you are know this is going to a mobile device, then I would recommend place the TEXT as the preferred display, as TEXT will display cleaner on a mobile phone.

Including Different Languages

The nice thing about multipart emails, is you can send your e-mail in different languages, and the recipient can decide which language they want to display the e-mail in. Again, this is not difficult to do, but it means you have to make sure you provide the information about the languages included in the e-mail.

In order to do this, you have to create a multipart/alternative section to define each of the languages that can be displayed. You will also have to include a header that defines language for each section. See figure 2 for an example.

Content-type: multipart/alternative; 
boundary="68734-812jasj-o871lnl8la"'
differences=Content-Language
Content-Language: en, fr, de
--68734-812jasj-o871lnl8la
content-Type: text/plain
Content-Language: fr

Bonjour, ceci est du texte brut

--68734-812jasj-o871lnl8la
content-Type: text/plain
Content-Language: de

Hej, dette er almindelig tekst

--68734-812jasj-o871lnl8la
content-Type: text/plain
Content-Language: en

Hello, this is plain text

--68734-812jasj-o871lnl8la--

Fig. 2

C ontent Encoding

When you write your body, you don't have to encode your information in any specific formats unless you want to. By default, the e-mail client will assume the content is in a 7-bit format, which means that all the characters included in the e-mail are between ASCII 0-128.

Well, that is not a problem, correct? That is all the visible characters we care about… except when you have Unicode characters in your e-mail. Then you should define the emails are 8-bit encoding.

To define your content encoding, you add the following e-mail header right after the "content-type" header: "content-encoding: 8bit" There are limitations to 7-bit and 8-bit encoding. Each line of your e-mail can not exceed 998 characters. The likelihood that you run into this is pretty slim, but it does exist.

Another encoding type you can use is Quoted-Printable. While you don't need it, it can come in handy when you want to provide line wrapping on your TEXT section of your e-mail. The main issue with TEXT only is that you either provide line breaks yourself, or then hope the e-mail client is displaying that many characters on the screen or you keep your paragraphs all on one line, and hope you don't hit the 998 character limit for 7-bit and 8-bit encoding.

To get around this, you can use the "Quoted-Printable" encoding. The encoding works like the this: No line will exceed 79 characters, any line of text that is part of a line paragraph will include a '=' on the end to identify it as part of the next line of text; ASCII 33-60 AND 62-126 will be left alone, but any other character will be encoded with a '=' and hex value. See figure 3 for an example.

Encoded:

To illustrate the =
Various rules for encoding,=20the=20following=20=
Example uses a little of

everything

Decode:
To illustrate the Various rules for encoding, the 
following Example uses a little of

everything

Fig. 3

In the next issue we will take a look at addition attachments to your e-mail.

NATHAN RECTOR

View more articles
menu
menu