27675 2014-12-19 16:49:47 +0000 U+FFFD in euc_kr index 2014-12-20 09:42:49 +0000 1 1 1 Unclassified WHATWG Encoding unspecified PC Windows NT RESOLVED FIXED P2 normal Unsorted 1 public+w3 annevk mike www-international sideshowbarker+encodingspec oldest_to_newest 116560 0 public+w3 2014-12-19 16:49:47 +0000 The updated euc_kr table now has the following entries: ---8<--- 5916 0xFFFD � (REPLACEMENT CHARACTER) 5917 0xFFFD � (REPLACEMENT CHARACTER) 5918 0xFFFD � (REPLACEMENT CHARACTER) 5919 0xFFFD � (REPLACEMENT CHARACTER) 5920 0xFFFD � (REPLACEMENT CHARACTER) 5921 0xFFFD � (REPLACEMENT CHARACTER) [snip] 5948 0xFFFD � (REPLACEMENT CHARACTER) 5949 0xFFFD � (REPLACEMENT CHARACTER) 5950 0xFFFD � (REPLACEMENT CHARACTER) 5951 0xFFFD � (REPLACEMENT CHARACTER) 5952 0xFFFD � (REPLACEMENT CHARACTER) 5953 0xFFFD � (REPLACEMENT CHARACTER) ---8<--- They correspond to byte sequences A0 5B..60 and A0 7B..80, which are gaps between UHC ranges. I don't think Bug 16691 intended this (as they are the only occurrences of U+FFFD throughout the indices at the moment). This causes an otherwise valid decoder to accept those sequences even when the fatal mode is in the use. 116563 1 annevk 2014-12-19 19:13:19 +0000 Should I remove the space from your Korean name? Other contributors with a Korean name do not have a space there. See https://encoding.spec.whatwg.org/#acknowledgments for context. Anyway, that's an aside, thanks a lot for spotting for this! This was a stupid mistake when regenerating the index. https://github.com/whatwg/encoding/commit/7991e7b9add2a6d1ccd34e637d2c4e15ae7bbf7c 116598 2 public+w3 2014-12-20 02:30:16 +0000 That is intended (i.e. I personally prefer that), but if you want to be consistent I don't mind normalizing that. 116601 3 annevk 2014-12-20 09:42:49 +0000 Thanks, I added a note so I don't forget about your preference. It'll stay as is.