On the other hand, Outlook still has a ridiculous bug that uses the wrong encoding when presenting HTML email - that is, it uses the encoding of the email's text-body when presenting the html-body, even if the html-body specifies a different encoding.
So, if the two bodies have differing encodings (charsets), then the HTML body will look wrong. Unless you force Outlook to always use UTF-8 for encoding emails (which is a setting, but not the default) then you'll end up sending emails that will look garbled to your recipient.
This "differing charset" scenario actually happens pretty frequently, because of the following scenario:
a) You write an email (or reply to an existing email - actually it happens most with replies).
b) Outlook's text editor decides to insert a non-breaking space (codepoint U+00A0). Perhaps it generates HTML with but before transmission this eventually turns into the single UTF-8 character 0xC2 0xA0.
c) When generating the text-body, Outlook decides to just use a plain old space, so the text body is plain ASCII.
d) Outlook, in its cleverness, then says "ooh, I can 'conserve' encoding-ness and use plain old iso-8859-1 for the text body, but I need to use UTF-8 for the HTML body because of that non-ascii character"
e) Outlook generates this email (please excuse formatting woes due to HN).
Content-Type: multipart/alternative; boundary="0016e64dbd929784310488b2b082"
This is a multi-part message in MIME format.
--0016e64dbd929784310488b2b082
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
yo yo
--0016e64dbd929784310488b2b082
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<body>
yo=C2=A0yo
</body>
<html>
--0016e64dbd929784310488b2b082--
When you view the above email in Outlook, you see "yo yo" instead of "yo yo"