rfc1896.txt

<VC++网络游戏建摸与实现>源代码

   In some environments, it might be impossible to combine certain
   text/enriched formatting commands, whereas in others they might be
   combined easily. For example, the combination of <bold> and <italic>
   might produce bold italics on systems that support such fonts, but
   there exist systems that can make text bold or italicized, but not
   both. In such cases, the most recently issued (innermost) recognized
   formatting command should be preferred.

   One of the major goals in the design of text/enriched was to make it
   so simple that even text-only mailers will implement enriched-to-
   plain-text translators, thus increasing the likelihood that enriched
   text will become "safe" to use very widely. To demonstrate this
   simplicity, an extremely simple C program that converts text/enriched
   input into plain text output is included in Appendix A.

Extensions to text/enriched

   It is expected that various mail system authors will desire
   extensions to text/enriched. The simple syntax of text/enriched, and
   the specification that unrecognized formatting commands should simply
   be ignored, are intended to promote such extensions.

An Example

   Putting all this together, the following "text/enriched" body
   fragment:

     From: Nathaniel Borenstein <[e-mail]>
     To: Ned Freed <[e-mail]>
     Content-type: text/enriched

     <bold>Now</bold> is the time for <italic>all</italic>
     good men
     <smaller>(and <<women>)</smaller> to
     <ignoreme>come</ignoreme>

     to the aid of their


     <color><param>red</param>beloved</color>
     country.

     By the way,
     I think that <paraindent><param>left</param><<smaller>

     </paraindent>should REALLY be called

     <paraindent><param>left</param><<tinier></paraindent>



Resnick & Walker             Informational                     [Page 15]

RFC 1896            text/enriched MIME Content-type        February 1996


     and that I am always right.

     -- the end

   represents the following formatted text (which will, no doubt, look
   somewhat cryptic in the text-only version of this document):

     Now is the time for all good men (and <women>) to come
     to the aid of their

     beloved country.
     By the way, I think that
          <smaller>
     should REALLY be called
          <tinier>
     and that I am always right.
     -- the end

   where the word "beloved" would be in red on a color display.

   ti 0 Security Considerations

   Security issues are not discussed in this memo, as the mechanism
   raises no security issues.

Authors' Addresses

   For more information, the authors of this document may be contacted
   via Internet mail:

   Peter W. Resnick
   QUALCOMM Incorporated
   6455 Lusk Boulevard
   San Diego, CA 92121-2779

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Amanda Walker
   InterCon Systems Corporation
   950 Herndon Parkway
   Herndon, VA 22070

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]



Resnick & Walker             Informational                     [Page 16]

RFC 1896            text/enriched MIME Content-type        February 1996


Acknowledgements

   The authors gratefully acknowledge the input of many contributors,
   readers, and implementors of the specification in this document.
   Particular thanks are due to Nathaniel Borenstein, the original
   author of RFC 1563.

References

   [RFC-1341]
        Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
        Extensions): Mechanisms for Specifying and Describing the Format
        of Internet Message Bodies", 06/11/1992.

   [RFC-1521]
        Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
        Extensions) Part One: Mechanisms for Specifying and Describing
        the Format of Internet Message Bodies", 09/23/1993.

   [RFC-1523]
        Borenstein, N., "The text/enriched MIME Content-type",
        09/23/1993.

   [RFC-1563]
        Borenstein, N., "The text/enriched MIME Content-type",
        01/10/1994.

   [RFC-1642]
        Goldsmith, D., Davis, M., "UTF-7 - A Mail-Safe Transformation
        Format of Unicode", 07/13/1994.

   [RFC-1766]
        Alvestrand, H., "Tags for the Identification of Languages",
        03/02/1995.

   [RFC-1866]
        Berners-Lee, T., and D. Connolly, D., "Hypertext Markup Language
        - 2.0", 11/03/1995.













Resnick & Walker             Informational                     [Page 17]

RFC 1896            text/enriched MIME Content-type        February 1996


Appendix A--A Simple enriched-to-plain Translator in C

   One of the major goals in the design of the text/enriched subtype of
   the text Content-Type is to make formatted text so simple that even
   text-only mailers will implement enriched-to-plain-text translators,
   thus increasing the likelihood that multifont text will become "safe"
   to use very widely. To demonstrate this simplicity, what follows is a
   simple C program that converts text/enriched input into plain text
   output. Note that the local newline convention (the single character
   represented by "\n") is assumed by this program, but that special
   CRLF handling might be necessary on some systems.

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

main() {
    int c, i, paramct=0, newlinect=0, nofill=0;
    char token[62], *p;

    while ((c=getc(stdin)) != EOF) {
        if (c == '<') {
            if (newlinect == 1) putc(' ', stdout);
            newlinect = 0;
            c = getc(stdin);
            if (c == '<') {
                if (paramct <= 0) putc(c, stdout);
            } else {
                ungetc(c, stdin);
                for (i=0, p=token;
                    (c=getc(stdin)) != EOF && c != '>'; i++) {
                    if (i < sizeof(token)-1)
                        *p++ = isupper(c) ? tolower(c) : c;
                }
                *p = '\0';
                if (c == EOF) break;
                if (strcmp(token, "param") == 0)
                    paramct++;
                else if (strcmp(token, "nofill") == 0)
                    nofill++;
                else if (strcmp(token, "/param") == 0)
                    paramct--;
                else if (strcmp(token, "/nofill") == 0)
                    nofill--;
            }
        } else {
            if (paramct > 0)



Resnick & Walker             Informational                     [Page 18]

RFC 1896            text/enriched MIME Content-type        February 1996


                ; /* ignore params */
            else if (c == '\n' && nofill <= 0) {
                if (++newlinect > 1) putc(c, stdout);
            } else {
                if (newlinect == 1) putc(' ', stdout);
                newlinect = 0;
                putc(c, stdout);
            }
        }
    }
    /* The following line is only needed with line-buffering */
    putc('\n', stdout);
    exit(0);
}

   It should be noted that one can do considerably better than this in
   displaying text/enriched data on a dumb terminal. In particular, one
   can replace font information such as "bold" with textual emphasis
   (like *this* or _T_H_I_S_). One can also properly handle the
   text/enriched formatting commands regarding indentation,
   justification, and others.  However, the above program is all that is
   necessary in order to present text/enriched on a dumb terminal
   without showing the user any formatting artifacts.

Appendix B--A Simple enriched-to-HTML Translator in C

   It is fully expected that other text formatting standards like HTML
   and SGML will supplant text/enriched in Internet mail. It is also
   likely that as this happens, recipients of text/enriched mail will
   wish to view such mail with an HTML viewer. To this end, the
   following is a simple example of a C program to convert text/enriched
   to HTML. Since the current version of HTML at the time of this
   document's publication is HTML 2.0 defined in [RFC-1866], this
   program converts to that standard.  There are several text/enriched
   commands that have no HTML 2.0 equivalent. In those cases, this
   program simply puts those commands into processing instructions; that
   is, surrounded by "<?" and ">". As in Appendix A, the local newline
   convention (the single character represented by "\n") is assumed by
   this program, but special CRLF handling might be necessary on some
   systems.

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

main() {
    int c, i, paramct=0, nofill=0;



Resnick & Walker             Informational                     [Page 19]

RFC 1896            text/enriched MIME Content-type        February 1996


    char token[62], *p;

    while((c=getc(stdin)) != EOF) {
        if(c == '<') {
            c = getc(stdin);
            if(c == '<') {
                fputs("&lt;", stdout);
            } else {
                ungetc(c, stdin);
                for (i=0, p=token;
                    (c=getc(stdin)) != EOF && c != '>'; i++) {
                    if (i < sizeof(token)-1)
                        *p++ = isupper(c) ? tolower(c) : c;
                }
                *p = '\0';
                if(c == EOF) break;
                if(strcmp(token, "/param") == 0) {
                    paramct--;
                    putc('>', stdout);
                } else if(paramct > 0) {
                    fputs("&lt;", stdout);
                    fputs(token, stdout);
                    fputs("&gt;", stdout);
                } else {
                    putc('<', stdout);
                    if(strcmp(token, "nofill") == 0) {
                        nofill++;
                        fputs("pre", stdout);
                    } else if(strcmp(token, "/nofill") == 0) {
                        nofill--;
                        fputs("/pre", stdout);
                    } else if(strcmp(token, "bold") == 0) {
                        fputs("b", stdout);
                    } else if(strcmp(token, "/bold") == 0) {
                        fputs("/b", stdout);
                    } else if(strcmp(token, "italic") == 0) {
                        fputs("i", stdout);
                    } else if(strcmp(token, "/italic") == 0) {
                        fputs("/i", stdout);
                    } else if(strcmp(token, "fixed") == 0) {
                        fputs("tt", stdout);
                    } else if(strcmp(token, "/fixed") == 0) {
                        fputs("/tt", stdout);
                    } else if(strcmp(token, "excerpt") == 0) {
                        fputs("blockquote", stdout);
                    } else if(strcmp(token, "/excerpt") == 0) {
                        fputs("/blockquote", stdout);
                    } else {



Resnick & Walker             Informational                     [Page 20]

RFC 1896            text/enriched MIME Content-type        February 1996


                        putc('?', stdout);
                        fputs(token, stdout);
                        if(strcmp(token, "param") == 0) {
                            paramct++;
                            putc(' ', stdout);
                            continue;
                        }
                    }
                    putc('>', stdout);
                }
            }
        } else if(c == '>') {
            fputs("&gt;", stdout);
        } else if (c == '&') {
            fputs("&amp;", stdout);
        } else {
            if(c == '\n' && nofill <= 0 && paramct <= 0) {
                while((i=getc(stdin)) == '\n') fputs("<br>", stdout);
                ungetc(i, stdin);
            }
            putc(c, stdout);
        }
    }
    /* The following line is only needed with line-buffering */
    putc('\n', stdout);
    exit(0);
}
























Resnick & Walker             Informational                     [Page 21]