Re: Western vs Unicode - why doesn't SM pick the right one?
flyguy wrote on 11/12/2014 21:18: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the View>Character Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? Five years later than the OP, I also have the same problem. No matter whether the e-mail declares its character set as UTF-8 in its source code, Seamonkey always displays its contents as Western, thus garbling every special or accented character. So for every e-mail I read, I have to manually select Unicode in the View -> Text encoding menu. I have already tried to change the settings in the "Edit -> Preferences -> Mail & Newsgroups -> Text Encoding" menu to every existing option, but none worked. Any ideas ? ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
flyguy wrote: mozilla-lists.mbou...@spamgourmet.com wrote, On 12/12/2014 2:40 PM: flyguy wrote: mozilla-lists.mbou...@spamgourmet.com wrote, On 12/11/2014 1:42 PM: flyguy wrote: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? It should pick up the encoding from the Content-Type header of the email. Having said that, at one time I used to find the message pane in the main window didn't switch encodings when moving between emails, but pressing F8 a couple of times to hide and then show it again sorted it out. Haven't noticed that problem for a long time now. Even then, fully opening emails in a separate window did use the correct encoding. Alternatively, it could be that the problematic emails have the wrong encoding, or perhaps no encoding, specified in the header. e.g. the sending application has specified iso-8859-1 in the header but actually encoded the content in utf-8. If that's the case, at least you've got an option to manually override the encoding so that it can be displayed correctly ;o) The email has these lines in it: I hope you mean when looking at the message source; you shouldn't see these lines when reading normally (I do occasionally see some of the source in the message pane, but pressing F8 a couple of times to hide and show the message pane fixes that - which you mention below doesn't help in your case so I don't think that's it). Content-Type: multipart/alternative; boundary=_--=_MCPart_1762143897 Content-Type: text/plain; charset=utf-8; format=fixed ... and two or three with Content-Type in parenthesis. The content following Content-Type: text/plain... will be the plain text version. If there's a text/html alternative SeaMonkey will probably display that instead, unless you've set View Message Body As Plain Text. I'm not sure what you mean about Content-Type being in parentheses, but that may be the problem. It would be interesting to see the complete structure of one of those emails. If you're not sure what to look for and there's nothing in one of them you don't mind sharing, it's probably easiest to View Message Source, copy the source into a plain text document, and upload it somewhere (or send as an attachment, but copy my address - mozilla-lists.mbourne at spamgourmet.com - if you do that as I think the mailing list strips attachments). I just forwarded the email to your spamgourment address. Thanks, but I'd need the original source. Forwarding causes SeaMonkey to reformat it, with any additional message you add, so loses any original signs of a problem. The following should work (easier than my previous instruction to view and copy the source): - Open the email. - Make sure it is one of the ones which displays incorrectly. - File Save As File - For Save as type, select Mail Files (*.eml) - Save - Attach that file to an email to me Oddly, tonight SM is displaying the email properly. The View Character encoding shows as Unicode after I click on the email, even if I set it to Western beforehand. I'm fairly sure I didn't change anything. I'm not sure, but it's possible that SeaMonkey remembers any manual selections for each email and uses them next time it's opened. Thanks, Mark. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
flyguy wrote: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? just fill in unicode8 at the right places sincerely -- Vink User agent: Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 Windows7 Premium 32bits --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. http://www.avast.com ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
flyguy wrote: mozilla-lists.mbou...@spamgourmet.com wrote, On 12/11/2014 1:42 PM: flyguy wrote: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? It should pick up the encoding from the Content-Type header of the email. Having said that, at one time I used to find the message pane in the main window didn't switch encodings when moving between emails, but pressing F8 a couple of times to hide and then show it again sorted it out. Haven't noticed that problem for a long time now. Even then, fully opening emails in a separate window did use the correct encoding. Alternatively, it could be that the problematic emails have the wrong encoding, or perhaps no encoding, specified in the header. e.g. the sending application has specified iso-8859-1 in the header but actually encoded the content in utf-8. If that's the case, at least you've got an option to manually override the encoding so that it can be displayed correctly ;o) I forgot to mention I'm using SM 2.26 on a Win 8.1 computer. For the record, I'm currently using SM 2.26.1 on Windows Vista. The email has these lines in it: I hope you mean when looking at the message source; you shouldn't see these lines when reading normally (I do occasionally see some of the source in the message pane, but pressing F8 a couple of times to hide and show the message pane fixes that - which you mention below doesn't help in your case so I don't think that's it). Content-Type: multipart/alternative; boundary=_--=_MCPart_1762143897 Content-Type: text/plain; charset=utf-8; format=fixed ... and two or three with Content-Type in parenthesis. The content following Content-Type: text/plain... will be the plain text version. If there's a text/html alternative SeaMonkey will probably display that instead, unless you've set View Message Body As Plain Text. I'm not sure what you mean about Content-Type being in parentheses, but that may be the problem. It would be interesting to see the complete structure of one of those emails. If you're not sure what to look for and there's nothing in one of them you don't mind sharing, it's probably easiest to View Message Source, copy the source into a plain text document, and upload it somewhere (or send as an attachment, but copy my address - mozilla-lists.mbourne at spamgourmet.com - if you do that as I think the mailing list strips attachments). Otherwise you could try picking out the parts defining the structure and just copy them into an email. Basically you'd be looking for: - the main Content-Type header - any blocks starting with one of the separators mentioned as the boundary parameter to any of the Content-Type lines, up to the next blank line (these blocks will probably contain another Content-Type header and possibly others) For an email with attachments as well as plain text and HTML alternative parts, there should be something like the following; text in square brackets is notes I've added: [several headers] Content-Type: multipart/mixed; boundary=_006_141836474851268922sparsholtacuk_ [several more headers] --_006_141836474851268922sparsholtacuk_ Content-Type: multipart/alternative; boundary=_000_141836474851268922sparsholtacuk_ --_000_141836474851268922sparsholtacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [content as plain text] --_000_141836474851268922sparsholtacuk_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [content as HTML] --_000_141836474851268922sparsholtacuk_-- --_006_141836474851268922sparsholtacuk_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name=filename.docx Content-Description: filename.docx Content-Disposition: attachment; filename=filename.docx; size=188079; creation-date=Thu, 11 Dec 2014 22:30:02 GMT; modification-date=Thu, 11 Dec 2014 22:30:02 GMT Content-ID: 88d57fea92099c4c89f4f2d3f8011...@eurprd07.prod.outlook.com Content-Transfer-Encoding: base64 [attachment] --_006_141836474851268922sparsholtacuk_-- Pressing f8 has no effect; neither does opening the email in it's own window. I suspected it wouldn't, but thought it worth mentioning in case it helped. Mark. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
mozilla-lists.mbou...@spamgourmet.com wrote: The content following Content-Type: text/plain... will be the plain text version. If there's a text/html alternative SeaMonkey will probably display that instead, unless you've set View Message Body As Plain Text. I'm not sure what you mean about Content-Type being in parentheses, but that may be the problem. It would be interesting to see the complete structure of one of those emails. If you're not sure what to look for and there's nothing in one of them you don't mind sharing, it's probably easiest to View Message Source, copy the source into a plain text document, and upload it somewhere (or send as an attachment, but copy my address - mozilla-lists.mbourne at spamgourmet.com - if you do that as I think the mailing list strips attachments). It probably includes a plain-text version and an HTML version, separated by the specified boundary. The encoding specification may be different in the different parts, though in principle it shouldn't be. The OP might try View | Message Body As... and choose a different option from the one he's viewing now. If at least one of the parts is correctly specified and encoded, he'll get a workable view. If not, he'll have to force the right encoding by choosing it from View | Encoding... There's not an awful lot SeaMonkey can do to guess correctly if the sending program lies about the encoding. In such cases, only ad hoc user intervention works. But once you've found the right answer, replying works fine. BTW, you're not doing yourself any good by munging your address in your message body if you give the clear version in your From: field; you're only inconveniencing your correspondents. If you really want to hide from the spambots, do it in the From field as well. As it is, your clear address appears in the attribution line of every reply (see above). -- War doesn't determine who's right, just who's left. -- Paul B. Gallagher ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
mozilla-lists.mbou...@spamgourmet.com wrote, On 12/12/2014 2:40 PM: flyguy wrote: mozilla-lists.mbou...@spamgourmet.com wrote, On 12/11/2014 1:42 PM: flyguy wrote: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? It should pick up the encoding from the Content-Type header of the email. Having said that, at one time I used to find the message pane in the main window didn't switch encodings when moving between emails, but pressing F8 a couple of times to hide and then show it again sorted it out. Haven't noticed that problem for a long time now. Even then, fully opening emails in a separate window did use the correct encoding. Alternatively, it could be that the problematic emails have the wrong encoding, or perhaps no encoding, specified in the header. e.g. the sending application has specified iso-8859-1 in the header but actually encoded the content in utf-8. If that's the case, at least you've got an option to manually override the encoding so that it can be displayed correctly ;o) I forgot to mention I'm using SM 2.26 on a Win 8.1 computer. For the record, I'm currently using SM 2.26.1 on Windows Vista. The email has these lines in it: I hope you mean when looking at the message source; you shouldn't see these lines when reading normally (I do occasionally see some of the source in the message pane, but pressing F8 a couple of times to hide and show the message pane fixes that - which you mention below doesn't help in your case so I don't think that's it). Content-Type: multipart/alternative; boundary=_--=_MCPart_1762143897 Content-Type: text/plain; charset=utf-8; format=fixed ... and two or three with Content-Type in parenthesis. The content following Content-Type: text/plain... will be the plain text version. If there's a text/html alternative SeaMonkey will probably display that instead, unless you've set View Message Body As Plain Text. I'm not sure what you mean about Content-Type being in parentheses, but that may be the problem. It would be interesting to see the complete structure of one of those emails. If you're not sure what to look for and there's nothing in one of them you don't mind sharing, it's probably easiest to View Message Source, copy the source into a plain text document, and upload it somewhere (or send as an attachment, but copy my address - mozilla-lists.mbourne at spamgourmet.com - if you do that as I think the mailing list strips attachments). Otherwise you could try picking out the parts defining the structure and just copy them into an email. Basically you'd be looking for: - the main Content-Type header - any blocks starting with one of the separators mentioned as the boundary parameter to any of the Content-Type lines, up to the next blank line (these blocks will probably contain another Content-Type header and possibly others) For an email with attachments as well as plain text and HTML alternative parts, there should be something like the following; text in square brackets is notes I've added: [several headers] Content-Type: multipart/mixed; boundary=_006_141836474851268922sparsholtacuk_ [several more headers] --_006_141836474851268922sparsholtacuk_ Content-Type: multipart/alternative; boundary=_000_141836474851268922sparsholtacuk_ --_000_141836474851268922sparsholtacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [content as plain text] --_000_141836474851268922sparsholtacuk_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [content as HTML] --_000_141836474851268922sparsholtacuk_-- --_006_141836474851268922sparsholtacuk_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name=filename.docx Content-Description: filename.docx Content-Disposition: attachment; filename=filename.docx; size=188079; creation-date=Thu, 11 Dec 2014 22:30:02 GMT; modification-date=Thu, 11 Dec 2014 22:30:02 GMT Content-ID: 88d57fea92099c4c89f4f2d3f8011...@eurprd07.prod.outlook.com Content-Transfer-Encoding: base64 [attachment] --_006_141836474851268922sparsholtacuk_-- Pressing f8 has no effect; neither does opening the email in it's own window. I suspected it wouldn't, but thought it worth mentioning in case it helped. I just forwarded the email to your spamgourment address. Oddly, tonight SM is displaying the email properly. The View Character encoding shows as Unicode after I click on the email, even if I set it to Western beforehand. I'm fairly sure I didn't change anything. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Western vs Unicode - why doesn't SM pick the right one?
Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
flyguy wrote: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? It should pick up the encoding from the Content-Type header of the email. Having said that, at one time I used to find the message pane in the main window didn't switch encodings when moving between emails, but pressing F8 a couple of times to hide and then show it again sorted it out. Haven't noticed that problem for a long time now. Even then, fully opening emails in a separate window did use the correct encoding. Alternatively, it could be that the problematic emails have the wrong encoding, or perhaps no encoding, specified in the header. e.g. the sending application has specified iso-8859-1 in the header but actually encoded the content in utf-8. If that's the case, at least you've got an option to manually override the encoding so that it can be displayed correctly ;o) Mark. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
flyguy wrote: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? Two ways: 1) Tell the webmaster to specify the correct encoding in his code. ;-) 2) Look at Edit | Preferences | Browser and see what you've specified at the bottom for legacy content that doesn't declare its language. I don't see how you can specify Unicode there, but for example if your fallback language is Chinese and most of the pages you visit are written in Russian, you'll get a lot of bad guesses. For similar issues with mail and newsgroups, look under Edit | Preferences | Mail Newsgroups | Character Encoding. -- War doesn't determine who's right, just who's left. -- Paul B. Gallagher ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Western vs Unicode - why doesn't SM pick the right one?
mozilla-lists.mbou...@spamgourmet.com wrote, On 12/11/2014 1:42 PM: flyguy wrote: Most of my email displays properly with Western character encoding, but about 10-20% requires selecting Unicode from the ViewCharacter Encoding list. I've tried to make SM select it automatically, but it still doesn't. Is there anyway to make it pick the proper character encoding? It should pick up the encoding from the Content-Type header of the email. Having said that, at one time I used to find the message pane in the main window didn't switch encodings when moving between emails, but pressing F8 a couple of times to hide and then show it again sorted it out. Haven't noticed that problem for a long time now. Even then, fully opening emails in a separate window did use the correct encoding. Alternatively, it could be that the problematic emails have the wrong encoding, or perhaps no encoding, specified in the header. e.g. the sending application has specified iso-8859-1 in the header but actually encoded the content in utf-8. If that's the case, at least you've got an option to manually override the encoding so that it can be displayed correctly ;o) I forgot to mention I'm using SM 2.26 on a Win 8.1 computer. The email has these lines in it: Content-Type: multipart/alternative; boundary=_--=_MCPart_1762143897 Content-Type: text/plain; charset=utf-8; format=fixed ... and two or three with Content-Type in parenthesis. Pressing f8 has no effect; neither does opening the email in it's own window. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey