-1

Why does decoding the following fail

Subject: =?ISO-8859-1?Q?Begr=FC=DFungsschreibe?=n

while decoding the following works?

Subject: =?ISO-8859-1?Q?Begr=FC=DFungsschreiben?=

I read https://www.rfc-editor.org/rfc/rfc2047 but could not find a note that there must be space after the end mark ?=. That's the only difference between the two lines. In the first line (which is the failed one) there is the n directly after the end mark.

I used Python 2.7 for decoding.

I googled for a bug in Python, but could only found resolved issues.

Community
  • 1
  • 1
guettli
  • 25,042
  • 81
  • 346
  • 663
  • 1
    Show *what* you try to decode it! – Wolf Dec 10 '14 at 09:09
  • I showed **what** I want to decode. I did not show **how** (by intend). It should not matter in this context. This question is about specs. – guettli Dec 10 '14 at 09:46
  • I see, the confusion I guess comes from mentioning python. Do you actually ask if there might by a bug in some implementation? If it is yours than you should add it, if it is pythons why don't you **name the function you use**? **Which specs** do you refer to? – Wolf Dec 10 '14 at 10:05
  • @Wolf thank you for your feedback. I updated the question. It is about RFC2047 – guettli Dec 10 '14 at 10:12
  • Much clearer now (--1) – Wolf Dec 10 '14 at 10:34
  • `I used Python 2.7 for decoding.` *What* of python did you use? – Wolf Dec 10 '14 at 11:03
  • You are speaking of *space* in the working example, but I see no space in your code snippet. Has the line break (after the header line) the same effect? – Wolf Dec 10 '14 at 13:42

1 Answers1

1

RFC2047 5.1:

an 'encoded-word' that appears in a header field defined as '*text' MUST be separated from any adjacent 'encoded-word' or 'text' by 'linear-white-space'.

The Subject header is defined as *text (and in any case the errata add the same restriction more generally to section 2).

Community
  • 1
  • 1
bobince
  • 528,062
  • 107
  • 651
  • 834