This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

作者 poq
收信人 Arfrever, Nicholas.Cole, ezio.melotti, inigoserna, loewis, poq, tchrist, vstinner, zeha
日期 2012-03-11.00:32:14
SpamBayes Score 1.652261e-05
Marked as misclassified
Message-id <1331425935.51.0.471117522786.issue12568@psf.upfronthosting.co.za>
In-reply-to
内容
It seems this is a bit of a minefield...

GNOME Terminal/libvte has an environment variable (VTE_CJK_WIDTH) to override the handling of ambiguous width characters. It bases its default on the locale (with the comment 'This is basically what GNU libc does').

urxvt just uses system wcwidth.

Xterm uses some voodoo to decide between system wcwidth and mk_wcwidth(_cjk): http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c

I think the simplest solution is to just expose libc's wc(s)width. It is widely used and is most likely to match the behaviour of the terminal.

FWIW I wrote a little script to test the widths of all Unicode characters, and came up with the following logic to match libvte behaviour:

def wcwidth(c, legacy_cjk=False):
	if c in u'\t\r\n\10\13\14': raise ValueError('character %r has no intrinsic width' % c)
	if c in u'\0\5\7\16\17': return 0
	if u'\u1160' <= c <= u'\u11ff': return 0 # hangul jamo
	if unicodedata.category(c) in ('Mn', 'Me', 'Cf') and c != u'\u00ad': return 0 # 00ad = soft hyphen
	eaw = unicodedata.east_asian_width(c)
	if eaw in ('F', 'W'): return 2
	if legacy_cjk and eaw == 'A': return 2
	return 1
历史
日期 用户 动作 参数
2012-03-11 00:32:15poq修改recipients: + poq, loewis, vstinner, ezio.melotti, Arfrever, inigoserna, zeha, Nicholas.Cole, tchrist
2012-03-11 00:32:15poq修改messageid: <1331425935.51.0.471117522786.issue12568@psf.upfronthosting.co.za>
2012-03-11 00:32:14poq链接issue12568 messages
2012-03-11 00:32:14poq创建