We're calling on all EU-based Mozillians with iOS or iPadOS devices to help us monitor Apple’s new browser choice screens. Join the effort to hold Big Tech to account!

搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

了解更多

Copy/move to local folder: Â injected into text

  • 3 回覆
  • 1 有這個問題
  • 1 次檢視
  • 最近回覆由 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. :-)

被選擇的解決方法

Can I assume this is "fixed"

從原來的回覆中察看解決方案 👍 0

所有回覆 (3)

more options

選擇的解決方法

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"