1256718 - Composer always turns charset=ISO-8859-1 ==> charset=windows-1252

Status: RESOLVED INVALID

(SeaMonkey :: Composer, defect)

Description

[R.K.]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:44.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
Build ID: 20151103191810

Steps to reproduce:

loading HTML file with charset=ISO-8859-1   (latin-1).
saving after just adding and deleting a space somewhere.


Actual results:

resulting file is  charset=windows-1252.
diff -u shows no other change.


Expected results:

retain ISO-8859-1 encoding. "windows" looks strange. And its not really the same (0x80..0x9f)


Table of Differenzes: 
number; ISO-8859-1; windows-1252.

0x80  u'\x80' € u'\u20ac'
0x81  u'\x81'  u''
0x82  u'\x82' ‚ u'\u201a'
0x83  u'\x83' ƒ u'\u0192'
0x84  u'\x84' „ u'\u201e'
0x85 u'\x85' … u'\u2026'
0x86  u'\x86' † u'\u2020'
0x87  u'\x87' ‡ u'\u2021'
0x88  u'\x88' ˆ u'\u02c6'
0x89  u'\x89' ‰ u'\u2030'
0x8a  u'\x8a' Š u'\u0160'
0x8b  u'\x8b' ‹ u'\u2039'
0x8c  u'\x8c' Πu'\u0152'
0x8d  u'\x8d'  u''
0x8e  u'\x8e' Ž u'\u017d'
0x8f  u'\x8f'  u''
0x90  u'\x90'  u''
0x91  u'\x91' ‘ u'\u2018'
0x92  u'\x92' ’ u'\u2019'
0x93  u'\x93' “ u'\u201c'
0x94  u'\x94' ” u'\u201d'
0x95  u'\x95' • u'\u2022'
0x96  u'\x96' – u'\u2013'
0x97  u'\x97' — u'\u2014'
0x98  u'\x98' ˜ u'\u02dc'
0x99  u'\x99' ™ u'\u2122'
0x9a  u'\x9a' š u'\u0161'
0x9b  u'\x9b' › u'\u203a'
0x9c  u'\x9c' œ u'\u0153'
0x9d  u'\x9d'  u''
0x9e  u'\x9e' ž u'\u017e'
0x9f  u'\x9f' Ÿ u'\u0178'

Comment 1

[Philip Chee]

All major browsers including Firefox and SeaMonkey now treat ISO-8859-1 as a synonym for windows-1252.

https://en.wikipedia.org/wiki/Windows-1252

[quote]
Most modern web browsers and e-mail clients treat the MIME charset ISO-8859-1 as Windows-1252 to accommodate such mislabeling. This is now standard behavior in the HTML5 specification, which requires that documents advertised as ISO-8859-1 actually be parsed with the Windows-1252 encoding.
[/quote]

Comment 2

[Anne (:annevk)]

Indeed, see also bug 228779.