您知道 APC (U+009F) 控制序列的使用记录吗？
Do you know of documented uses of the APC (U+009F) control sequences?
我正在寻找使用 APC（应用程序命令）控制字符的应用程序的文档示例。我读过 ECMA-48，它的定义如下：
APPLICATION PROGRAM COMMAND APC - APPLICATION PROGRAM COMMAND
Notation: (C1)
Representation: 09/15 or ESC 05/15
APC is used as the opening delimiter of a control string for application program use. The command string following may consist of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant application program.
我发现许多现代终端仿真器程序都能识别此控件，足以通过 ST 抑制 APC 的显示，这似乎与 ECMA 意图相匹配...我正在寻找使用的任何示例“命名空间”可能允许不同的应用程序在命令序列中使用不同的内容。我会对终端仿真器使用 APC 序列执行 某事 的示例特别感兴趣。
示例
const APC = "\x9F"
const ST = "\x9C"
console.log(`Hello world${APC}hidden command${ST}!`)
如终端上显示的那样 (Windows 10)
PS > node index.js
Hello world!
不显示“隐藏命令”。这看起来不错，但如果我将输出通过管道传输到另一个应用程序，命令字符串就在那里。
一些 shell 似乎对 C1 版本的控制字符有点困惑，我需要做一些工作来记录这一点。
背景
我正在考虑使用 APC 序列来允许嵌入数据（例如 JSON 形式）混合到标准输出流中。
碰巧在 screen 手册中遇到这个小问题。
Screen maintains a hardstatus line for every window.
If a window gets selected, the display's hardstatus
will be updated to match the window's hardstatus line.
If the display has no hardstatus the line will be displayed
as a standard screen message.
The hardstatus line can be changed with the
ANSI Application Program Command (APC):
"ESC_<string>ESC\".
As a convenience for xterm users the sequence
"ESC]0..2;<string>^G" is also accepted.
应用程序命令 (APC) 的已知用户：
- 一些 Kermit 实现（特别是 C-Kermit）支持 运行 Kermit 命令作为 APC 字符串发送
- Kitty 使用 APC 序列作为其 graphics protocol
的一部分
- iRMX real-time 操作系统的终端支持控制 (TSC) 组件使用 APC 序列。您作为 OSC 向 TSC 发送请求，它作为 APC 发送回复。 （参见 this PDF，第 242 和 285 页，PDF 第 256 和 299 页）
- 找到这个的 GNU 屏幕 hardstatus is set via APC. (Thanks to Gerrit's answer。）
- 同样，tmux支持使用APC设置window标题（见tmux源码
input_exit_apc function
- Perforce（以前称为 Rogue Wave）HostAccess 终端仿真器支持使用 APC 序列构建 Windows GUI（参见 this PDF 第 12 页）。这样您就可以拥有一个遗留的终端模式应用程序（最常见的是用 BASIC 为 PICK 平台编写的商业软件），只需在代码中添加转义序列就可以给它一个 Windows GUI
- 在 1980 年代的美国军方“综合信息支持系统”(IISS) 计划中，APC 序列用于发送功能键（参见 ADA182580 PDF page 34, November 1985; ADA249197 PDF 第 12 页，1990 年 9 月）
- 一些 Beehive 终端支持使用 APC 发送功能键，尽管使用了来自 IISS 的不兼容编码。 （参见示例 ATL-008 Technical User's Manual，1984 年 2 月，PDF 第 45 页）他们还支持使用 APC（不寻常的，实际上是
ESC APC，即 ESC ESC _）来配置键绑定和终端的 built-in菜单系统（请参阅该 PDF 第 104 页）。
你会注意到以上几乎都是完全不相容的。我所知道的唯一“名称空间”标准是 DEC 的内部标准 DEC STD 070, which mandates the first character of the APC sequence identify its type/purpose – but DEC themselves never really used APC sequences, and there is no registry of those prefixes. However, Kitty's graphics protocol (approximately) follows that standard by prefixing all its APC messages with G. (I say "approximately", because DEC-STD-070 says only "private use" sequence characters should be used, and apparently G 不是其中之一。）
现实情况是，APC 很少被实现——大多数系统从不生成 APC 序列并且默默地忽略任何接收到的。任何应用程序都不应发送或解释 APC 序列，除非它知道连接的另一端正在以特定方式使用它们——例如通过配置选项启用它们，或者它（以某种方式）知道正在使用哪个终端仿真器并且知道终端仿真器为它们分配了特定的含义——因此，在实践中对“命名空间”的需求不大。如果您真的觉得需要“命名空间”，最好的选择可能是使用 DEC-STD-070 保留初始字符的方法。
很少使用 APC 的原因之一是它是一个潜在的安全漏洞 – 如果您的 APC 序列做了一些潜在有害的事情，攻击者可能会将 APC 序列放入一个文件中并诱使用户查看该文件使用 cat/等。显示不受信任文件的程序应过滤其输出以删除转义序列，例如 APC，但 cat 等程序通常不会。
我正在寻找使用 APC（应用程序命令）控制字符的应用程序的文档示例。我读过 ECMA-48，它的定义如下：
APPLICATION PROGRAM COMMAND APC - APPLICATION PROGRAM COMMAND
Notation: (C1)
Representation: 09/15 or ESC 05/15
APC is used as the opening delimiter of a control string for application program use. The command string following may consist of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant application program.
我发现许多现代终端仿真器程序都能识别此控件，足以通过 ST 抑制 APC 的显示，这似乎与 ECMA 意图相匹配...我正在寻找使用的任何示例“命名空间”可能允许不同的应用程序在命令序列中使用不同的内容。我会对终端仿真器使用 APC 序列执行 某事 的示例特别感兴趣。
示例
const APC = "\x9F"
const ST = "\x9C"
console.log(`Hello world${APC}hidden command${ST}!`)
如终端上显示的那样 (Windows 10)
PS > node index.js
Hello world!
不显示“隐藏命令”。这看起来不错，但如果我将输出通过管道传输到另一个应用程序，命令字符串就在那里。
一些 shell 似乎对 C1 版本的控制字符有点困惑，我需要做一些工作来记录这一点。
背景
我正在考虑使用 APC 序列来允许嵌入数据（例如 JSON 形式）混合到标准输出流中。
碰巧在 screen 手册中遇到这个小问题。
Screen maintains a hardstatus line for every window.
If a window gets selected, the display's hardstatus
will be updated to match the window's hardstatus line.
If the display has no hardstatus the line will be displayed
as a standard screen message.
The hardstatus line can be changed with the
ANSI Application Program Command (APC):
"ESC_<string>ESC\".
As a convenience for xterm users the sequence
"ESC]0..2;<string>^G" is also accepted.
应用程序命令 (APC) 的已知用户：
- 一些 Kermit 实现（特别是 C-Kermit）支持 运行 Kermit 命令作为 APC 字符串发送
- Kitty 使用 APC 序列作为其 graphics protocol 的一部分
- iRMX real-time 操作系统的终端支持控制 (TSC) 组件使用 APC 序列。您作为 OSC 向 TSC 发送请求，它作为 APC 发送回复。 （参见 this PDF，第 242 和 285 页，PDF 第 256 和 299 页）
- 找到这个的 GNU 屏幕 hardstatus is set via APC. (Thanks to Gerrit's answer。）
- 同样，tmux支持使用APC设置window标题（见tmux源码
input_exit_apcfunction - Perforce（以前称为 Rogue Wave）HostAccess 终端仿真器支持使用 APC 序列构建 Windows GUI（参见 this PDF 第 12 页）。这样您就可以拥有一个遗留的终端模式应用程序（最常见的是用 BASIC 为 PICK 平台编写的商业软件），只需在代码中添加转义序列就可以给它一个 Windows GUI
- 在 1980 年代的美国军方“综合信息支持系统”(IISS) 计划中，APC 序列用于发送功能键（参见 ADA182580 PDF page 34, November 1985; ADA249197 PDF 第 12 页，1990 年 9 月）
- 一些 Beehive 终端支持使用 APC 发送功能键，尽管使用了来自 IISS 的不兼容编码。 （参见示例 ATL-008 Technical User's Manual，1984 年 2 月，PDF 第 45 页）他们还支持使用 APC（不寻常的，实际上是
ESC APC，即ESC ESC _）来配置键绑定和终端的 built-in菜单系统（请参阅该 PDF 第 104 页）。
你会注意到以上几乎都是完全不相容的。我所知道的唯一“名称空间”标准是 DEC 的内部标准 DEC STD 070, which mandates the first character of the APC sequence identify its type/purpose – but DEC themselves never really used APC sequences, and there is no registry of those prefixes. However, Kitty's graphics protocol (approximately) follows that standard by prefixing all its APC messages with G. (I say "approximately", because DEC-STD-070 says only "private use" sequence characters should be used, and apparently G 不是其中之一。）
现实情况是，APC 很少被实现——大多数系统从不生成 APC 序列并且默默地忽略任何接收到的。任何应用程序都不应发送或解释 APC 序列，除非它知道连接的另一端正在以特定方式使用它们——例如通过配置选项启用它们，或者它（以某种方式）知道正在使用哪个终端仿真器并且知道终端仿真器为它们分配了特定的含义——因此，在实践中对“命名空间”的需求不大。如果您真的觉得需要“命名空间”，最好的选择可能是使用 DEC-STD-070 保留初始字符的方法。
很少使用 APC 的原因之一是它是一个潜在的安全漏洞 – 如果您的 APC 序列做了一些潜在有害的事情，攻击者可能会将 APC 序列放入一个文件中并诱使用户查看该文件使用 cat/等。显示不受信任文件的程序应过滤其输出以删除转义序列，例如 APC，但 cat 等程序通常不会。