Closed RichardSteele closed 6 months ago
vincent-richard
commented
1 year ago Hello!
Unfortunately, the patch you proposed introduces a regression and breaks the "parser_textTest" unit test, at 3 places:
1) test: textTest::testNewFromString (F) line: 182 2) test: textTest::testBugFix20110511 (F) line: 593 3) test: textTest::testInternationalizedEmail_whitespace (F) line: 711
RichardSteele
commented
1 year ago Right, I forgot about the tests.
I think this bug can't be resolved without breaking other parts. As per RFC2047 spaces between adjacent encoded words are just separators but not meant to be displayed. A space between an encoded word and a regular ASCII text is not just a separator but also meant to be displayed.
The problem is that vmime::text::createFromString() doesn't know whether or not the text will be forcefully encoded later on, which will create encoded words even for ASCII texts, like in a mailbox field. Likewise, during the stringification of a text it's unclear whether or not the text was created manually or by createFromString(). Handling the bug at this point could end up in adding redundant spaces.
As RFC2047 says:
Use of 'encoded-word's to represent strings of purely ASCII characters is allowed, but discouraged.
In conclusion, it might be better to put a warning in the comments of vmime::text.
Prevents the loss of a space if the previous word is 8-bit but the current one is not. This equals the case of the current word being 8-bit but not the previous one.