0x9B（155decimal）是一个特殊的控制字符吗？为什么ascii表中缺少它？

我正在开发一个嵌入式系统，我正在制作剧本，让它通过串口发送特定的数据块。我缩小了范围，发现如果消息中存在0x9B，则会破坏消息

然后我在上面查找0x9b（155），它不见了！这不是一个奇怪的巧合吗

有什么想法吗，这是一个特殊的角色还是什么

---

-编辑-好吧，对不起，这不是0x9b造成的，是0x11字符造成的。哪个…drumroll。。。是一个XON/XOFF字符。我在计算机上错误地将流量控制设置为xon/xoff，而在设备上没有流量控制！无论如何，感谢您的帮助。

我猜这是一个0x1B，即ASCII转义字符，第8位位置有一个奇偶校验位（它来自串行通信和所有）

从技术上讲，ASCII集中的字符都小于或等于0x7F，0x80到0xFF之间的字符是扩展ASCII的一部分。0x7F以上代码的含义通常不同，允许多个字符集中的一个字符集使用大小正好为一个字节的代码进行处理。不幸的是，这一功能引入了歧义，因为人们需要知道正在使用的特定额外字符集（“代码页”），如果您愿意的话。
例如，问题中引用的“ASCII”表格似乎没有任何与0x9B相关的字符，而许多其他扩展ASCII集合将其用于“普通”/可显示字符（例如：ISO-8859-1中的一个

外观字符、带有另一个集合的分号（类似c的字符）等）

---

因此，0x9B字符的可能含义可能取决于底层应用程序中使用的[隐含]字符集。但如前所述，它看起来更像是在7位上编码的字符（因此可能是“纯”ASCII字符）带有一个奇偶校验位。

在ANSI转义序列中，

0x9B

是一个字符（更常见的多字符版本是

ESC-[
0x9B是CSI或“控制序列导入器”，它是C1控制代码集的一部分，请参见此处：

假设数据通过处理C1控制代码的层，则此字符后缺少几个字节就不足为奇了，因为它用于指示ansi转义序列的开始。这些字节正在消失，因为某个层正在将它们作为指令的一部分进行峰值化。有关此方面的详细信息，请参见：

显然，我不能保证这是您的问题，但我会根据您描述的症状在api文档中挖掘它。
如果0x9B之前的字符是0x10（DLE-数据链接转义字符）这可能解释了您看到的丢失字符的原因。某些设备使用DLE作为控制命令指示器，随后的字符就是命令。如果没有转义DLE字符，通常的迹象是流中丢失2个字符，或者设备出现奇怪的行为。
使用DLE转义DLE字符。因此，在您的情况下，如果您的数据流包括：

…0x10 0x9b

你得写信

…0x10 0x10 0x9b…
对于仅仅因为标题而回答此问题的人：
0x9b
/
155
在ASCII表中丢失，因为它不是ASCII字符。ASCII字符只有7位宽，这意味着其中只有128位，根本没有字符155

[社区维基，因为它实际上并没有回答问题，只有标题。]
ASCII只升到127（0x7f十六进制）。好的，如果你愿意的话，扩展ascii。损坏是什么样子的？连接断开了吗？或者你得到的字节序列与输入不匹配吗？在这种情况下，它看起来像什么？它好像在该字节后跳过了几个字符。ascii是7位和8位。我相信8位版本被称为扩展ascii。如果你是使用Microsoft开发产品，如果内存可用，您只需要正确的编码器Windows-1252。嗯，我不太确定：我的通信设置是8N1-8位，无奇偶校验，1个停止bit@Chris，它可以是逻辑奇偶校验位，即在文件/内容级别管理的奇偶校验位，而不是与串行通信设备一起添加的奇偶校验位如果串行com还包括奇偶校验位，“皮带+吊杆”设置。）您可以通过断言，例如，您从未有过0x41或0x42（而是分别有0xC1和0xC2），相反，您总是有0x43（并且从未有过0xC3）来验证这一点。（猜测…）@克里斯：另外，请记住，并不是因为串行通信的一端设置为8位无奇偶校验，另一端不能为7位加奇偶校验…（再想想，可能是奇偶校验，因为通常串行通信使用偶数奇偶校验位，而不是奇偶校验位…）但是我怀疑你是对的：在退出com端口之前，这条消息必须经过一些供应商API，我敢打赌他们正在删除第8位，并不知何故混淆了这个字符……用有缺陷的晦涩API进行该死的嵌入式编程！好吧，对不起，这是我的一个愚蠢错误。我在设备上关闭了流控制，xon/xof计算机上的f，所以计算机正在吃0x11。0x9b是一条红鲱鱼。好吧，154和156在我正在查看的ascii表中，只缺少155个！无论如何，我发现了问题，这是一个xon/xoff配置错误。