Compare Q and B byte encodings
02Q and B encode bytes, not abstract letters. Q favors recognizable ASCII text; B uses the same Base64 encoding as MIME bodies.
=?UTF-8?Q?caf=C3=A9?= and =?UTF-8?B?Y2Fmw6k=?= both display café under the assumed UTF-8 support. Encoding is neither encryption nor proof of a sender.
Source for this drawing: RFC 2047 · Read RFC section 4.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Encode special bytes without inserting raw spaces.
- Encode special bytes without inserting raw spaces.
- In Q, =HH represents an octet using two hexadecimal digits; uppercase hex is recommended. An underscore represents byte20 (hexadecimal), even if a charset assigns SPACE differently. Literal underscore, question mark and equals sign need encoding.
- B is MIME Base64. Readers supporting an encoded-word charset MUST handle Q and B. Q is recommended when text is mostly ASCII; otherwise B should be used. Context can further restrict Q’s literal characters.
Header Q is similar to body quoted-printable, not identical: underscore-to-byte20 is a header-Q rule. SPACE and TAB MUST NOT occur raw inside either encoding. All shown byte sequences and display strings are chosen examples, not a requirement to choose one encoding for every Subject. The field name Subject: is outside the encoded word.
Read the RFC section ↗