NIH Library in Building 10 |
|
Table of Contents
Why Are Attachments Encoded?
Internet e-mail and Usenet news posts were designed for plain text messages. As
such, many systems expect the messages to only contain printable characters
from the 7-bit (first bit of the 8-bit byte is always zero) ASCII character
set. These programs can have problems if the message includes extended 8-bit
(the first bit is a one) characters, such as the various accented letters. This
also poses a problem for sending files, such as images, sound, video,
spreadsheets and programs which can contain any combination of 8-bit binary
data. This even poses a problem for formatted documents, since many word
processors embed binary control fields in the files.
The way around this limitation is to encode the binary data (attachment) into
ASCII characters before sending. To the mail and news systems that the messages
travels through, the file is just so much text. At the receiving end, the
message is decoded back into the original file, none-the-worse for the
experience. Many mail and news programs automate the encoding and decoding.
However, sometimes a separate program may be required. encode decoded
The nice thing about Standards is there are so many to choose from. Encoding is
no exception. Among the more popular are: Uuencode, MIME, Base64,
Quoted-Printable and Binhex. There are other less common methods as well.The
nice thing about Standards is there are so many to choose from.
It should be noted that encoding is not the same as encryption. The purpose of
encoding is to allow some information to be stored in, or pass through, a
medium that can't handle the data directly. The purpose of encryption is
prevent unauthorized persons from view or using some information. It's possible
for a message to use both encoding and encryption. encoding encryption
encoding encryption
Top of page Top of section
Uuencode
Uuencode (Unix-to-Unix Encode), as its name implies, comes from the Unix world.
It was commonly used to encode files transmitted from one Unix computer to
another. Since the early Internet consisted almost entirely of computers
running the Unix operating system, it's not surprising that Uuencode is widely
used. Today, almost all computer platforms have programs capable of
encoding/decoding using Uuencode.
Most mail and news programs can decode Uuencode. However, not all of them can
encode it. Most mail systems will pass Uuencode without problems. If you don't
know your recipient's capabilities, Uuencode is a good first guess. Uuencode is
more common in news than mail. MIME is making inroads in mail faster than news.
Uuencode results in a transmitted message about 42% larger than the original
file. This is typical of the encoding penalty.
Below
shows how the image to the right would look if Uuencoded. The first line starts
with the word "begin". The "644" represents the Unix file
permissions (read/write/execute). This is largely ignored by other operating
systems. In this example, "http://nihlibrary.nih.gov/gifs/a.gif" is
the file name.
The encoded file follows. Most lines begin with an "M" (representing
the line length) and 60 characters of data. The last data line is usually
shorter, and therefore starts with a different character. The end of the
encoding has "`" on a line by itself and then the word
"end" on a line by itself.
begin 644 a.gif
M1TE&.#EA)0`H`+,``.P`2QBQ`/__________________________________
M_____________________RP`````)0`H```$5S#(2:N]..O-N_]@*(YD:9YH
MB@(LH%ZM^U;Q3,6L+>6MW@>_5VXW%,J`Q500>5PUF:HE\4F20ITX'#:K-5FG
;WB3MZR&#J^(QM9RVF'7PN'Q.K]OO^+Q^!``[
`
end
MIME
MIME (Multipurpose Internet Mail Extensions) is not actually a method for
encoding attachments. Rather, it deals with the overall structure of a message.
A message using MIME doesn't necessarily include attachments. If it does
include attachments, they most often use Base64 encoding, or sometimes
Quoted-Printable encoding. Theoretically, MIME could even use Uuencode, Binhex,
or other methods, but that is both rare and frowned upon in the MIME standards
(RFC 2045).
The main advantage of MIME is that it provides a consistent way for the sending
program to describe the message contents to the receiving program. The original
Internet mail message specification (RFC 822) just describes simple text
messages. The message might include an encoded attachment, but it's up to the
receiving program to find it in the midst of the message text.
Most newer mail and news programs support MIME. However, older programs don't.
And some older mail and news servers either remove or mutilate some of the MIME
headers, rendering the message unintelligible to a receiving MIME capable
program. Due to its flexibility and power, MIME is the best choice if all
parties can handle it.
Some mail and news programs present a choice between Uuencode and MIME
encoding. This is a bit misleading and confusing. The Uuencode choice usually
means to use a simple mail message (none of the MIME message headers), and to
Uuencode any attachments. The MIME choice means to use the MIME headers, and
use Base64 or Quoted-Printable for attachments.
The distinguishing characteristic of a MIME message is the presence of the MIME
headers. These are normally invisible in a MIME capable reader, but can be seen
in the message source. Below are shown some typical MIME headers. The
"MIME-Version:" header is present in all messages using MIME. The
others are specific to the attachments or other contents. A MIME message may
have multiple attachments of various types.
MIME-Version: 1.0
Content-Description: "Base64 encode of a.gif by Wincode 2.7.3"
Content-Type: image/gif; name="a.gif"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="a.gif"
Although the MIME name specifies "Internet Mail", the same
considerations also apply to news. And some parts of MIME are also used by Web
Browsers. In particular, the web servers use the Content-Type
("image/gif" in the above example) to identify the type of file being
sent to the browser so that the browser can determine how to handle it.
However, since the browser protocol (http) supports binary transfers, the
encoding issues don't apply there. (For more information on Content-Type, see:
RFC 2046 and MIME Types)
Top of page Top of section
Base64
Base64 is the preferred encoding method for attachments in messages using MIME.
However, in some cases Quoted-Printable is used instead. Although Base64 could
be used without MIME, this is rare.
Base64 results in a transmitted message about 37% larger than the original
file. This is typical of the encoding penalty, but slightly more efficient than
Uuencode.
Below
shows how the image to the right would look if using Base64 encoding. The MIME
headers provide all the descriptive information. This includes the file name,
its type, and that Base64 encoding is used.
MIME-Version: 1.0
Content-Description: "Base64 encode of a.gif by Wincode 2.7.3"
Content-Type: image/gif; name="a.gif"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="a.gif"
R0lGODlhJQAoALMAAOwASxixAP//////////////////////////////////////////////////
/////ywAAAAAJQAoAAAEVzDISau9OOvNu/9gKI5kaZ5oigIsoF6t+1bxTMWsLeWt3ge/V243FMqA
xVQQeVw1maol8UmSQp04HDarNVmn3iTt6yGDq+IxtZy2mHXwuHxOr9vv+Lx+BAA7
Quoted-Printable
Quoted-Printable is used to encode some attachments in messages using MIME.
Quoted-Printable leaves printable ASCII characters alone and only encodes those
characters (bytes) that might get lost or converted in transit.
If the attachment consists mostly of printable ASCII characters, the MIME
program may automatically select quoted-printable over Base64, since this would
be much more efficient. In the best case, Quoted-Printable results in a
transmitted message only about 3% larger than the original file. However, in
the worst case, the transmitted message could be about 200% larger than the
original file. So it's important to only use this encoding method on suitable
files.
Although Quoted-Printable may be used for attachments, it is more often used
for the main message text. The mail or news program may offer the option to
encode the text using Quoted-Printable. There are two advantages to this. 1)
Characters outside of the normal printable ASCII can be safely transmitted.
This includes some special characters, and letters from some foreign alphabets.
2) The intended paragraph layout can be preserved. Simple text messages are
arbitrarily chopped into suitable chunks (typically 70-80 characters per line)
by the sending program. Quoted-Printable allows the logical lines to exceed the
physical line limits of the mail or news transport. It places a hard carriage return
(line break) only at the end of a paragraph. The receiving program can then
reflow the paragraph to the viewing window. Not all receiving programs support
wrapping. This may result in each paragraph being displayed as a single line
making the message difficult to read. And some programs will wrap the text for
display, but not for printing.
Some mail and news servers may automatically convert any messages that contain
8-bit characters into quoted-printable encoding as the message passes through
them.
The following sample text
This is a example of a quoted-printable text file. This might contain some
special characters such as:This is a example
of a quoted-printable text file. This might contain some special characters
such as:
equal sign =, dollar sign $, or even extended characters such as the cent sign
¢ or foreign characters ÀÆß
is shown below as it would look if using Quoted-Printable encoding. An equal
sign "=" at the end of a line indicates a soft carriage-return. The
receiving program should remove it and flow the following line into this one.
an "=20" at the end of a line represents a Space. Normally, trailing
spaces on a line are removed in transit. This causes them to be preserved. And
finally, an equal sign followed by 2 hexadecimal characters (0-9, A-F)
represent an extended character.
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This is a example of a quoted-printable text file. This might contain =
some special characters such as:=20
equal sign =3D, dollar sign $, or even extended characters such as the =
cent sign =A2 or foreign characters =C0=C6=DF
If the recipient's mail or news program can't handle
quoted-printable (many older ones can't), the message will look peculiar with
all the equal signs and hexadecimal encoding, but it is still largely readable.
Top of page Top of section
Binhex
Binhex is most often used with the Macintosh. Although Binhex decoders are
available for other platforms few people have them. Binhex is a reasonable
choice for encoding if both the sender and recipient are using Macs. However,
in any other case another encoding method should be used.
Unlike most other methods, Binhex encodes the file name and other information
along with the data.
Also, unlike most other methods, Binhex has a built-in compression capability.
It's possible that a highly compressible file could result in a smaller
transmitted message than the original file. However, you will generally get
better results by compressing the file first with a standard compression
utility. For an already compressed file, Binhex results in a transmitted
message about 40% larger than the original file. This is typical of the
encoding penalty, but slightly less efficient than Base64.
Below
shows how the image to the right would look if using Binhex encoding. The first
line, rather obviously, indicates the encoding method.
(This file must be converted with BinHex 4.0)
:"@%ZCfPQ!&4&@&4YC'pc!*!&SJ#3"*!!bNG*4MJjB58!+!#c!!$X!%XBX3$rN#S
X!*!%*3!S!!!%9c$)5DZp11[0ZrpJ+)jNDCjSLJ)XS&kYqeEa6-@X,H@YhJHr9fi
h&-U!a933H9`eQDSPm8Q53Tdi($DV09QRhL6Ykb'$Uq)aYCbfQ(A`Z(a1Vp[[q,a
q"!!lU1B!!!!!:
Other
Encoding Methods
In addition to the most common encoding methods discussed above, you might
encounter several other methods of encoding attachments, or several things that
look similar to encoded attachments. The following should help you identify
what you've got.
Binary, 8-Bit, Raw
Below
shows how the image to the right might look if using Binary, 8-bit, or Raw
encoding. This does not actually encode the file, but rather includes the data
without any conversion. Some mail and news programs allow you to do this or you
might be able to paste the file or concatenate it into the message text without
conversion. However, Internet mail and news transports don't guarantee to
transmit the file without alteration. It's quite possible that the message will
get truncated because some combination of characters look like an end of
message indication. It might even result in a corrupted mail folder on the mail
server or the recipient's mail program. It's unlikely that the recipient will
be able to use the file unless it was a text file to begin with. If you receive
such a file, you might as well throw it away and ask the sender to try again.
BTOA
Below
shows how the image to the right might look if using BTOA encoding. This is
rarely seen on the Internet today.
xbtoa5 78 a.gif Begin
7nH003FO36-igRR!:0\Y(pO)@s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s"<
"-M!!";F-ia5M="q]eX1^LYc+F!`.#qhPSnNu_/>-=Oqc<5\`N1ZQXkj;t=)Kr2b(.H1&:%M<RAqS,
'8WlE23#jiW2-Hj6,jjn@K<*ud[@F[mFmung:9WF@pq2%Y!':/\E
xbtoa End N 162 a2 E 26 S 3a3f R 7626cb65
BOO
Below
shows how the image to the right might look if using BOO encoding. This is
rarely seen on the Internet today.
A.GIF
AdU6>3UQ9@0X0;<00>`0BaRa0?oooooooooooooooooooooooooooooooooooooooooooooooooo
ooooob`0~39@0X~215L`b4V[_CS[cK_oH2R>I6VNJ8X2;:1N[O]FlDc5[2gU[Mh7_eM^=aC:P<ED
47UL=IVZ9O59TT:M>1`fZcEIYmhTkN\QPj_R<KFL]YQel;QlCZoKkoRlOP@0>`00
ROT-13
ROT-13 is not a encoding format for attachments. It is a simple encryption for
text. It Rotates each letter of the alphabet 13 positions. "A" and
"N" are exchanged, "B" and "O" are exchanged,
etc. Numbers, spaces and punctuation are not changed. Because it is so simple,
its purpose is not security. Rather, it is used so that others don't
accidentally read a message that they don't want to. It was most often used for
messages of questionable taste. Some news readers have ROT-13 decoding
built-in. It is rarely used on the Internet today. Below is a sample of a
message using ROT-13 encoding.
Guvf vf n fnzcyr bs n zrffntr rapbqrq hfvat EBG-13 rapbqvat.
Orpnhfr bs gur fvzcyr angher bs gur rapelcgvba, vgf checbfr
vf abg frphevgl ohg gb cerirag nppvqragny ernqvat.
MS-TNEF WINMAIL.DAT Attachments
Mail programs in the Microsoft Exchange family, which includes Windows
Messaging, Outlook97, Outlook98 and Outlook2000, will include a TNEF (Transport
Neutral Encapsulation Format) attachment named WINMAIL.DAT when then sender
selects, or defaults to, RTF (Rich Text Format). If the sender is using MIME
formatting, this attachment will have Content-Type: application/ms-tnef. Content-Type:
application/ms-tnef
The TNEF attachment includes a Rich Text Format (e.g. bold, underline, fonts)
version of the plain text message. If the sender has included any attachments
(e.g. pictures, spreadsheets, programs), they will be embedded within the TNEF
attachment and not as separate attachments.
Most other mail programs do not know how to handle the TNEF attachments and so
Exchange family users should avoid using RTF unless they know that the
recipient has a compatible program. For more information on this, see the
following articles: OL98: Attachments Not Visible to Some Recipients When Using
TNEF, XCLN: Sending Messages In Rich-Text Format, XFOR: Preventing WINMAIL.DAT
Sent to Internet Users, Sending RTF with Attachment as MIME Loses Attachment
and XADM: POP3 Users may not Receive an Attachment if Part of DL.
Fentun
Fentun is a freeware TNEF Attachment Extractor. It is available for the
Win95/98/NT4 and Linux operating systems. It does not show the RTF message
embedded in the TNEF attachment, but does let you see if there are any other
attachments within the TNEF attachment and let's you save them.
For Netscape Mail, Fentun can be installed as a Helper. Instructions are at the
Fentun web site.
Users of Microsoft IE3 Internet Mail, and IE4/IE5 Outlook Express will not see
any indication that they have recieved a TNEF attachment. Apparently, Microsoft
has decided that since these programs can't handle a TNEF attachment, it will
be hidden. In order get these programs to decode the TNEF attachment and make
it available to Fentun via the above file assocation, perform the following
steps:
HTML - Web Pages
HTML (Hyper Text Markup Language) is used to describe web pages. A web page
consits of one or more files. The main file is a text file that contains the
HTML formatting codes, usually most or all of the page text, links to any other
web pages and links to any images, animations, sound clips, etc. Each image,
animiation, sound clip, etc. is a separate file.
Some, but not all, mail and news programs can display HTML messages. Most that
can display HTML require that the message use MIME formatting and specify
Content-Type: text/html for the HTML message portion. Many programs that create
HTML messages specify Content-Type: multipart/alternative and include two
copies (attachments) of the message text. The first is the plain text version
of the message (Content-Type: text/plain), the second is the HTML version
(Content-Type: text/html). If a receiving program understands the MIME
multipart/alternative and HTML, it will display the HTML version in the message
body and hide the plain text one. If it doesn't understand HTML, it will
display the plain text version in the message body and hide the HTML one. If it
doesn't understand multipart/alternative it may display either or both message
copies as attachments. And if it doesn't understand MIME, it will display both
copies in the message body, but the HTML version will be difficult to read
because it will be the raw HTML with all the formatting codes displayed. Content-Type:
text/html Content-Type: multipart/alternative
Below is "A simple HTML message.":
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01BEA6E2.1A467F40"
This is a multi-part message in MIME format.
------=_NextPart_000_0059_01BEA6E2.1A467F40
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
A simple HTML message.
------=_NextPart_000_0059_01BEA6E2.1A467F40
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY>
<DIV>A simple <STRONG>HTML</STRONG> message.</DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0059_01BEA6E2.1A467F40--
The HTML capabilities of mail and news programs come in 3 levels:.
If a message's HTML features exceed the capabiliities of the
recipient's mail or news program, it is possible to save the HTML portion of
the message to an HTML file (.HTM or .HTML file extension) and then open in the
web browser. If the message used multipart/related, the images will need to
also be saved, possibly requiring manual Decoding. The HTML file will require
editing if multipart/related was used because the links are not normal file
names. Even in other cases, some edting may be required to make the HTML file
usable. Overall, this is a lot more bother than it is probably worth.
Top of page Top of section
Macintosh Notes - AppleSingle and
AppleDouble
Some Macintosh files consist of two parts:
A Macintosh mail or news program could encode attachments one or more of the following ways. Some may offer a choice, some will support only one of the following.
AppleSingle and AppleDouble attachments normally use MIME
formatted messages with Base64 encoding. The Data Fork only attachments could
use Base64, Uuencode or Binhex. For example, if the Macintosh program gives you
encoding options of AppleDouble, Base64 and Binhex, the Base64 and Binhex options
likely send only the Data Fork.
When a non-Macintosh user receives an AppleDouble attachment, they will most
likely see two attachments. Both attachments might have the same name (e.g.
photo.jpg), or the first attachment (Resource Fork) might have a generated name
(e.g. att0001.dat) while the second (Data Fork) has the real name (e.g.
photo.jpg). The first attachment is usually small (less than 10 KB). They will
likely get an error if they try to open the first attachment (unknown file type
or invalid file format). They should ignore the first attachment and just
open/save the second one.
You can verify the presence of AppleSingle or AppleDouble encoding by looking
at the message source. AppleSingle will have a single attachment with a
"Content-type: application/applefile". AppleDouble will have a header
with a "Content-type: multipart/appledouble" followed by the Resource
Fork attachment with "Content-type: application/applefile" followed
by the Data fork attachment with a Content-type that depends on the actual file
type (e.g. "Content-type: image/jpeg").
Top of page Top of section
Compression and Message Size
Limits
Sometimes it is a good idea to compress the files before attaching. The
advantages of this are:
However, since compression does require a little extra work
on both the sender's and recipient's part, there are times when it isn't worth
the bother. If the file size is small (e.g. less than 40 KB) or a file type
that doesn't compress well (see above) and you are only sending one or two
files, I wouldn't compress them. Also take into consideration whether the
recipient will know how to uncompress the file.
There are several compression methods
ZIP
This is the most common compression method on DOS and Windows PCs. Programs are
also readily available to handle Zip files on other platforms. This is the best
choice of a compression method for DOS and Windows, as well as cross-platform
file transfers. PKWARE PKZIP/PKUNZIP is the standard DOS program for ZIP files.
They also have versions for Windows, OS/2 and Unix. There are also numerous DOS
and Windows front-end programs available to make the use of the DOS PKZIP
easier. Winzip is a popular Windows base Zip/Unzip program, that also has
decoding abilities. Info-ZIP has freeware Zip and Unzip programs for over 30
operating systems.
StuffIt - SITStuffIt - SIT
Aladdin Systems StuffIt is commonly used on Macs. Unstuffing utilities (e.g.
StuffIt Expander) are available for DOS and Windows PCs, but few people have
them. Utilities for creating SIT files are not commonly available on these
platforms. StuffIt Expander can also uncompress ZIP files as well as decode
Uuencode and Binhex.
TAR - CompressTAR - Compress
TAR (Tape ARchive) is the standard archive for Unix systems. This is often
combined with the standard Unix utility "compress". Compressed Unix
files typically have a file name ending in ".Z". TAR and Unix
"compress" compatible utilities are available for other platforms,
but few people have them.
For ZIP and other utilities, try these sites: ZDNET Hotfiles, SHAREWARE.COM,
c|net Download.Com, Filez.
Top of page Top of section
Encoding
Mechanics
Most newer mail and news programs provide automatic encoding of attachments.
You merely select the menu item or button for Attachment and then select the
file to attach. Or your operating system may provide a drag-and-drop or other
method to send a file. If your mail or news program supports more than one encoding
method, there will be an option to set the default encoding method. There may
also be the option to override the default encoding method when composing a
message. (Note: Some programs support more decoding methods than they do
encoding methods. For example, a program might always use MIME encoding in
sending, but be able to decode either MIME or Uuencoded attachments on
receipt.)
There are two cases where you might need or want to manually encode an
attachment: your program doesn't support attachments or the recipient's program
can't decode any of the encoding methods that your program supports.
Because MIME headers are integrated with the message headers, it would be
difficult, if not impossible, to manually insert a MIME encoded attachment in
an existing message such that the recipient's program would automatically
decode it. For this reason, Uuencode would be the best choice for manual
encoding.
When you manually encode a file, the encoder program produces a plain text
file. For example, the A.GIF file might get converted to A.UUE.
".UUE" is a common extension for Uuencoded files. However, the exact
name is unimportant since it should appear nowhere in the sent message. Once
you have the encoded file, you need to insert it as text into the body of the
message. The encoded file should appear along with your message text, as in the
following example.
Hi Bob,
Here's the image file that I promised you.
begin 644 a.gif
M1TE&.#EA)0`H`+,``.P`2QBQ`/__________________________________
M_____________________RP`````)0`H```$5S#(2:N]..O-N_]@*(YD:9YH
MB@(LH%ZM^U;Q3,6L+>6MW@>_5VXW%,J`Q500>5PUF:HE\4F20ITX'#:K-5FG
;WB3MZR&#J^(QM9RVF'7PN'Q.K]OO^+Q^!``[
`
end
Some people include a line, such as "------ CUT HERE
-----" before and after the encoded text. This is unnecessary. If the
recipient's program can decode the attachment type, it won't use those lines.
If the recipient has to manually cut the encoded text for decoding, after
they've done it once, it will be obvious to them what needs to be cut.
Notes: If you are manually encoding a file, be sure to Insert as Text and not
Attach the encoded file. If you attach the encoded file, it gets encoded a
second time. Not only does it make the resulting message larger than necessary,
but defeats the purpose of manual encoding. If the recipient could decode your
attachments in the first place, there would be no need for the manual encoding.
By attaching an already encoded file, you are forcing the recipient to double
decode it.Notes: manually Insert as Text Attach
If you manually Uuencode an attachment and insert that into a message that is
using MIME, that may allow a recipient whose program only supports Uuencode to
automatically decode it. However, if the recipient's program supports MIME, it
may not automatically decode such a message, even if that program also supports
Uuencode. That's because many programs don't expect MIME and Uuencode to be
used in the same message. They only look for Uuencoded attachments in messages
without any MIME headers.
If you are going to use compression, you compress the original file first. Then
either attach the compressed file (if using automatic encoding) or encode the
compressed file (if using manual encoding).
Top of page Top of section
Decoding Mechanics
Most newer mail and news programs provide automatic decoding of attachments.
However, your program might not support the encoding method used by the sender.
If your program can handle the decoding of more than one method, it will
usually automatically detect the message's method.
If your program automatically decoded an attachment, it will do one of several
things, depending on the program, your options, the type of file and/or how it
was attached.
You might need to manually decode an attachment. The reasons
for this include: The sender used an encoding method not supported by your mail
or news program; your mail or news server doesn't support MIME and removed some
critical MIME headers; the sender double encoded the attachment (see Encoding
Mechanics); and the original message was split into multiple parts (see
Compression and Message Size Limits)
If your mail or news program decodes an attachment, but it needs further
decoding, use the program's save attachment feature, then use the manual
decoder on that file (for an exception, see Multipart Messages below).
Otherwise you need to save the raw message as a plain text file. Most programs
have a File, Save As option to save a message to an external file. Although
they may give the file a special extension, these are normally plain text
files. Your manual decoder program might expect that the file has a special
extension, such as ".UUE", but this is usually not necessary.
It's a good idea to look at the saved file in your word processor to see what
you've got. Comparing the file to the examples in Uuencode, MIME, Base64,
Quoted-Printable, Binhex, and Other sections should allow you to identify the
type of encoding used.
Depending on the manual decoder program that you use, you may need to do some
editing of the saved file before decoding. You may need to remove message
headers (e.g. From:, Subject:, etc.) and normal message text. However, MIME
decoders generally expect the message headers, and Binhex decoders expect the
"(This file must be converted with BinHex 4.0)" line. Some better
decoder programs (e.g. Wincode) do a good job of ignoring what they don't need,
so that you rarely need to edit the file before decoding.
You might also need to tell the decoder program the type of encoding used, or
select a different decoder program based on the type of encoding. Wincode
version 2.7.3 or later does a good job of determining the encoding type if set
to "AUTO-1" decoding. (However, some files use Base64 with incomplete
or no MIME headers. In that case you will need to manually strip the file of
any headers before decoding and set Wincode to decode Raw Base64.)
Multipart Messages
Because of message size limits imposed by some ISPs (see Compression and
Message Size Limits), larger attachments may have been split into multiple
messages. Since decoding is the reverse of encoding, you must perform the steps
in the reverse order. The original file was first encoded, then split into
multiple messages. So you must first combine the multiple messages, then decode
it.
Some news programs (but fewer mail programs) may automatically identify the
message parts, combine them and decode. Some others may allow you to identify
the parts and order them, then the program will decode it. However, in many
cases, you will need to manually save the parts and then decode it.
Your mail or news program may automatically decode the first message part.
However, that doesn't do you any good. There is no practical way to combine
that already decoded part with the rest of the parts. You will need to save
each part (including the first) as a plain text file (as discussed above), then
decode that. Your program may allow you to select all the parts and save as a
single text file. If not, save each message part as a separate file. If you
give the individual parts names such as FILE1.UUE, FILE2.UUE, FILE3.UUE, etc.
then tell Wincode to decode FILE1.UUE, it will automatically find the other
parts for decoding. For some decoders it may be necessary to use your word
processor (or other program) to combine the individual parts into a single file
before decoding.
For Wincode and other decoding utilities, try these sites: ZDNET Hotfiles,
SHAREWARE.COM, c|net Download.Com, Filez. Winzip also includes decoding
functions. Aladdin Systems StuffIt Expander can also decode Uuencode and
Binhex.
Top of page Top of section
Problems and Complications
If there weren't problems and complications, you wouldn't be reading this. Most
of these are caused by incompatibilities between the sending and receiving
program. Another source of problems is the sender's lack of understanding of
encoding. One or more of the following may apply to the problem message.
If your program has a View Message Source option you should be able to quickly tell if there is any attachment there. If there is an attachment, or you don't have that option, you will need to save the message and then manually decode it. See the Decoding Mechanics section. If this is a mail message, it might be possible that in the future the sender could use an encoding method common to both your programs. However, depending on the programs used, there might not be a common method.
Notes
on Mail and News Programs
Disclaimer:Program features are subject to change without notice. Different
versions of a program on the same or different platforms may have different
features. For example, the Macintosh version might support both encoding and
decoding using Binhex, while the Windows version might support only decoding
Binhex, or not support Binhex at all.Disclaimer:
Notes on
Service Providers
Disclaimer: Information in this section is based on rumor and innuendo. Service
features are subject to change without notice. Users on the same service may
have different software or versions. The service on different platforms may
have different features.Disclaimer:
Some of the links below are restricted to members of the service.
Comments to NIHLibrary@nih.gov
News | NIH Library | O R S | N I H | Disclaimer | Accessibility |