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