<div dir="ltr"><div dir="ltr">On Thu, 11 Jan 2018 at 11:43 Random832 <<a href="mailto:random832@fastmail.com">random832@fastmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Maybe we need a new error handler that maps unassigned bytes in the 
range 0x80-0x9f to a single character in the range U+0080-U+009F. Do any
 of the encodings being discussed have behavior other than the "normal" 
version of the encoding plus what I just described?<br>
</blockquote><br>(accidentally replied individually instead of replaying all)<br><div><div class="inbox-inbox-uyb8Gf"><div><div class="inbox-inbox-vI"><div dir="ltr"><div class="gmail_quote"><div><br></div></div></div></div></div></div><div class="inbox-inbox-uyb8Gf"><div><div class="inbox-inbox-F3hlO"><div dir="ltr"><div class="gmail_quote"><div>There
 is one more difference I have found between Python's encodings and 
WHATWG's. In Python's codepage 1255, b'\xca' is undefined. In WHATWG's, 
it maps to U+05BA HEBREW POINT HOLAM HASER FOR VAV. I haven't tracked 
down what the Unicode Consortium has to say about this. <br></div><div><br></div><div>Other than that, all the differences are adding the fall-throughs in the range U+0080 to U+009F. For example, elsewhere in windows-1255, the byte b'\xff' is undefined, and it remains undefined in WHATWG's mapping.<br></div></div></div></div></div></div><br></div></div>