david wrote:
Paul F. wrote:
aside from the logic aspect: i take it that text with a NUL must
be treated differently than text with an 8th bit set. i assume it
must be encoded with q-p? (or base64, but q-p would be sufficient?)
Right, NUL is binary, not 8-bit, data. It can be encoded with
q-p, according to RFC 2045 §6.7. If the text has a lot of binary
okay, good. after getting application files with NULs to work (which
fixed all the problems with attaching one or more NUL-filled files),
i took a look at text files with embedded NULs. the q-p encoder
uses fgets, so it didn't work so well, but that's fixed now too.
while i'm on a roll, anyone have another favorite place where fgets
should be replaced?
data, it wouldn't be very readable as q-p, so base64 might be a
better choice.
i don't see that kind of heuristic being made anywhere currently. does
that sound right?
paul
----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 56.8 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers