This test data is part of rfc2045 which includes all characters a~z A~Z, 0~9 and all symbols, It is used to test java.util.Base64.Encoder, and will be encoded by org.apache.commons.codec.binary.Base64.java to test java.util.Base64.Decoder; Freed & Borenstein Standards Track [Page 1] RFC 2045 Internet Message Bodies November 1996 These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Table of Contents 1. Introduction ......................................... 3 2. Definitions, Conventions, and Generic BNF Grammar .... 5 3. MIME Header Fields ................................... 8 4. MIME-Version Header Field ............................ 8 5. Content-Type Header Field ............................ 10 6. Content-Transfer-Encoding Header Field ............... 14 7. Content-ID Header Field .............................. 26 8. Content-Description Header Field ..................... 27 9. Additional MIME Header Fields ........................ 27 10. Summary ............................................. 27 11. Security Considerations ............................. 27 12. Authors' Addresses .................................. 28 A. Collected Grammar .................................... 29 Freed & Borenstein Standards Track [Page 7] RFC 2045 Internet Message Bodies November 1996 3. MIME Header Fields MIME defines a number of new RFC 822 header fields that are used to describe the content of a MIME entity. These header fields occur in at least two contexts: (1) As part of a regular RFC 822 message header. (2) In a MIME body part header within a multipart construct. The formal definition of these header fields is as follows: MIME-message-headers := entity-headers fields version CRLF ; The ordering of the header ; fields implied by this BNF ; definition should be ignored. MIME-part-headers := entity-headers [ fields ] ; Any field not beginning with ; "content-" can have no defined ; meaning and may be ignored. ; The ordering of the header ; fields implied by this BNF ; definition should be ignored. The syntax of the various specific MIME header fields will be described in the following sections. Freed & Borenstein Standards Track [Page 11] RFC 2045 Internet Message Bodies November 1996 5.1. Syntax of the Content-Type Header Field In the Augmented BNF notation of RFC 822, a Content-Type header field value is defined as follows: content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive. type := discrete-type / composite-type discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token composite-type := "message" / "multipart" / extension-token extension-token := ietf-token / x-token ietf-token := x-token := subtype := extension-token / iana-token iana-token := parameter := attribute "=" value attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. value := token / quoted-string token := 1* tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values description := "Content-Description" ":" *text encoding := "Content-Transfer-Encoding" ":" mechanism entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF ) hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; Octet must be used for characters > 127, =, ; SPACEs or TABs at the ends of lines, and is ; recommended for any character not listed in ; RFC 2049 as "mail-safe". RFC 2045 Internet Message Bodies November 1996 must be used. An equal sign as the last character on a encoded line indicates such a non-significant ("soft") line break in the encoded text. Thus if the "raw" form of the line is a single unencoded line that says: Now's the time for all folk to come to the aid of their country. This can be represented, in the Quoted-Printable encoding, as: Now's the time = for all folk to come= to the aid of their country. Since the hyphen character ("-") may be represented as itself in the Quoted-Printable encoding, care must be taken, when encapsulating a quoted-printable encoded body inside one or more multipart entities, to ensure that the boundary delimiter does not appear anywhere in the encoded body. (A good strategy is to choose a boundary that includes a character sequence such as "=_" which can never appear in a quoted-printable body. See the definition of multipart messages in RFC 2046.) !"#$@[\]^`{|}~% Freed & Borenstein Standards Track [Page 24] RFC 2045 Internet Message Bodies November 1996 Table 1: The Base64 Alphabet Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y