如何在Python的curses库中使用扩展字符？

发布于 2024-07-30 18:12:35 字数 433 浏览 4 评论 0原文

我一直在阅读有关 Python 中的 Curses 编程的教程，许多教程提到了使用扩展字符的能力，例如画线符号。他们是人物> 255，curses 库知道如何以当前终端字体显示它们。

有些教程说你像这样使用它：

c = ACS_ULCORNER

...有些人说你像这样使用它：（

c = curses.ACS_ULCORNER

这应该是一个盒子的左上角，就像一个垂直翻转的L）

无论如何，无论我使用哪种方法使用时，名称未定义，因此程序失败。我尝试了“导入诅咒”和“从诅咒导入*”，但都不起作用。

Curses 的 window() 函数使用了这些字符，所以我什至尝试在我的盒子上查找源代码，看看它是如何实现的，但我在任何地方都找不到它。

原文

I've been reading tutorials about Curses programming in Python, and many refer to an ability to use extended characters, such as line-drawing symbols. They're characters > 255, and the curses library knows how to display them in the current terminal font.

Some of the tutorials say you use it like this:

c = ACS_ULCORNER

...and some say you use it like this:

c = curses.ACS_ULCORNER

(That's supposed to be the upper-left corner of a box, like an L flipped vertically)

Anyway, regardless of which method I use, the name is not defined and the program thus fails. I tried "import curses" and "from curses import *", and neither works.

Curses' window() function makes use of these characters, so I even tried poking around on my box for the source to see how it does it, but I can't find it anywhere.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

oО清风挽发oО 2024-08-06 18:12:35

您必须将本地设置为 all，然后将输出编码为 utf-8，如下所示：

import curses
import locale

locale.setlocale(locale.LC_ALL, '')    # set your locale

scr = curses.initscr()
scr.clear()
scr.addstr(0, 0, u'\u3042'.encode('utf-8'))
scr.refresh()
# here implement simple code to wait for user input to quit
scr.endwin()

输出：
あ

you have to set your local to all, then encode your output as utf-8 as follows:

import curses
import locale

locale.setlocale(locale.LC_ALL, '')    # set your locale

scr = curses.initscr()
scr.clear()
scr.addstr(0, 0, u'\u3042'.encode('utf-8'))
scr.refresh()
# here implement simple code to wait for user input to quit
scr.endwin()

output:
あ

回复收藏 0 原文

折戟 2024-08-06 18:12:35

来自curses/__init__.py：

一些常量，最值得注意的是 ACS_*
那些，仅添加到C
调用 initscr() 后 _curses 模块的字典。（部分版本
SGI 的诅咒并没有定义价值观
对于这些常量，直到 initscr()
已被调用。）这个包装器
函数调用底层C
initscr()，然后复制
常数从
_curses 模块添加到curses 包的字典中。不要从诅咒中执行 'import *' 如果您需要
ACS_* 常量。

换句话说：

>>> import curses
>>> curses.ACS_ULCORNER
exception
>>> curses.initscr()
>>> curses.ACS_ULCORNER
>>> 4194412

From curses/__init__.py:

Some constants, most notably the ACS_*
ones, are only added to the C
_curses module's dictionary after initscr() is called. (Some versions
of SGI's curses don't define values
for those constants until initscr()
has been called.) This wrapper
function calls the underlying C
initscr(), and then copies the
constants from the
_curses module to the curses package's dictionary. Don't do 'from curses import *' if you'll be needing the
ACS_* constants.

In other words:

>>> import curses
>>> curses.ACS_ULCORNER
exception
>>> curses.initscr()
>>> curses.ACS_ULCORNER
>>> 4194412

回复收藏 0 原文

毁梦 2024-08-06 18:12:35

我相信以下内容是适当相关的，将在这个问题下发布。在这里我将使用 utfinfo.pl (另请参阅超级用户)。

首先，对于标准 ASCII 字符集，Unicode 代码点和字节编码是相同的：

$ echo 'a' | perl utfinfo.pl 
Char: 'a' u: 97 [0x0061] b: 97 [0x61] n: LATIN SMALL LETTER A [Basic Latin]

所以我们可以在 Python 的 curses 中执行以下操作：

window.addch('a')
window.border('a')

... 并且它按预期工作

但是，如果一个字符高于基本 ASCII，则存在差异，其中 addch 文档不一定明确。首先，我可以这样做：

window.addch(curses.ACS_PI)
window.border(curses.ACS_PI)

...在这种情况下，在我的 gnome-terminal 中，将呈现 Unicode 字符“π”。但是，如果您检查 ACS_PI，您会看到它是一个整数，值为 4194427 (0x40007b)；因此，以下内容也会呈现相同的字符（或评分者、字形？）“π”：

window.addch(0x40007b)
window.border(0x40007b)

为了查看发生了什么，我搜索了 ncurses 源代码，并发现了以下内容：

#define ACS_PI      NCURSES_ACS('{') /* Pi */  
#define NCURSES_ACS(c)  (acs_map[NCURSES_CAST(unsigned char,c)])
#define NCURSES_CAST(type,value) static_cast<type>(value)
#lib_acs.c: NCURSES_EXPORT_VAR(chtype *) _nc_acs_map(void): MyBuffer = typeCalloc(chtype, ACS_LEN);
#define typeCalloc(type,elts) (type *)calloc((elts),sizeof(type))
#./widechar/lib_wacs.c: { '{',  { '*',  0x03c0 }},  /* greek pi */

