MIME::D...er::NBit(3)

πŸ’– MIME::Decoder::NBit πŸ’–

okay bestie, welcome to MIME::Decoder::NBit β€” that's the MIME::D...er::NBit(3) page from the User Contributed Perl Documentation, and yeah, the name got cut off in the header like a text that got truncated mid-sentence. we're still gonna slay it. πŸŽ€


✨ NAME ✨

MIME::Decoder::NBit β€” encode/decode a "7bit" or "8bit" stream πŸ¦‹


🌸 SYNOPSIS 🌸

A generic decoder object; see MIME::Decoder for usage. that's it, that's the whole synopsis, she's lowkey minimal and we respect it.


πŸ’… DESCRIPTION πŸ’…

so this is a MIME::Decoder subclass for the "7bit" and "8bit" content transfer encodings. and here's the tea: these are not "encodings" per se β€” they're literally just assertions about what's inside the message. like, "bestie, trust me, this is 7bit data." that's the whole vibe. straight from RFC-2045 Section 6.2.:

Three transformations are currently defined: identity, the "quoted-printable" encoding, and the "base64" encoding. The domains are "binary", "8bit" and "7bit". 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.

so in keeping with all that: as of MIME-tools 4.x, this class does no modification of its input when encoding. zero. none. not me changing a single byte. all it does is attempt to detect violations of the 7bit/8bit assertion, and issue a warning (one per message) if any are found. it's giving hall monitor energy and honestly? iconic. πŸ‘‘

RFC-2045 Section 2.7 defines legal "7bit" data:

"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.

RFC-2045 Section 2.8 defines legal "8bit" data:

"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.

🧚 How decoding is done

the decoder does a line-by-line pass-through from input to output, leaving the data unchanged except 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. and honestly? fair. reasonable queen behavior. πŸ’œ

✨ How encoding is done

the encoder does a line-by-line pass-through from input to output, and simply attempts to detect violations of the "7bit"/"8bit" domain. the default action is to warn once per encoding if violations are detected; the warnings may be silenced with the QUIET configuration of MIME::Tools. so if you're getting yelled at, that's why, and you can absolutely mute her. πŸ”‡


🫢 SEE ALSO 🫢

  • MIME::Decoder

πŸ‘‘ AUTHOR πŸ‘‘

Eryq (eryq@zeegee.com), ZeeGee Software Inc (http://www.zeegee.com).

All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


and that's the whole page, bestie!! no notes, ate, periodt. πŸ’…βœ¨

perl v5.42.0, dated 2026-02-11 β€” courtesy of MIME::D...er::NBit(3), whose name got snipped in the header but whose whole heart is here. mwah. πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from