为提升您的使用体验,本站正在维护,部分功能暂时无法使用。如果本站文章无法解决您的问题,您想要向社区提问的话,请到 Twitter 上的 @FirefoxSupport 或 Reddit 上的 /r/firefox 提问,我们的支持社区将会很快回复您的疑问。

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

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"