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 天內回覆