| 1 | | I spent a bunch of time dealing with this stuff at a previous job. Here's how it works: |
| 2 | | |
| 3 | | In the first email, this "Subject: more =?iso-8859-15?q?=E9?= " does NOT mean the email is encoded in iso-8859-15. That is only the encoding for that subject line. I can't remember the RFC number but that format is common. So you decode the part inbetween the last two question marks using the format in the first part. The "=E9" is the part that translates to the é character. |
| 4 | | |
| 5 | | Then this is the encoding for the email: "Content-Transfer-Encoding: quoted-printable" |
| 6 | | "k=C3=A9" in "quoted-printable" format is "ké". |
| 7 | | |
| 8 | | Similarly, for the second email, the *subject* line is UTF-8 encoded, much like the first email: "Subject: =?UTF-8?Q?more_=C3=A9?=" |
| 9 | | |
| 10 | | For the content of the second email, it's UTF-8 format, but it's encoded as base64: |
| 11 | | "a8OpDQo=" is base64 code for "ké" |
| 12 | | |
| 13 | | You can even get these types of things nested inside each other, when mail is replied to and forwarded from different mail clients with different encodings. |
| 14 | | |
| 15 | | So it looks like the mail itself is formatted correctly. |
| 16 | | |
| 17 | | |
| 18 | | |
| 19 | | |
| 20 | | |
| 21 | | |
| 22 | | |
| | 1 | <deleted> |
