email: non-ASCII whitespace after a space is lost from address display names
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
The bug is in get_fws() in Lib/email/_header_value_parser.py, which uses value.lstrip() and so strips Unicode whitespace beyond SP and HTAB. The issue body already links PR gh-161679, though the linked-PR list is empty, so check that PR before starting. Done means display names such as '. \xa0b' survive a round trip through the email parser, with a regression test in Lib/test/test_email.
由索引模型根据 Issue 内容生成。
描述
Bug description:
The email header parser silently drops Unicode whitespace other than SP and HTAB (for example U+00A0 NO-BREAK SPACE, U+2003 EM SPACE, U+3000 IDEOGRAPHIC SPACE) when it follows a space in an address display name. A message generated by the email package itself doesn't round-trip:
import email
from email import policy
from email.message import EmailMessage
from email.headerregistry import Address
m = EmailMessage()
m['To'] = Address('. \xa0b', 'u', 'example.com')
print(m['To']) # =?utf-8?q?=2E_=C2=A0?=b <[email protected]>
m2 = email.message_from_string(m.as_string(), policy=policy.default)
print(ascii(m2['To'].addresses[0].display_name)) # '. b', expected '. \xa0b'
Received mail is affected too: To: =?utf-8?q?x_=C2=A0b?= <[email protected]> gives the display name 'x b'.
The cause is get_fws() in Lib/email/_header_value_parser.py:
def get_fws(value):
"""FWS = 1*WSP
...
newvalue = value.lstrip()
str.lstrip() strips all Unicode whitespace, but FWS is only SP and HTAB (RFC 5322 §3.2.2: FWS = ([*WSP CRLF] 1*WSP) / obs-FWS; RFC 5234: WSP = SP / HTAB). The extra characters end up in a WhiteSpaceTerminal, whose value is always a single space, so they are lost.
I couldn't find a test or comment saying stripping all Unicode whitespace was intended.
CPython versions tested on:
3.13, CPython main branch
Operating systems tested on:
Windows
Linked PRs
- gh-161679
- 主要语言
- Python
- 星标
- 78.2k
- 派生
- 36.6k
- 平均合并
- 19 小时 57 分钟
- 30 天内合并 PR
- 630
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
python/cpython 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
stdlib type-bug
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
extension-modules stdlib topic-XML type-bug
难度 2/5 1-3 小时 新手友好度 76/100
python/cpython#161807 · 1 条评论 ·
维护者通常 1 天内回复
-
stdlib type-feature
难度 2/5 1-3 小时 新手友好度 78/100
python/cpython#161788 · 7 条评论 ·
维护者通常 1 天内回复
-
extension-modules topic-IO type-bug
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
cpp-best-practices/project_validator#267 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
维护者通常 1 天内回复
-
[Bug] Sending a Telegram message chain twice duplicates mentions可能已有人在做 @123XieC 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
AstrBotDevs/AstrBot#11125 ·
维护者通常 1 天内回复
-
backend bug priority: high
难度 2/5 1-3 小时 新手友好度 72/100
nooriegarg/ContribIQ#73 ·
维护者通常 1 天内回复
-
bug p3 security
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复