Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Copy/move to local folder: Â injected into text

  • 3 پاسخ
  • 1 has this problem
  • 1 view
  • آخرین پاسخ توسّط Matt

more options

I have a bunch of local folders, where I organize my important email. I recently changed the "Fonts & Encodings" setting to "Unicode (UTF-8)" on both Outgoing and Incoming Mail settings. This setting is at: >>> Tools, Options, Display, Advanced.

Ever since that point, every email message I move to my primary local folder, all the double-spaces become Â-space.

In my inbox, the message looks like this: Tools, Options, Display, Advanced: outgoing: Unicode (UTF-8) incoming: Unicode (UTF-8)

Ctrl-click-drag to the main local folder, it becomes: Tools, Options, Display, Advanced: outgoing: Unicode (UTF-8) incoming: Unicode (UTF-8)

But... I created a new local folder just as a test, and the same message copied to that folder, looks fine. In fact, it is only one folder with this problem. Any ideas on how to force the old folder to stop changing characters?

Oh my!!! Right-click on the folder, properties: Fallback Text Encoding = Western (ISO-8859-1), and checkbox checked: Apply encoding to all messages in the folder (individual message text encoding settings and auto-detection will be ignored)

So... unchecking the checkbox, and messages look OK.

Thanks for all the help.  :-)

I have a bunch of local folders, where I organize my important email. I recently changed the "Fonts & Encodings" setting to "Unicode (UTF-8)" on both Outgoing and Incoming Mail settings. This setting is at: >>> Tools, Options, Display, Advanced. Ever since that point, every email message I move to my primary local folder, all the double-spaces become Â-space. In my inbox, the message looks like this: Tools, Options, Display, Advanced: outgoing: Unicode (UTF-8) incoming: Unicode (UTF-8) Ctrl-click-drag to the main local folder, it becomes: Tools, Options, Display, Advanced: outgoing: Unicode (UTF-8) incoming: Unicode (UTF-8) But... I created a new local folder just as a test, and the same message copied to that folder, looks fine. In fact, it is only one folder with this problem. Any ideas on how to force the old folder to stop changing characters? Oh my!!! Right-click on the folder, properties: Fallback Text Encoding = Western (ISO-8859-1), and checkbox checked: Apply encoding to all messages in the folder (individual message text encoding settings and auto-detection will be ignored) So... unchecking the checkbox, and messages look OK. Thanks for all the help. :-)

Chosen solution

Can I assume this is "fixed"

Read this answer in context 👍 0

All Replies (3)

more options

Chosen Solution

Can I assume this is "fixed"

more options

Yes, the problem is "fixed" on my workstation. I've seen the "Â injection" (or "A hat") issue for so long -- from others using TBird -- and I have tried searching these forums for an answer, without any luck.

So in the process of writing the post above, I tried the right-click-on-the-folder action for the first time ever, and discovered the options there. I continued to add the solution to the post, in hopes that this will help others in the future.

What would really be nice, though, is if someone sharper than me could figure out a way to get Thunderbird to stop changing two spaces into the Â-space character pair, EVEN when an email is moved from one folder to another when they have the bogus settings.

more options

Stevec5088 said

What would really be nice, though, is if someone sharper than me could figure out a way to get Thunderbird to stop changing two spaces into the Â-space character pair, EVEN when an email is moved from one folder to another when they have the bogus settings.

I understand where you are coming from, but I do not think we will ever see resolution whilst ever the on ANSI character sets are supported in email. (That is an internet standard)

While I do think Thunderbird could do with a setting checker that might highlight such anomalies, is is unlikely to eventuate unless I go learn JavaScript and write it myself.

The changes BTW are actually a side effect of how windows renders the text when a font does not have the desired character. In the days of ANSI it used to put squares in place of the missing characters, but in UNICODE it "substitutes"