plain.txt

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