[
https://issues.apache.org/jira/browse/EMAIL-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Speakmon updated EMAIL-1:
-----------------------------
Attachment: email-1.patch
Here's a patch to address this. It includes a fix and tests for three scenarios:
1) setContent() with a text content type *without* any specific charset. If a
charset has been previously set, it is automatically applied to the content
type. (This fixes the actual issue.)
2) setContent() with a text content type *with* a specific charset. The content
type charset will override any previously set charset and will change the
Email's default charset to itself. (This is current behavior.)
3) setContent() with a non-text content type. Any charset already set in the
message will be ignored, since we don't want to declare encodings for binary
types. Besides, they'll either come with their own encodings or will be left to
the underlying platform. (This is also current behavior, but this ensures that
the fix for #1 doesn't inadvertently break other types of content.
> [email] setCharset() in Email does not set the charset for the message content
> ------------------------------------------------------------------------------
>
> Key: EMAIL-1
> URL: https://issues.apache.org/jira/browse/EMAIL-1
> Project: Commons Email
> Issue Type: Bug
> Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
> Reporter: James Mc Millan
> Attachments: email-1.patch
>
>
> Hello
> More accurately, the charset is not used in buildMimeMessage() as it is not
> part
> of the contentType used when calling message.setContent(). Since
> setContentType() updates the charset, I think it makes for setCharset() to
> update the contentType?
> James
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
