Japanese is garbled on the mail server.

I don't know how it's disguised, but the way it's spooky is different.

Example

=81=40=82=b3=82=c4=81=41=82=d3=82=c6=8e=76=82=a2=97=a7=82=c1=8
2=c4=81=41=90=56=8a=83=95=fb=96=ca=82=c9=82=d3=82=e7=82=c1=8

The problem is that the sender does not set the Content-Type header or set the Latin-1 series character set name even though it uses 8 bit characters.

Example

gXmLxopFk66M/IF6DQoNCkVyaWNzc29ugUFJbnRlbILIgsc1jtCCqoOCg2+DQ4OLkluWloz8gq+W
s5D8kNqRsYtaj3CC8JStlVwNCg0KgaFVUkwNCmh0dHA6Ly93d3cuYmx1ZXRvb3RoLmNvbS8NCmh0
dHA6Ly93d3cuYmx1ZXRvb3RoLmNvbS9uZXdzL3RleHQvcHJlc3M0Lmh0bSCBaZStlVyOkZe/gWoN

This is also a problem for the sender that is not configured in the Content-Type header.

Recently, however, mailers are mostly responsible for garbled text.
If it is gmail, I think charset=utf8 is set in the Content-Type header of the corresponding email.Also, the Subject header should be encoded as follows:

Subject: ?utf-8?B?$...

If the Content-Type header is not set, many Japanese mailers will be judged to be "probably iso-2022-jp" because of the base64 encoded name used in the Subject and From headers (often =?iso-2022-jp? in Japan).

"Even though it was sent with ""utf8 and base64"", ""all Japanese in the text is garbled"" means
" I don't think you can see the raw data of base64.(If it is base64, all characters, not limited to Japanese, cannot be read)

Possible
·UTF-8 is incorrect
　b Base64 decoding succeeded, but charset is not UTF-8.
　　In this case, you will be haunted by unintended kanji characters.

·Base64 is incorrect
　QQuoted-Printable or ISO-2022-JP can read only ASCII parts.
　　In that case, it would be spooky like Mattn with ASCII area characters (alphanumeric characters).