1 This test data is part of rfc2045 which includes all characters a~z A~Z, 0~9 and all symbols,
2 It is used to test java.util.Base64.Encoder, and will be encoded by org.apache.commons.codec.binary.Base64.java
3 to test java.util.Base64.Decoder;
4
5 Freed & Borenstein Standards Track [Page 1]
6 RFC 2045 Internet Message Bodies November 1996
7
8 These documents are revisions of RFCs 1521, 1522, and 1590, which
9 themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
10 2049 describes differences and changes from previous versions.
11
12 Table of Contents
13
14 1. Introduction ......................................... 3
15 2. Definitions, Conventions, and Generic BNF Grammar .... 5
16 3. MIME Header Fields ................................... 8
17 4. MIME-Version Header Field ............................ 8
18 5. Content-Type Header Field ............................ 10
19 6. Content-Transfer-Encoding Header Field ............... 14
20 7. Content-ID Header Field .............................. 26
21 8. Content-Description Header Field ..................... 27
22 9. Additional MIME Header Fields ........................ 27
23 10. Summary ............................................. 27
24 11. Security Considerations ............................. 27
25 12. Authors' Addresses .................................. 28
26 A. Collected Grammar .................................... 29
27
28 Freed & Borenstein Standards Track [Page 7]
29 RFC 2045 Internet Message Bodies November 1996
30
31 3. MIME Header Fields
32
33 MIME defines a number of new RFC 822 header fields that are used to
34 describe the content of a MIME entity. These header fields occur in
35 at least two contexts:
36
37 (1) As part of a regular RFC 822 message header.
38
39 (2) In a MIME body part header within a multipart
40 construct.
41
42 The formal definition of these header fields is as follows:
43
44 MIME-message-headers := entity-headers
45 fields
46 version CRLF
47 ; The ordering of the header
48 ; fields implied by this BNF
49 ; definition should be ignored.
50
51 MIME-part-headers := entity-headers
52 [ fields ]
53 ; Any field not beginning with
54 ; "content-" can have no defined
55 ; meaning and may be ignored.
56 ; The ordering of the header
57 ; fields implied by this BNF
58 ; definition should be ignored.
59
60 The syntax of the various specific MIME header fields will be
61 described in the following sections.
62
63 Freed & Borenstein Standards Track [Page 11]
64 RFC 2045 Internet Message Bodies November 1996
65
66 5.1. Syntax of the Content-Type Header Field
67
68 In the Augmented BNF notation of RFC 822, a Content-Type header field
69 value is defined as follows:
70
71 content := "Content-Type" ":" type "/" subtype
72 *(";" parameter)
73 ; Matching of media type and subtype
74 ; is ALWAYS case-insensitive.
75
76 type := discrete-type / composite-type
77
78 discrete-type := "text" / "image" / "audio" / "video" /
79 "application" / extension-token
80
81 composite-type := "message" / "multipart" / extension-token
82
83 extension-token := ietf-token / x-token
84
85 ietf-token := <An extension token defined by a
86 standards-track RFC and registered
87 with IANA.>
88
89 x-token := <The two characters "X-" or "x-" followed, with
90 no intervening white space, by any token>
91
92 subtype := extension-token / iana-token
93
94 iana-token := <A publicly-defined extension token. Tokens
95 of this form must be registered with IANA
96 as specified in RFC 2048.>
97
98 parameter := attribute "=" value
99
100 attribute := token
101 ; Matching of attributes
102 ; is ALWAYS case-insensitive.
103
104 value := token / quoted-string
105
106 token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
107 or tspecials>
108
109 tspecials := "(" / ")" / "<" / ">" / "@" /
110 "," / ";" / ":" / "\" / <">
111 "/" / "[" / "]" / "?" / "="
112 ; Must be in quoted-string,
113 ; to use within parameter values
114
115 description := "Content-Description" ":" *text
116
117 encoding := "Content-Transfer-Encoding" ":" mechanism
118
119 entity-headers := [ content CRLF ]
120 [ encoding CRLF ]
121 [ id CRLF ]
122 [ description CRLF ]
123 *( MIME-extension-field CRLF )
124
125 hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
126 ; Octet must be used for characters > 127, =,
127 ; SPACEs or TABs at the ends of lines, and is
128 ; recommended for any character not listed in
129 ; RFC 2049 as "mail-safe".
130
131 RFC 2045 Internet Message Bodies November 1996
132
133 must be used. An equal sign as the last character on a
134 encoded line indicates such a non-significant ("soft")
135 line break in the encoded text.
136
137 Thus if the "raw" form of the line is a single unencoded line that
138 says:
139
140 Now's the time for all folk to come to the aid of their country.
141
142 This can be represented, in the Quoted-Printable encoding, as:
143
144 Now's the time =
145 for all folk to come=
146 to the aid of their country.
147
148 Since the hyphen character ("-") may be represented as itself in the
149 Quoted-Printable encoding, care must be taken, when encapsulating a
150 quoted-printable encoded body inside one or more multipart entities,
151 to ensure that the boundary delimiter does not appear anywhere in the
152 encoded body. (A good strategy is to choose a boundary that includes
153 a character sequence such as "=_" which can never appear in a
154 quoted-printable body. See the definition of multipart messages in
155 RFC 2046.)
156
157 !"#$@[\]^`{|}~%
158
159 Freed & Borenstein Standards Track [Page 24]
160
161 RFC 2045 Internet Message Bodies November 1996
162
163
164 Table 1: The Base64 Alphabet
165
166 Value Encoding Value Encoding Value Encoding Value Encoding
167 0 A 17 R 34 i 51 z
168 1 B 18 S 35 j 52 0
169 2 C 19 T 36 k 53 1
170 3 D 20 U 37 l 54 2
171 4 E 21 V 38 m 55 3
172 5 F 22 W 39 n 56 4
173 6 G 23 X 40 o 57 5
174 7 H 24 Y 41 p 58 6
175 8 I 25 Z 42 q 59 7
176 9 J 26 a 43 r 60 8
177 10 K 27 b 44 s 61 9
178 11 L 28 c 45 t 62 +
179 12 M 29 d 46 u 63 /
180 13 N 30 e 47 v
181 14 O 31 f 48 w (pad) =
182 15 P 32 g 49 x
183 16 Q 33 h 50 y