Commons Email
  1. Commons Email
  2. EMAIL-1

[email] setCharset() in Email does not set the charset for the message content

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.1
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      Description

      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

      1. email-1.patch
        4 kB
        Ben Speakmon

        Issue Links

          Activity

          Hide
          dion gillard added a comment -

          Applied.

          Show
          dion gillard added a comment - Applied.
          Hide
          Ben Speakmon added a comment -

          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.

          Show
          Ben Speakmon added a comment - 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.
          Hide
          Ben Speakmon added a comment -

          Adding link to related issue.

          Show
          Ben Speakmon added a comment - Adding link to related issue.
          Hide
          Ben Speakmon added a comment -

          This should be fixable without any additional charset code, shouldn't it? Quick glance through the source suggests that it can.

          Show
          Ben Speakmon added a comment - This should be fixable without any additional charset code, shouldn't it? Quick glance through the source suggests that it can.
          Hide
          Michael Stevens added a comment -

          As a workaround setContent can be used directly. For example
          mail.setCharset(Email.ISO_8859_1); // sets the charset for the subject
          mail.setFrom(from);
          mail.addTo(user.getEmail());
          mail.setSubject(subject);
          mail.setContent(mailText, "text/plain; charset=iso-8859-1");

          Show
          Michael Stevens added a comment - As a workaround setContent can be used directly. For example mail.setCharset(Email.ISO_8859_1); // sets the charset for the subject mail.setFrom(from); mail.addTo(user.getEmail()); mail.setSubject(subject); mail.setContent(mailText, "text/plain; charset=iso-8859-1");

            People

            • Assignee:
              Unassigned
              Reporter:
              James Mc Millan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development