Bug report

Bug description:

iso2022processesc() in Modules/cjkcodecs/_codecs_iso2022.c only checks that a designated charset is in the codec's table, not that it is designated to the G set (G0/G1/G2) the encoding assigns it to. So iso2022_kr accepts ESC $ ( C and decodes the following ASCII as Korean, the iso2022_jp* codecs silently eat G1 designations they do not have, and iso2022_jp_2 can reach an internal error path that raises RuntimeError regardless of the error handler.

>>> b'abc\x1b$(Cdefg'.decode('iso2022_kr')
'abc鴨鉛'
>>> b'ab\x1b$)Bdef'.decode('iso2022_jp')
'abdef'
>>> b'\x1b.J\x1bNx'.decode('iso2022_jp_2', 'replace')
Traceback (most recent call last):
  ...
RuntimeError: internal codec error

The RuntimeError also comes out of email.message_from_bytes(...).get_filename() for a filename*=iso-2022-jp-2''a%1B.J%1BNx parameter. These escapes should raise UnicodeDecodeError like any other invalid sequence. Related: gh-153603 (same designation table, different bug).

The valid designations for each encoding are fixed by their RFCs: RFC 1468 (ISO-2022-JP: ESC ( B, ESC ( J, ESC $ @, ESC $ B, all G0), RFC 2237 (ISO-2022-JP-1 adds ESC $ ( D to G0), RFC 1554 (ISO-2022-JP-2 adds ESC $ A, ESC $ ( C, ESC $ ( D to G0 and ESC . A, ESC . F to G2) and RFC 1557 (ISO-2022-KR: only ESC $ ) C, designating KS C 5601 to G1). The designation mechanism itself is ISO/IEC 2022 / ECMA-35.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-160187: Reject ISO-2022 designations into the wrong G set #160188
• [3.15] gh-160187: Reject ISO-2022 designations into the wrong G set (GH-160188) #161064