latin1 and cp1252 inconsistent?

Sat Nov 17 13:13:51 EST 2012

On Sat, Nov 17, 2012 at 11:08 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Sat, Nov 17, 2012 at 9:56 AM, <buck at yelp.com> wrote:
>> "should" is a wish. The reality is that documents (and especially URLs) exist that can be decoded with latin1, but will backtrace with cp1252. I see this as a sign that a small refactorization of cp1252 is in order. The proposal is to change those "UNDEFINED" entries to "<control>" entries, as is done here:
>>>> http://dvcs.w3.org/hg/encoding/raw-file/tip/index-windows-1252.txt
>>>> and here:
>>>> ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt
>> The README for the "BestFit" document states:
>> """
> These tables include "best fit" behavior which is not present in the
> other files. Examples of best fit
> are converting fullwidth letters to their counterparts when converting
> to single byte code pages, and
> mapping the Infinity character to the number 8.
> """
>> This does not sound like appropriate behavior for a generalized
> conversion scheme. It is also noted that the "BestFit" document is
> not authoritative at:
>> http://www.iana.org/assignments/charset-reg/windows-1252

I meant to also comment on the first link, but forgot. As that
document is published by the W3C, I understand it to be specific to
the Web, which Python is not. Hence I think the more general Unicode
specification is more appropriate for Python.