Garbled Email Subjects: Causes and Fixes, and How to Read =?UTF-8?B?, =?ISO-2022-JP?B?, and $B

=?UTF-8?B?…?= in a subject is Japanese wrapped in ASCII

Email headers (subject, sender, and so on) were originally designed to carry only ASCII. So a Japanese subject is sent as ASCII, labeled with its character encoding and conversion method. This is MIME encoding (RFC 2047), and it looks like this.

For example, “=?UTF-8?B?5piO5pel44Gu5Lya6K2w44Gu6LOH5paZ44KS6YCB44KK44G+44GZ?=” is a Japanese sentence meaning “I’m sending the materials for tomorrow’s meeting”, in UTF-8 and converted to Base64. Email apps normally turn this back into Japanese automatically, but it can stay wrapped in phone notifications, mail logs, notification emails sent from web forms, and subjects extracted by a program.

Reading B, Q, and ISO-2022-JP subjects

• B method (Base64): =?UTF-8?B?5paH5a2X5YyW44GR?= decodes to the Japanese word for “mojibake”. Nearly all Japanese subjects use this
• Q method (Quoted-Printable): =?UTF-8?Q?=E6=96=87=E5=AD=97?= decodes to 文字 (“characters”). The two digits after each = are one byte. It’s used for subjects that are mostly English
• ISO-2022-JP (JIS): =?ISO-2022-JP?B?GyRCTEBGfCROMnE1RCROO3FOQSRyGyhC?= decodes to the first half of the sentence above. This form has long been used by Japanese email software

Long subjects get split into several =?…?= parts with line breaks, to keep any single line from getting too long. For example, sending the sentence above in ISO-2022-JP can split it into “=?ISO-2022-JP?B?GyRCTEBGfCROMnE1RCROO3FOQSRyGyhC?=” and “=?ISO-2022-JP?B?GyRCQXckaiReJDkbKEI=?=”. Under the rules, the spaces and line breaks between such parts are removed and the parts joined back together.

A body like “$BL@F|$N…(B” is JIS with the ESC missing

ISO-2022-JP switches between “Japanese from here” and “ASCII from here” using an invisible control character called ESC. “ESC $ B” starts Japanese and “ESC ( B” returns to ASCII. If the ESC characters alone get dropped, say when an email is copied as text or imported into another system, you see the switch signals and the contents as plain ASCII, as in “$BL@F|$N2q5D$N;qNA$rAw$j$^$9(B”.

This form can be restored by reading the ASCII between “$B” and “(B” two characters at a time, each pair being one Japanese character. The example above is the sentence about tomorrow’s meeting materials. Since all you’re doing is putting the ESC back, no characters are lost.

Why a body turns into 縺, ã, or ‚

A garbled body happens when the “Content-Type: text/plain; charset=…” declaration in the email’s header disagrees with the body’s actual encoding. If the body is UTF-8 but the charset says Shift_JIS, you get a stream of “縺” and “繧”. If there’s no charset and the recipient’s software reads it in a Western encoding, you get rows of “ã” and “æ”.

• A program sending web form auto-replies or system notifications forgot to declare the charset
• A template written in Shift_JIS is being sent by a UTF-8 mail program
• Only the body’s encoding was converted on the way through a mailing list or forward
• The body appears as raw Base64 or Quoted-Printable (the =E3=81=82 form). This isn’t garbling, just the wrapped form left as is

Some email software lets you switch the display encoding by hand (look for a text encoding item in the View menu). If yours doesn’t, copy the garbled body and paste it into the tool, which works out which mix-up happened and restores it. The Mojibake Patterns Chart shows how to recognize each type.

What senders can do to prevent garbling

1. 1

   Standardize on UTF-8

   Today’s email apps and phones read UTF-8 without trouble. Use UTF-8 for the subject, body, and attachment names, and always declare charset=UTF-8 in the header.

2. 2

   Watch out for platform-dependent characters and emoji

   If the recipient is on an older setup receiving ISO-2022-JP, characters such as “①”, “㈱”, and “髙”, or emoji, can turn into “?” or “〓”. In standard external messages, it’s safer to rewrite them as “(1)” or “(株)”.

3. 3

   Send yourself a test

   Check the subject and body of system notifications in several environments: Gmail, Outlook, and phone mail apps. If a subject still shows as =?…?=, the sending side may be writing the encoding incorrectly.

Another common complaint is a CSV attached to an email coming out garbled in Excel. That’s an encoding problem in the file, not the email, and it’s covered in How to Fix CSV Garbled in Excel.

FAQ

Why does my email subject show =?UTF-8?B?

You’re seeing the raw form of MIME encoding, the rule for sending Japanese subjects wrapped in ASCII. Notifications and logs outside email apps may not convert it back automatically. The part between =? and ?= is Base64, and reading the result as UTF-8 gives you the Japanese.

How do I decode an =?ISO-2022-JP?B? subject?

Remove the Base64, then read the result as ISO-2022-JP (JIS). Removing the Base64 alone leaves ASCII mixed with ESC characters. Long subjects are split into several =?…?= parts, so remove the spaces and line breaks between them and read them together.

The email body is ASCII with $B and (B mixed in. What happened?

The ESC characters that signal switching have dropped out of Japanese written in ISO-2022-JP. Read the ASCII between “$B” and “(B” two characters at a time, each pair being one character, and it can be restored.

How can I keep emails I send from being garbled?

Use UTF-8 for the subject and body and declare charset=UTF-8 in the header. If the email might reach an older setup, avoid platform-dependent characters such as ① and ㈱, as well as emoji, and send yourself a test to check.