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 := <An extension token defined by a | |
standards-track RFC and registered | |
with IANA.> | |
x-token := <The two characters "X-" or "x-" followed, with | |
no intervening white space, by any token> | |
subtype := extension-token / iana-token | |
iana-token := <A publicly-defined extension token. Tokens | |
of this form must be registered with IANA | |
as specified in RFC 2048.> | |
parameter := attribute "=" value | |
attribute := token | |
; Matching of attributes | |
; is ALWAYS case-insensitive. | |
value := token / quoted-string | |
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, | |
or tspecials> | |
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 |