Robert wrote:
I know that it should display as "foobar" - the RFC is kind of
weird, it says "for display purposes" (or similar) in several
places, which implies that for other purposes the words are
not considered as one.
It doesn't imply that to me.
I kind of suspect that they just didn't consider apps that
would want to examine the content of non structured fields for
purposes other than displaying to the user.
Or the interpretation for other purposes should be the same
as for display. This paragraph, from RFC 2047 Sec. 6.2, starts
with "displaying" but then says "the use of [...] to represent":
When displaying a particular header field that contains
multiple 'encoded-word's, any 'linear-white-space' that
separates a pair of adjacent 'encoded-word's is ignored.
(This is to allow the use of multiple 'encoded-word's to
represent long strings of unencoded text, without having to
separate 'encoded-word's where spaces occur in the unencoded
text.)
As to why the test fails on FreeBSD: I suspect the relevant
code has to do with the "between_encodings" and "whitespace"
variables in sbr/fmt_rfc2047.c. And I expect that this will
show the problem and get right to decode_rfc2047():
$ ap -format '%(decode{text})' \
'=?us-ascii?q?=66=6f=6f?= =?utf-8?q?=62=61=72?='
I don't have FreeBSD installed so I can't help beyond that.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers