Message145523
| Author |
loewis |
| Recipients |
Nicholas.Cole, ezio.melotti, inigoserna, loewis, tchrist, vstinner, zeha |
| Date |
2011年10月14日.14:56:58 |
| SpamBayes Score |
0.0076282495 |
| Marked as misclassified |
No |
| Message-id |
<1318604219.18.0.9022990154.issue12568@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I think the WideCharToMultibyte approach is just incorrect.
I'm -1 on using wcswidth, though. We already have unicodedata.east_asian_width, which implements http://unicode.org/reports/tr11/
The outcomes of this function are these:
- F: full-width, width 2, compatibility character for a narrow char
- H: half-width, width 1, compatibility character for a narrow char
- W: wide, width 2
- Na: narrow, width 1
- A: ambiguous; width 2 in Asian context, width 1 in non-Asian context
- N: neutral; not used in Asian text, so has no width. Practically, width can be considered as 1 |
|