1This test data is part of rfc2045 which includes all characters a~z A~Z, 0~9 and all symbols, 2It is used to test java.util.Base64.Encoder, and will be encoded by org.apache.commons.codec.binary.Base64.java 3to test java.util.Base64.Decoder; 4 5Freed & Borenstein Standards Track [Page 1] 6RFC 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 12Table 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 28Freed & Borenstein Standards Track [Page 7] 29RFC 2045 Internet Message Bodies November 1996 30 313. 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 63Freed & Borenstein Standards Track [Page 11] 64RFC 2045 Internet Message Bodies November 1996 65 665.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 131RFC 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 159Freed & Borenstein Standards Track [Page 24] 160 161RFC 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 184