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