角色要去哪里？

Question

在有效的shell \\u（bash +4.3、ksh93 或 zsh）中，我们可以打印 Unicode 字符：

\n

$ printf \'a b c \\ua0 \\ua1 \\ua2 \\ua3 \\n\'\na b c   \xc2\xa1 \xc2\xa2 \xc2\xa3\n

\n

这是Latin-1_Suplement范围中的一些字符。

\n

然而，一旦9f添加了 Unicode 字符，打印就会停止，直到打印出 Unicode 9c。

\n

和\\u9f（\\u9cAPC 和 ST）都是C1控制字符。

\n

$ printf \'a b c \\u9f d e f \\u9c \\ua0 \\ua1 \\ua2 \\ua3 \\n\'\na b c  \xc2\xa0 \xc2\xa1 \xc2\xa2 \xc2\xa3 \n

\n

角色肯定会消失。

\n

可以肯定的是，它printf正在生成所有字符，并且将输出重定向到其他软件（而不是终端）将显示生成的字符：

\n

$ printf \'a b c \\u9f d e f \\u9c \\ua0 \\ua1 \\ua2 \\ua3 \\n\' | od -A n -tx1\n 61 20 62 20 63 20 c2 9f 20 64 20 65 20 66 20 c2\n 9c 20 c2 a0 20 c2 a1 20 c2 a2 20 c2 a3 20 0a\n

\n

这足以证明角色正在生成。那么，为什么它们没有被打印（用一些可见的字形显示）？

\n

我的问题是：

\n

\n
1. 实际上APC连接到ST. 它在哪里定义的？
\n
2. 这两个字符之间的字符是否发送到某个应用程序？
\n
3. 如果是这样，到哪个应用程序？
\n
4. 谁负责这种重定向？shell、终端还是其他东西？
\n

\n

编辑

\n

xterm或终端都不会konsole删除d e f字符。

\n

这证实这是终端应用程序的内部问题，而不是 shell。还没有找到在哪里定义的。

\n

Answer 1

\n

APC实际上是连接到ST的吗？它在哪里定义的？

\n

\n

这些控制字符实际上并不是 Unicode 的原始字符，而是从旧的字符集规范继承的，例如ECMA-48、ISO/IEC 6429 和 ISO/IEC-8859 字符编码系列。从广义上讲，这些标准在 C1 控制字符上基本上彼此一致（因为它们彼此向后兼容，甚至有些更旧的规范）。

\n

由于 ISO/IEC 6429 的副本正在出售，我不希望在互联网上找到免费的合法副本，但 ECMA-48 表示：

\n

\n

8.3.2 APC——应用程序命令

\n

符号：(C1)

\n

代表：09/15 或 ESC 05/15

\n

APC 用作应用程序使用的控制字符串的起始定界符。后面的命令串可以由 00/08 至 00/13 和 02/00 至 07/14 范围内的位组合组成。控制字符串由终止定界符 STRING TERMINATOR (ST) 关闭。命令串的解释取决于相关的应用程序。

\n

\n

和：

\n

\n

8.3.143 ST——字符串终止符

\n

符号：(C1)

\n

代表：09/12 或 ESC 05/12

\n

ST 用作由应用程序命令 (APC)、设备控制字符串 (DCS)、操作系统命令 (OSC)、隐私消息 (PM) 或字符串开始 (SOS) 打开的控制字符串的结束分隔符。

\n

\n

Unicode 在 C1 控制字符范围内仅定义一个控制字符：U+0085 下一行 (NEL)。对于 C1 范围内的任何其他字符，规范的这一部分适用：

\n

\n

控制代码的语义通常由它们所使用的应用程序确定。然而，在没有特定应用用途的情况下，可以根据 ISO/IEC 6429:1992 中规定的控制功能语义来解释它们。

\n

\n

我无法在这里验证它，但我希望 ISO/IEC 6429 非常符合 ECMA-48 的规定，如上所述。此外，终端的作者可能认为“向后兼容 Unicode 之前的 7 位和 8 位字符编码，如 ECMA-48”是特定的应用程序使用。

\n

因此，终端可能会将 APC 和 ST 之间的字符合法地解释为“我不知道这些字符的用途，但我确信这些字符不打算显示为常规输出”。

\n

终端可能会或可能不会以某种方式对封装在 APC 和 ST 之间的某些特定字符串做出反应，并忽略任何不匹配的字符串。由于终端窗口是“人类面前的最后一步”，因此当然可以假设任何应用程序命令字符串都意味着终端要解释并执行操作（如果适用），以及任何无法识别的此类字符串终端一定有错误。

\n

显示“无效编码”字符或其他错误消息是不合适的，因为该字符串被有效编码为“特定于应用程序的控制字符串，不适用于显示”。那么“角色要去哪里？”这个标题问题的答案就是这样的。最有可能的是：它们作为无效控制字符串的一部分被丢弃。

\n

但请注意，Unicode 规范说的是“...可以解释...”，而不是“...必须解释...”。因此，其他终端实现选择忽略 APC 和 ST 字符作为没有适用含义的不可打印控制字符也不一定是无效的。

\n

Stack Overflow 上的这个问题还讨论了涉及 APC 和 ST 控制字符的控制序列。

\n

那里接受的答案说：

\n

\n

现实情况是，APC 很少实现 \xe2\x80\x93 大多数系统从不生成 APC 序列并默默地忽略任何收到的序列。任何应用程序都不应发送或解释 APC 序列，除非它知道连接的另一端正在以特定方式使用它们 \xe2\x80\x93 例如通过配置选项来启用它们的使用，或者它（以某种方式）知道哪个终端正在使用模拟器并知道终端模拟器为它们分配了特定的含义[...]

\n

\n