> I can’t imagine that adding a code page helps anything, nor that changing an existing behavior helps anything.
It allows implementers to be compliant with unicode.org and compatible with all (Microsoft) browsers at the same time. Currently these are mutually exclusive. > People really should be using UTF-8. In contrast, bringing the cp1252 definition into line with real implementations and recommending UTF-8 for new developments are *not*mutually exclusive. On Fri, Dec 7, 2012 at 4:41 PM, Shawn Steele <[email protected]>wrote: > It’s a variation. The undefined codepoints in 1252 probably shouldn’t > be used, and I can’t imagine that adding a code page helps anything, nor > that changing an existing behavior helps anything. People really should be > using UTF-8.**** > > ** ** > > -Shawn**** > > ** ** > > *From:* Buck Golemon [mailto:[email protected]] > *Sent:* Friday, December 7, 2012 4:34 PM > *To:* Shawn Steele > *Cc:* unicode > > *Subject:* Re: data for cp1252**** > > ** ** > > I've been told that bestfit1252 wasn't meant to redefine the cp1252 > mapping, although its first line declares "CODEPAGE 1252".**** > > ** ** > > Is it a separate encoding or not?**** > > ** ** > > If so, I'll submit a new "bestfit1252" to the python stdlib.**** > > If not, I believe the cp1252 mapping needs brought into line.**** > > > > > **** > > On Fri, Dec 7, 2012 at 4:27 PM, Shawn Steele <[email protected]> > wrote:**** > > J**** > > ** ** >
