Re: data for cp1252

> 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 <Shawn.Steele_at_microsoft.com>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:buck_at_yelp.com]
> *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 <Shawn.Steele_at_microsoft.com>
> wrote:****
>
> J****
>
> ** **
>
Received on Fri Dec 07 2012 - 18:57:42 CST