Bugzilla

Please note the information in https://thunderbird.topicbox.com/groups/e2ee/T87cabaa23b8a0245-M8efe6de47470962ee9f5211f/openpgp-signedencrypted-email-renders-chinese-characters-as-random-symbols summarised in comment #1:
When the reporter *decrypts* a message produced with TB 128 using `gpg -d`, he notices that the inner payload has an *encoding* problem when CTE 8bit is used, there is no encoding issue when base64 is used. This indicates that TB 128 has an *encoding* issue when encoding the payload into CTE 8bit. Once the message has been badly encoded, no program will be able to decrypt and decode it correctly. In fact, comment #1 states that the fault seems to be that a JS string is converted twice into UTF-8, first the payload in a JS string is converted to a raw binary JS string, and then that buffer is converted a second time, so one for example, one initial diacritic ä is finally encoded as four raw bytes instead of two (0xC3 0xA4).

Please note the information in https://thunderbird.topicbox.com/groups/e2ee/T87cabaa23b8a0245-M8efe6de47470962ee9f5211f/openpgp-signedencrypted-email-renders-chinese-characters-as-random-symbols summarised in comment #1:
When the reporter *decrypts* a message produced with TB 128 using `gpg -d`, he notices that the inner payload has an *encoding* problem when CTE 8bit is used, there is no encoding issue when base64 is used. This indicates that TB 128 has an *encoding* issue when encoding the payload into CTE 8bit. Once the message has been badly encoded (and later encrypted), no program will be able to decrypt and decode it correctly. In fact, comment #1 states that the fault seems to be that a JS string is converted twice into UTF-8, first the payload in a JS string is converted to a raw binary JS string, and then that buffer is converted a second time, so one for example, one initial diacritic ä is finally encoded as four raw bytes instead of two (0xC3 0xA4).