This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
>>> -- 5.4: Error handling in line with EUC-JP and Shift-JIS. A second >>> byte 0x53--0xA0 after a first byte 0xC6 (the undefined area after the >>> last UHC hangul) is arguably outside the encoding as well and not just >>> accidentally undefined, so such a byte should strictly speaking be >>> reprocessed as well. >> >> It is already in line. Because pointer (formerly index) would be null. > > Hm, I have now attempted to apply the algorithm to the byte sequence C6 > 53 and I seem to get the pointer value (26+26+126) x (C6-0x81) + > (0x53-0x41) = 12,300, which is not null. Am I missing something?
In other words, should bytes in the range 0x53 to 0xA0 following lead byte 0xC6 be eaten or not.
Firefox, Safari, Opera and IE6 all handle C6 0x53 in the same way as C7 0x53 (the last UHC codepoint being C6 0x52), i.e., 0x53 is reprocessed in both cases (Firefox) or neither (the others). Introducing a difference here seems a bad idea. Related: <https://www.w3.org/Bugs/Public/show_bug.cgi?id=16771> (Big5 reprocessing).
*** This bug has been marked as a duplicate of bug 16691 ***