<HTML>
<HEAD>
<TITLE>MIME::Decoder::NBit</TITLE>
</HEAD>
<BODY
bgcolor="#FFFFFF" link="#CC3366" vlink="#993366" alink="#FF6666">
<FONT FACE="sans-serif" SIZE=-1><A HREF="http://www.zeegee.com" TARGET="_top"><IMG SRC="icons/zeegee.gif" ALT="ZeeGee Software" ALIGN="RIGHT" BORDER="0"></A><A NAME="__TOP__"><H1>MIME::Decoder::NBit</H1>
</A>
<P><B>This module is <FONT COLOR="#990000">BETA</FONT> code, which means that the interfaces are fairly stable BUT it has not been out in the community long enough to guarantee much testing. Use with caution! Please report any errors back to <A HREF="mailto:eryq@zeegee.com">eryq@zeegee.com</A> as soon as you can.</B><UL>
<LI> <A HREF="#NAME">NAME</A>
<LI> <A HREF="#SYNOPSIS">SYNOPSIS</A>
<LI> <A HREF="#DESCRIPTION">DESCRIPTION</A>
<UL>
<LI> <A HREF="#Legal_7bit_data">Legal 7bit data</A>
<LI> <A HREF="#Legal_8bit_data">Legal 8bit data</A>
<LI> <A HREF="#How_decoding_is_done">How decoding is done</A>
<LI> <A HREF="#How_encoding_is_done">How encoding is done</A>
</UL>
<LI> <A HREF="#AUTHOR">AUTHOR</A>
<LI> <A HREF="#VERSION">VERSION</A>
</UL>
</A>
<P><HR>
<A NAME="NAME"><H2><A HREF="#__TOP__"><IMG SRC="icons/h1bullet.gif" ALT="Top" BORDER="0"></A> NAME</H2></A>
<P>MIME::Decoder::NBit - encode/decode a "7bit" or "8bit" stream
<P><HR>
<A NAME="SYNOPSIS"><H2><A HREF="#__TOP__"><IMG SRC="icons/h1bullet.gif" ALT="Top" BORDER="0"></A> SYNOPSIS</H2></A>
<P>A generic decoder object; see <A HREF="../../MIME/Decoder.pm.html">MIME::Decoder</A> for usage.
<P><HR>
<A NAME="DESCRIPTION"><H2><A HREF="#__TOP__"><IMG SRC="icons/h1bullet.gif" ALT="Top" BORDER="0"></A> DESCRIPTION</H2></A>
<P>This is a MIME::Decoder subclass for the <CODE>7bit</CODE> and <CODE>8bit</CODE> content
transfer encodings. These are not "encodings" per se: rather, they
are simply assertions of the content of the message.
From RFC-2045 Section 6.2.:
<FONT SIZE=3 FACE="courier"><PRE>
Three transformations are currently defined: identity, the "quoted-
printable" encoding, and the "base64" encoding. The domains are
"binary", "8bit" and "7bit".
</PRE></FONT>
<FONT SIZE=3 FACE="courier"><PRE>
The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
mean that the identity (i.e. NO) encoding transformation has been
performed. As such, they serve simply as indicators of the domain of
the body data, and provide useful information about the sort of
encoding that might be needed for transmission in a given transport
system.
</PRE></FONT>
<P>In keeping with this: as of MIME-tools 4.x,
<I>this class does no modification of its input when encoding;</I>
all it does is attempt to <I>detect violations</I> of the 7bit/8bit assertion,
and issue a warning (one per message) if any are found.
<P><HR>
<A NAME="Legal_7bit_data"><H3><A HREF="#__TOP__"><IMG SRC="icons/h2bullet.gif" ALT="Top" BORDER="0"></A> Legal 7bit data</H3></A>
<P>RFC-2045 Section 2.7 defines legal <CODE>7bit</CODE> data:
<FONT SIZE=3 FACE="courier"><PRE>
"7bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]. No octets with decimal values greater than 127
are allowed and neither are NULs (octets with decimal value 0). CR
(decimal value 13) and LF (decimal value 10) octets only occur as
part of CRLF line separation sequences.
</PRE></FONT>
<P><HR>
<A NAME="Legal_8bit_data"><H3><A HREF="#__TOP__"><IMG SRC="icons/h2bullet.gif" ALT="Top" BORDER="0"></A> Legal 8bit data</H3></A>
<P>RFC-2045 Section 2.8 defines legal <CODE>8bit</CODE> data:
<FONT SIZE=3 FACE="courier"><PRE>
"8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]), but octets with decimal values greater than 127
may be used. As with "7bit data" CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.
</PRE></FONT>
<P><HR>
<A NAME="How_decoding_is_done"><H3><A HREF="#__TOP__"><IMG SRC="icons/h2bullet.gif" ALT="Top" BORDER="0"></A> How decoding is done</H3></A>
<P>The <B>decoder</B> does a line-by-line pass-through from input to output,
leaving the data unchanged <I>except</I> that an end-of-line sequence of
CRLF is converted to a newline "\n". Given the line-oriented nature
of 7bit and 8bit, this seems relatively sensible.
<P><HR>
<A NAME="How_encoding_is_done"><H3><A HREF="#__TOP__"><IMG SRC="icons/h2bullet.gif" ALT="Top" BORDER="0"></A> How encoding is done</H3></A>
<P>The <B>encoder</B> does a line-by-line pass-through from input to output,
and simply attempts to <I>detect</I> violations of the <CODE>7bit</CODE>/<CODE>8bit</CODE>
domain. The default action is to warn once per encoding if violations
are detected; the warnings may be silenced with the QUIET configuration
of <A HREF="../MIME/Tools.pm.html">MIME::Tools</A>.
<P><HR>
<A NAME="AUTHOR"><H2><A HREF="#__TOP__"><IMG SRC="icons/h1bullet.gif" ALT="Top" BORDER="0"></A> AUTHOR</H2></A>
<P>Eryq (<I><FILE><A HREF="mailto:eryq@zeegee.com">eryq@zeegee.com</A></FILE></I>), ZeeGee Software Inc (<I><FILE><A HREF="http://www.zeegee.com">http://www.zeegee.com</A></FILE></I>).
<P>All rights reserved. This program is free software; you can redistribute
it and/or modify it under the same terms as Perl itself.
<P><HR>
<A NAME="VERSION"><H2><A HREF="#__TOP__"><IMG SRC="icons/h1bullet.gif" ALT="Top" BORDER="0"></A> VERSION</H2></A>
<P>$Revision: 5.403 $ $Date: 2000/11/04 19:54:48 $
<P><HR>
<ADDRESS><FONT SIZE=-1>
Generated Wed Jan 17 01:58:03 2001 by cvu_pod2html
</FONT></ADDRESS>
</FONT></BODY>
</HTML>