Talk:Quoted-printable

Is there a free unix tool to convert to plain text (iso latin) ?

unnecessary encoding

More and more companies automated emailers use quoted printable on all email, even through there are no 8 bit characters worth encoding. I would like this stopped. 66.114.93.6 04:00, 12 February 2007 (UTC)[reply]

Are there currently any valid reasons for using quoted printable or base64? Many emails now specify 'Content-Transfer-Encoding: 8bit', so it seems unlikely that anyone would be using an email system that doesn't support this. I'd like to see this discussed in the article. Mike Dallwitz 23:38, 9 October 2007 (UTC)[reply]

Quite a few systems still either don't support the 8bitmime extention or offer it but don't support it properly and have it disabled by default (exim comes in that category or at least it did last time I checked). One complication is that in order to support that extention in a way that complies with the specs and doesn't piss off users hugely a mailserver supporting 8bitmime has to be able to trasform messages to 7 bit only to allow them to be passed to servers that don't. This transform is non trivial (according to the RFCs parts of types under multipart and message must not use quoted printable or binary so the transform must break up messages into a tree, convert the innermost parts and then rebuild the message). Also note that even with 8bitmime some things can't be sent without using either quoted printable or base64 because of maximum line length rules.

As for the automated emailers is it really worth implementing the checks so it only sends in quoted printable when it absoloutely has to for the sake of a few percent bandwidth saving (assuming that the sender is sending mostly english messages with the potential for the occasional non english character). Plugwash 19:20, 11 October 2007 (UTC)[reply]

It seems kind of overkill to me that I see quite a lot of automated emailers that arbitually send all email encoded in some way: either quoted-printable or sometimes base64. While doing so technically would be compliant, it is like abusing of a loophole almost. Since computers use 8-bit ASCII anyways, why not send "real" 8-bit email instead of encoding it? They are practically abusing RFC's as it is anyways and those standards are very old now. Also I am seeing an increasing number of mailers that don't even put in a plain text area at the top of HTML messages, so it is all HTML. To me, that is unacceptable. 66.114.93.6 (talk) 08:05, 21 July 2008 (UTC)[reply]

Spelling Correction

Oops I forgot to login before correcting that spelling mistake. --The One and only Shane91c! (talk) 20:11, 5 February 2009 (UTC)[reply]

"Quoted"?

Why quoted? Thanks, --Abdull (talk) 20:41, 30 November 2009 (UTC)[reply]

Whitespace management

RFC 2045 states that: (White Space) Octets with values of 9 and 32 MAY be represented as US-ASCII TAB (HT) and SPACE characters, respectively, but MUST NOT be so represented at the end of an encoded line.

However, the example you give is:

If you believe that truth=3Dbeauty, then surely=20=
mathematics is the most beautiful branch of philosophy.

From what I understand, =20 is only useful to encode a space that is the last of the line, with nothing else following. But you're using a soft line break afterwards (required because the line would be too long, as the whole sentence is more than 76 characters), so there's no need for this =20. Not doing it still respects the rule that a space MUST NOT be represented as a SPACE character at the end of an encoded line.

So for me this is shorter, and correct too:

If you believe that truth=3Dbeauty, then surely =
mathematics is the most beautiful branch of philosophy.

This example is also explicitly stated in the RFC 2045:

Now's the time for all folk to come to the aid of their country.

With the Quoted-Printable encoding, as:

Now's the time =
for all folk to come=
 to the aid of their country.

LuisMenina (talk) 11:30, 15 June 2012 (UTC)[reply]

I don't get it

The text says "Any 8-bit byte value may be encoded with 3 characters: an = followed by two hexadecimal digits (0–9 or A–F) representing the byte's numeric value.", but the example uses six characters, e.g. =C3=A9. 2003:EC:9BD2:B900:814E:D6A6:5CFB:3281 (talk) 12:40, 13 December 2018 (UTC)[reply]

Because the text is in UTF-8 where the letter "é" uses 2 bytes: C3 and A9. --RokerHRO (talk) 15:34, 12 February 2021 (UTC)[reply]

Error in example text?

I believe there is an error in the sample encoded text. The character immediately after the em dash in the final line is a hair space, U+200A. In UTF-8 it would be encoded as =E2=80=8A, but the article has =E2=80=89. The difference between a hair space and a thin space is probably invisible to the naked eye, but.... 129.24.38.129 (talk) 16:21, 12 January 2024 (UTC)[reply]