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"