Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Get The TCP/IP Guide for your own computer.
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Key Applications and Application Protocols
           9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
                9  TCP/IP Electronic Mail System: Concepts and Protocols (RFC 822, MIME, SMTP, POP3, IMAP)
                     9  TCP/IP Electronic Mail Message Formats and Message Processing: RFC 822 and MIME
                          9  TCP/IP Enhanced Electronic Mail Message Format: Multipurpose Internet Mail Extensions (MIME)

Previous Topic/Section
MIME Composite Media Types: Multipart and Encapsulated Message Structures
Previous Page
Pages in Current Topic/Section
12
3
Next Page
MIME Extension for Non-ASCII Mail Message Headers
Next Topic/Section

MIME Content-Transfer-Encoding Header and Encoding Methods
(Page 3 of 3)

base64 Encoding

In contrast, the base64 encoding is more often used for raw binary data that is not in human-readable form anyway, such as graphical images, audio, video and application files. The idea behind it is simple: the data that needs to be sent can have any value for each 8-bit byte, which is not allowed. So, why not rearrange the bits so the data “fits” into the 7-bit ASCII limits of RFC 822?

This is done by processing the data to be sent three bytes at a time. There are 24 bits in each three-byte block, which are carved into 4 sets of 6 bits each. Each 6-bit group has a value from 0 to 63, and is represented by a single ASCII character as presented in Table 249.


Table 249: MIME Base64 Encoding Groups

6-bit Value

Encoding

6-bit Value

Encoding

6-bit Value

Encoding

6-bit Value

Encoding

0

A

16

Q

32

g

48

w

1

B

17

R

33

h

49

x

2

C

18

S

34

i

50

y

3

D

19

T

35

j

51

z

4

E

20

U

36

k

52

0

5

F

21

V

37

l

53

1

6

G

22

W

38

m

54

2

7

H

23

X

39

n

55

3

8

I

24

Y

40

o

56

4

9

J

25

Z

41

p

57

5

10

K

26

a

42

q

58

6

11

L

27

b

43

r

59

7

12

M

28

c

44

s

60

8

13

N

29

d

45

t

61

9

14

O

30

e

46

u

62

+

15

P

31

f

47

v

63

/


For example, suppose the first three bytes of the data to be sent were the decimal values 212, 39 and 247. These cannot all be expressed in 7-bit ASCII. In binary form they are:

11010100 00100111 11110111

We can divide these into four 6-bit groups:

110101 - 00 0010 - 0111 11 - 110111

Which yields the four values 53, 2, 31 and 55. Thus, the values 214, 39 and 247 would be encoded as the three ASCII characters “1Cf3”. The conceptual steps of this process are shown in Figure 303.


Figure 303: MIME Base64 Encoding

In this simplified example, three binary data bytes are encoded as four ASCII characters using MIME base64 encoding. Instead of transmitting those three bytes, two of which would not be valid in RFC 822, the four ASCII characters “1Cf3” are sent.

 


Note: The sequence of steps for the encoding that I mentioned above and showed in the figure are intended to help you understand the process. Computers inherently deal directly with bits, and so would not bother with converting to decimal before encoding the 6-bit groups into ASCII characters.


This 3-to-4 encoding is done for all the data. The converted ASCII characters are then placed into the body of the entity instead of the raw binary data, 76 characters to a line. I showed how this is done in the second body part in the example of Table 248 (except I didn't put 76 characters per line, to keep the line lengths short). One final character is involved in this scheme, the equal sign (“=”), which is used as a padding character when needed.

Since base64 characters are regular ASCII, they appear to SMTP like a “regular text message”. Of course the data looks like gibberish to us, but that's not a problem since it will be converted back to its regular form and displayed to the recipient as an image, movie, audio or whatever.

Key Concept: MIME uses base64 encoding to transform arbitrary 8-bit files into a form that is acceptable for communication in e-mail. Each set of three 8-bit bytes is divided into four 6-bit groups, and each 6-bit group represented by an ASCII character. Since the data is ASCII, it conforms to the RFC 822 message format standard, even if it is not human-readable. The receiving device reverses the encoding, changing each four-character block back into three 8-bit bytes.


The main drawback of the base64 method? It is about 33% less efficient than sending binary data directly, using something like FTP. The reason is that three 8-bit bytes of binary data are sent as four ASCII characters, but of course, each ASCII character is represented using 8 bits itself. So there is 1/3 extra overhead when using base64. In most cases this is not a big deal, but it can be significant if downloading very large e-mail files over a slow Internet connection.

Note that RFC 2046 also defines two other encodings: ietf-token and x-token. These are included to allow new encoding types to be defined in the future.


Previous Topic/Section
MIME Composite Media Types: Multipart and Encapsulated Message Structures
Previous Page
Pages in Current Topic/Section
12
3
Next Page
MIME Extension for Non-ASCII Mail Message Headers
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.