`iso2022_jp_3` encodes U+9B1D but decodes the result as U+9B1C
维护者通常 1 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 84/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- python
调研方向
阅读 Modules/cjkcodecs/_codecs_iso2022.c 中 jisx0213_2000_2_decoder 附近的代码，并将 plane 2 的映射逻辑与 plane 1 解码器进行比较。Issue 指出了缺失的 else 和受影响的单元格；使用 PR #160155 中的测试 RoundTripBugs.test_iso2022_jp_3_mapping 进行回归检查。完成标准是 iso2022_jp_3 能正确往返转换 U+9B1D，同时保留预期的 2000 映射行为。
由索引模型根据 Issue 内容生成。
描述
Bug description
>>> '鬝'.encode('iso2022_jp_3')
b'\x1b$(P};\x1b(B'
>>> _.decode('iso2022_jp_3')
'鬜'
>>> hex(ord(_))
'0x9b1c'
JIS X 0213:2004 changed plane 2 row 93 cell 27 (0x7D3B) from U+9B1D to U+9B1C, and CPython emulates the 2000 mapping in the codecs named after that edition. euc_jisx0213 and shift_jisx0213 do so in both directions:
>>> '鬝'.encode('euc_jisx0213').decode('euc_jisx0213')
'鬝'
>>> '鬜'.encode('euc_jisx0213')
Traceback (most recent call last):
File "<python-input-5>", line 1, in <module>
'鬜'.encode('euc_jisx0213')
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
UnicodeEncodeError: 'euc_jisx0213' codec can't encode character '鬜' in position 0: illegal multibyte sequence
iso2022_jp_3 only does it when encoding: it accepts U+9B1D and rejects U+9B1C like the other 2000 codecs, but decodes 0x7D3B as U+9B1C, as iso2022_jp_2004 does.
The cause is in jisx0213_2000_2_decoder, Modules/cjkcodecs/_codecs_iso2022.c lines 728-739. The EMULATE_JISX0213_2000_DECODE_PLANE2_CHAR macro expands to an if that sets u = 0x9B1D for this cell, but the table lookup that follows it is a plain if (TRYMAP_DEC_ST(jisx0213_2_bmp, ...)) rather than else if, so it runs regardless and overwrites u with the 2004 value. The plane 1 decoder just above uses else if after its emulation macro and is fine, as are the EUC and Shift_JIS codecs, which use the OUTCHAR form of the macro in _codecs_jp.c. So the fix is the missing else.
A scan of every code point through iso2022_jp_3 found no other character that comes back different, so it should be just this one cell.
Found by the Hypothesis tests in #160155, where it is pinned as RoundTripBugs.test_iso2022_jp_3_mapping under expectedFailure and kept out of the generated text otherwise.
CPython versions tested on
CPython main (6e1bd24e4d8)
Operating systems tested on
Linux
- 主要语言
- Python
- 星标
- 77.8k
- 派生
- 37.7k
- 平均合并
- 12 小时 27 分钟
- 30 天内合并 PR
- 710
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
python/cpython 的其他 Issue
-
3.16 build type-bug
难度 2/5 1-3 小时 新手友好度 62/100
python/cpython#160829 · 4 条评论 ·
维护者通常 1 天内回复
-
dependencies infra topic-ensurepip
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
symtable: repr() of a Symbol raises TypeError under -X lazy_imports=all可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭stdlib topic-lazy-imports type-bug
难度 2/5 1-3 小时 新手友好度 72/100
python/cpython#160810 · 3 条评论 ·
维护者通常 1 天内回复
-
tarfile: extractfile(member).read() of a sparse member is slow due to repeated bytes concatenation未关闭performance stdlib triaged type-bug
难度 2/5 1-3 小时 新手友好度 75/100
python/cpython#160774 · 2 条评论 ·
维护者通常 1 天内回复
-
tests topic-profiling type-bug
难度 2/5 1-3 小时 新手友好度 78/100
python/cpython#160334 · 1 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
factory
难度 2/5 1-3 小时 新手友好度 78/100
Arize-ai/phoenix#17420 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 84/100
FireDynamics/LEDSmokeAnalysis#176 ·
维护者通常 1 天内回复
-
PC
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
dependencies
难度 2/5 1-3 小时 新手友好度 68/100
dlt-contrib/dlt-filesystem#51 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复