W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

[whatwg] iso-2022-jp and octets over 0x7E

From: NARUSE, Yui <naruse@airemix.jp>
Date: Mon, 09 Jan 2012 06:03:37 +0900
Message-ID: <4F0A04A9.2040906@airemix.jp>
(2012/01/09 4:49), Anne van Kesteren wrote:
> On Sun, 08 Jan 2012 15:32:47 +0100, Anne van Kesteren <annevk at opera.com> wrote:
>> On Sun, 08 Jan 2012 01:37:14 +0100, NARUSE, Yui <naruse at airemix.jp> wrote:
>>> == iso-2022-jp
>>> === The to Unicode algorithm
>>> ==== Based on iso-2022-jp state
>>> ===== ASCII state
>>> ====== Based on octet:
>>> ======= Otherwise
>>>> If the fatal flag is set, return failure.
>>>> Otherwise, emit the fallback code point.
>>> Just FYI, IE and Opera show these bytes as Katakana.
>>> If octet is greater than 0xA0 and less than 0xE0, value is octet + 0xFEC0.
>>> Moreover IE shows any shift_jis characters here.
>>> It seems that IE uses the same converter both iso-2022-jp and shift_jis.
>> I have filed a bug on Opera to become more strict like Webkit/Gecko. If there is some evidence that approach is wrong though, we can turn it around.
> So just to be sure I checked again and in Opera you can only get the "special" single-octet behavior if you active a particular state first. If you are in ASCII, Opera will simply emit the octet unless it is 0x1B (ESC) so maybe there is a system font that does something special for those characters? Or maybe you meant something else?

Ah, you are correct.
Opera's behavior is different from IE and it is clearly wrong.

NARUSE, Yui  <naruse at airemix.jp>
Received on Sunday, 8 January 2012 13:03:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC