While working on#84508 I noticed that the mapping forbig5hkscs codec has not been updated in a while. The current version in CPython reflects the Big-5 mappings forHKSCS-2004.

Since then, there have beensome updates:

• HKSCS-2008 adds 68 code points to the Big-5 encoding scheme
• HKSCS-2016 adds no code points to Big-5 (it's Unicode-only), but since new characters have been added to Unicode, the mapping can change
• after 2016, at least one mapped code point has been changed in an amendment

I can update the script and generate the mapping using the latest data available on theCCLI website, since I was already looking into this.

If we care about refreshingbig5hkscs at all, there are a couple questions about compatibility. In case mapping a Big-5 code X used to map to Unicode code point A (in HKSCS-2004), and is changed to map to B (in later versions):

1. should we: decode X to A, or to B?

2. should we: encode B to X, A to X, or both?

E.g. right now the Big-5 sequence 9D73 round-trips:

>>>x=bytes.fromhex('9D73')>>>x.decode('big5hkscs')=='\u4ca4'True>>>'\u4ca4'.encode('big5hkscs')==xTrue

If we followed the new HKSCS-2016 mapping with no compatibility provisions, this round-trip would instead go through the newly mapped character\u9fd0. This might be fine for some users, but it might break compatibility for others. So the questions are about what kind of compatibility we want to guarantee.

Related question which should not block this issue. For the web platform, WHATWG defines aBig5 encoding which includes HKSCS extensions, and already overlaps 99% withbig5hkscs, but is incompatible in some cases. Since one of the users of the CPython CJK codecs is html5lib, this means that html5lib does not comply with the web platform specifications. Should CPython be concerned with this, since it already provides the codec and the mapping tables, and it could provide a web-compatible codec with just a few fixups? Or does this belong in third-party libraries?