Skip Menu |

This queue is for tickets about the MIME-Charset CPAN distribution.

Report information
The Basics
Id: 37411
Status: resolved
Priority: 0/
Queue: MIME-Charset

People
Owner: hatuka [...] nezumi.nu
Requestors: OSALAUN [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.006.2
Fixed in: (no value)



Subject: body_encode() defaults to Base64 for ISO- content whereas QP would be preferable
We use MIME::Charset within Sympa ML software to encode attachement messages within service messages. The attached messages are encode using MIME::Charset::body_encode(). However when encoding messages that use ISO-xx charset, the body_encode() subroutine often decides to use Base64 whereas QP would be prefereable. See https://sourcesup.cru.fr/tracker/?func=detail&group_id=23&aid=3698&atid=167 for a description of this behavior. The problem is that some ML subscribers use the Eudora software that badly interprets Base64 encoded ext parts. It would be great if the body_encode() subroutine could use QP whenever it may be suiteable. If needed I can do some testing and provide some simple code that shows the problem. Thanks.
Olivier QP is not the true solution. Some other broken MUAs cannot handle the parts encoded by quoted-printable correctly! Anyway, base64 is safer because the body might be actually not text content. That's why base64 is chosen by Charset.pm when body content is 8-bit data without charset information. Possible solutions are: a) Fill up appropriate charset information for content-type headers of incoming messages. b) Apply a patch on Charset.pm bundled into Sympa to handle text without charset info as quoted-printable. Comments? --- nezumi
(Bcc'ing to submitter of original issue on CRU.fr) I (hopefully) solved this problem, as a side effect of the patch for Sympa... See: https://sourcesup.cru.fr/tracker/?func=detail&aid=5887&group_id=23&atid=167