此处注意：

$ echo '{π' | perl utfinfo.pl 
Got 2 uchars
Char: '{' u: 123 [0x007B] b: 123 [0x7B] n: LEFT CURLY BRACKET [Basic Latin]
Char: 'π' u: 960 [0x03C0] b: 207,128 [0xCF,0x80] n: GREEK SMALL LETTER PI [Greek and Coptic]

..两者都与 ACS_PI 的 4194427 (0x40007b) 值无关。

因此，当 addch 和/或 border 看到 ASCII 上方的字符（基本上是 unsigned int，而不是 unsigned char code>），他们（至少在这种情况下）使用该数字不作为 Unicode 代码点，或作为 UTF-8 编码字节表示 - 相反，他们使用它作为查找索引acs_map-ping 函数（不过，最终会返回 Unicode 代码点，即使它模拟 VT-100）。这就是为什么以下规范：

window.addch('π') 
window.border('π')

在 Python 2.7 中会失败，参数 1 或 3 必须是 ch 或 int；在 Python 3.2 中会简单地渲染一个空格而不是一个字符。当我们指定'π'时。我们实际上已经指定了 UTF-8 编码 [0xCF,0x80] - 但即使我们指定了 Unicode 代码点：

window.addch(0x03C0) 
window.border0x03C0)

...它在 Python 2.7 和 3.2 中也不会渲染任何内容（空格）。

话虽这么说 - 函数 addstr 确实接受 UTF-8 编码的字符串，并且工作正常：

window.addstr('π')

...但是对于边框 - 因为 border() 显然以与 addch() 相同的方式处理字符 - 我们显然运气不好，对于任何未明确指定为 ACS 常量的内容（并且没有那么多）其中之一）。

希望这对某人有帮助，
干杯!

I believe the below is appropriately related, to be posted under this question. Here I'll be using utfinfo.pl (see also on Super User).

First of all, for standard ASCII character set, the Unicode code point and the byte encoding is the same:

$ echo 'a' | perl utfinfo.pl 
Char: 'a' u: 97 [0x0061] b: 97 [0x61] n: LATIN SMALL LETTER A [Basic Latin]

So we can do in Python's curses:

window.addch('a')
window.border('a')

... and it works as intended

However, if a character is above basic ASCII, then there are differences, which addch docs don't necessarily make explicit. First, I can do:

window.addch(curses.ACS_PI)
window.border(curses.ACS_PI)

... in which case, in my gnome-terminal, the Unicode character 'π' is rendered. However, if you inspect ACS_PI, you'll see it's an integer number, with a value of 4194427 (0x40007b); so the following will also render the same character (or rater, glyph?) 'π':

window.addch(0x40007b)
window.border(0x40007b)

To see what's going on, I grepped through the ncurses source, and found the following:

#define ACS_PI      NCURSES_ACS('{') /* Pi */  
#define NCURSES_ACS(c)  (acs_map[NCURSES_CAST(unsigned char,c)])
#define NCURSES_CAST(type,value) static_cast<type>(value)
#lib_acs.c: NCURSES_EXPORT_VAR(chtype *) _nc_acs_map(void): MyBuffer = typeCalloc(chtype, ACS_LEN);
#define typeCalloc(type,elts) (type *)calloc((elts),sizeof(type))
#./widechar/lib_wacs.c: { '{',  { '*',  0x03c0 }},  /* greek pi */

Note here:

$ echo '{π' | perl utfinfo.pl 
Got 2 uchars
Char: '{' u: 123 [0x007B] b: 123 [0x7B] n: LEFT CURLY BRACKET [Basic Latin]
Char: 'π' u: 960 [0x03C0] b: 207,128 [0xCF,0x80] n: GREEK SMALL LETTER PI [Greek and Coptic]

... neither of which relates to the value of 4194427 (0x40007b) for ACS_PI.

Thus, when addch and/or border see a character above ASCII (basically an unsigned int, as opposed to unsigned char), they (at least in this instance) use that number not as Unicode code point, or as UTF-8 encoded bytes representation - but instead, they use it as a look-up index for acs_map-ping function (which ultimately, however, would return the Unicode code point, even if it emulates VT-100). That is why the following specification:

window.addch('π') 
window.border('π')

will fail in Python 2.7 with argument 1 or 3 must be a ch or an int; and in Python 3.2 would render simply a space instead of a character. When we specify 'π'. we've actually specified the UTF-8 encoding [0xCF,0x80] - but even if we specify the Unicode code point:

window.addch(0x03C0) 
window.border0x03C0)

... it simply renders nothing (space) in both Python 2.7 and 3.2.

That being said - the function addstr does accept UTF-8 encoded strings, and works fine:

window.addstr('π')

... but for borders - since border() apparently handles characters in the same way addch() does - we're apparently out of luck, for anything not explicitly specified as an ACS constant (and there's not that many of them, either).

Hope this helps someone,
Cheers!

回复收藏 0 原文

~没有更多了~