[−][src]Function mail_internals::bind::quoted_printable::encoded_word_encode

pub fn encoded_word_encode<'a, I, O>(input: I, out: &mut O) where
    I: Iterator<Item = &'a [u8]>,
    O: EncodedWordWriter, 

Quoted Printable encoding for Encoded Words in MIME-Headers

Which means:

  1. there is a limit to the maximum number of characters
    • the limit is 75 INCLUDING the =?charset?encoding?...?= overhead
    • as such the line length limit of quoted printable can not be hit, the quoted printable part is at most 67 chars long, e.g. for utf8 it is at most 64 chars
  2. has to be one token, so no ' ','\t' and neither soft nor hard newlines
  3. no '?' character

The input is a sequence of bytes split up in chunks where a split in multipl encoded words can be done between any two chunks but not in a chunk. Wrt. utf8 a chunk would correspond to a character, e.g. [65] for 'a' and [0xe2, 0x99, 0xa5] for a '♥'.

Note that a chunk can with more than 21 byte is not guranteed to work, and can trigger a panic.

As this has to be safe for usage in all header contexts, additional to the chars required by the standard (i.e. '=') following chars are ALWAYS quoted' ', '\t', '?', '(', ')'. Also '\n','\r' see the note below for more details.

Panics:

  1. if the encoded size of a chunk is more than 16 byte, which can happen if a chunk has more than 5 bytes. For comparison utf8 has at most chunks with 4 bytes leading to at most 12 byte buffer usage.

  2. if max size if >76 as no new line handling is implemented and the max size for the use case can be at most 67 chars

  3. if a single encoded chunk can not be written as one because of the length limitation AFTER a new encoded word was started.

Note:

as it has to be a token no new line characters can appear in the output, BUT q-encoding also forbids the encoding of CRLF line breaks in TEXT! bodies, which is mean to not mess up with the limitations to the line length, but they are allowed to appear in non TEXT data, but this function should, but might not be limited to be used with text data, which should but might not be limited to data not containing any new line character. For now any appearance of '\r' or '\n' will be encoded like any other "special" byte, for the future a context might be needed. (Especially as encoded words can contain non-ascii text in which '\r','\n' might be encoded with completely different bytes, but when the RFC speaks of '\r','\n' it normally means the bytes 10/13 independent of the character set, or if they appear in a image, zip-archiev etc. )