[wp-trac] [WordPress Trac] #18521: Wp_mail function: email subject with multibyte chars is not encoded properly

[WordPress Trac]

#18521: Wp_mail function: email subject with multibyte chars is not encoded
properly
--------------------------------+----------------------
 Reporter:  jetpackpony         |       Owner:
     Type:  defect (bug)        |      Status:  closed
 Priority:  normal              |   Milestone:
Component:  External Libraries  |     Version:  3.2.1
 Severity:  normal              |  Resolution:  invalid
 Keywords:                      |     Focuses:
--------------------------------+----------------------
Changes (by bpetty):

 * keywords:  needs-patch =>
 * status:  new => closed
 * resolution:   => invalid
 * severity:  major => normal
 * milestone:  Awaiting Review =>


Comment:

 I tested this with just the blog name changed to "some é and å characters"
 in single-site mode, and those emails were correct:

 Site Name: `some é and å characters`

 {{{
 Subject: =?UTF-8?Q?[some_=C3=A9_and_=C3=A5_characters]_Password_Reset?=
 }}}

 Since the instructions here seem to imply that this is a multi-site
 installation, I also performed the steps to reproduce by enabling user
 account registration (under "Allow new registrations": "Both sites and
 user accounts can be registered."), signing up a new account, and creating
 a new blog, whose name also contained UTF8 characters:

 Network Name: `some é and å chars`
 Site Name: `some é and å characters`

 {{{
 Subject:
 =?UTF-8?Q?New_some_=C3=A9_and_=C3=A5_chars_Site:_some_=C3=A9_and_=C3=A5_c?=
 =?UTF-8?Q?haracters?=
 }}}

 Not only does my email client (Gmail in this case) correctly decode and
 display this subject, but according to RFC 2047, this is also perfectly
 acceptable to have multiple `encoded-word` sections in the subject, as
 long as they are separated by a space (and they are, and you can see by
 looking at PHPMailer's source for `EncodeHeader` that the space is
 intentionally added). PHPMailer actively uses an algorithm to encode these
 in the most optimal way that results in the shortest string length, so it
 will break parts of the subject up and encode them separately, but I also
 believe in this case, it may have had a max length `encoded-word`, so it
 still broken them up.

 So in short, I don't see any double-encoding happening, and everything
 looks correct. Given the subject line you also listed:

 {{{
 Subject: =?UTF-8?Q?New_site_name_Site:_J=C3=A9t_inqsfzxb_p=C3=A5_?=
 =?UTF-8?Q?=C3=A9?=
 }}}

 This is also perfectly valid, so maybe you're email client lacked proper
 support? Feel free to re-open this ticket if you believe I'm wrong.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/18521#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform