我正在开发一个嵌入式系统，而且我正在通过串口让它发送一定数量的数据。我将其缩小，发现如果消息中存在0x9B，则会破坏消息。
然后我在http://www.asciitable.com/上查找0x9b（155），它就丢失了！这不是一个奇怪的巧合！
任何想法，这是一个特殊的角色还是什么？
-edit-好的抱歉，伙计们，这不是造成这个的0x9b，它是一个0x11字符。哪个... drumroll ...是一个XON / XOFF角色。我在计算机上错误地将流控制作为xon / xoff，并且设备上没有流量控制！无论如何，谢谢你的帮助。
答案 0 :(得分：6)
在ANSI转义序列中，0x9B是单字符Control Sequence Introducer（更熟悉的多字符版本是ESC-[。
答案 1 :(得分：3)
0x9B是CSI或“控制序列介绍人”，它是C1控制代码集的一部分，见这里：http://www.search.com/reference/C0_and_C1_control_codes
假设数据正在通过处理C1控制代码的层，那么在该字符之后缺少一些字节并不奇怪，因为它用于指示ansi转义序列的开始。字节正在消失，因为某些层正在将它们作为指令的一部分剥离。有关详细信息，请访问：http://en.wikipedia.org/wiki/Control_Sequence_Introducer
显然不能保证这是你的问题，但我会根据你描述的症状开始挖掘api文档。
答案 2 :(得分：2)
如果0x9B之前的字符是0x10（DLE - 数据链接转义字符），可能会解释您看到的丢失字符。有些设备使用DLE作为控制命令指示符，后续字符是命令。如果DLE字符未被转义，则通常的标志是流中丢失2个字符，或者设备出现奇怪的行为。 使用DLE转义DLE字符。因此，在您的情况下，如果您的数据流包括：
... 0x10 0x9b ...
你必须写
... 0x10 0x10 0x9b ...
答案 3 :(得分：1)
我猜这是一个0x1B，即ASCII转义字符，第8位的奇偶校验位（它来自串行通信和所有）。
从技术上讲， ASCII集中的字符都小于或等于0x7F ，0x80到0xFF之间的字符是 扩展 ASCII 的一部分>。 0x7F以上代码的含义通常会有所不同，允许使用大小恰好一个字节的代码处理多个字符集中的一个。不幸的是，这种能力引起了一种模糊性，需要知道正在使用的特定额外字符集（如果你愿意，可以使用“代码页”）。
例如，问题中引用的“ASCII”表似乎没有任何与0x9B相关联的字符，而许多其他扩展ASCII集用于“普通”/可显示字符（例如：>看起来字符在ISO-8859-1中，分号（类似c的字符）与另一组等。
因此，0x9B字符的可能含义可能取决于与底层应用程序一起使用的[隐含]字符集。但正如前面提到的，它看起来更像是用7位（因此可能是“纯”ASCII字符）编码的字符，带有一个奇偶校验位。
答案 4 :(得分：0)
对于因标题而出现此问题的任何人：ASCII表中缺少0x9B / 155，因为它不是ASCII字符。 ASCII字符只有7位宽，这意味着它们只有128位，只有 没有字符155。
[社区维基因为它实际上没有回答问题，只有标题。]