ncurses & telnet协议

Question

我正在编写程序，通过telnet导出一个基于ncurses的文本用户界面。当我使用硬编码值时，这基本上是可行的：

 fd = accept(sfd, NULL, 0); // tcp socket to client

 FILE *fh = fdopen(fd, "rw");

 SCREEN *scr = newterm("vt100", fh, fh);
 setterm(scr);
 resizeterm(25, 80);

 // ...regular ncurses code...

在ncurses中，您可以使用getch()检索按键。这将自动地将特殊字符(如游标键向上/向下/etc (ESC [A等))转换为常量，如KEY_UP。

Telnet使用特殊的字节码将终端窗口大小、终端类型等参数传递给telnet客户端，反之亦然。

如果我想去掉这些硬编码值，我需要发送telnet代码，但我也需要接收它们的响应。

我现在的问题是:这些telnet代码会不会干扰ncurses？我是否能够使用getch()，或者getch将错误地解释特殊字符的ncurses代码？

Answer 1

首先是RFCs：RFC 854 . TELNET协议规范说字符255 (0xff，IAC)是为客户端和服务器之间的通信而预留的。

RFC (理论)和实践(实现)之间存在着脱节。RFC显然只支持简单的电传类型替换(即没有游标寻址，根本不支持转义序列)。从RFC的角度来看，一旦您开始考虑终端(1983年RFC发布时可用的大多数终端确实支持游标寻址)，除了小心不要发送(未转义的)字符255之外，没有什么可说的。

2008年，RFC 5198 -用于网络交换的Unicode格式更新了RFC 854 (而不是过时的)。和RFC 854一样，它假设每个人都使用玻璃电传打字机，建议不要使用后置字符，因为它在不同系统上的行为可能有所不同。RFC中的一个有用的注释指出，字符255不会是有效的UTF-8字符串的一部分。

如果您没有使用UTF-8，ISO-8859-x编码可能会发送255。它是一个有效的可打印字符。除非您的数据碰巧包含该字符，否则ncurses不会发送该字符，但是ncurses没有特殊的转义该字符的规定。

ncurses假设您的通信路径是8位干净的。RFC 856 - TELNET二进制传输部分解决了这一问题，保留了IAC的致命弱点：

在二进制传输选项有效的情况下，接收机应该将从发送器接收到的不与IAC前面的字符解释为8位二进制数据，但IAC除外，IAC后面是小数值255的8位二进制数据。IAC后面跟着一个有效的TELNET命令(加上完成命令所需的任何其他字符)仍然是命令，即使使用二进制传输选项也是如此。IAC后面的字符不是定义的TELNET命令，其含义与IAC和NOP，具有相同的含义，尽管通常不应该在此模式下发送带有未定义命令的IAC。

当然，您可能会遇到一些真正的8位干净的实现，但是它不符合RFC。