0x9B（十进制155）是特殊控制字符吗？为什么 ascii 表中缺少它？
我正在开发一个嵌入式系统，并且我正在让它通过串行端口发送特定的数据块。我缩小了范围，发现如果消息中存在 0x9B，就会破坏消息。
所以我然后在 http://www.asciitable.com/ 上查找 0x9b (155)，它是丢失的！这难道不是一个奇怪的巧合吗！
有什么想法吗，这是一个特殊的角色还是什么？
-编辑- 好吧，对不起，伙计们，这不是 0x9b 造成的，而是 0x11 字符造成的。其中...鼓声...是 XON/XOFF 字符。我错误地将计算机上的流量控制设置为xon/xoff，而设备上没有流量控制！不管怎样，谢谢你的帮助。
I'm working on an embedded system, and i'm having dramas getting it to send a certain chunk of data across the serial port. I narrowed it down and found that if a 0x9B is present in the message, it corrupts the message.
So i then look up 0x9b (155) on http://www.asciitable.com/, and it's missing! Isn't that a bizarre coincidence!
Any ideas, is this a special character or something?
-edit- Okay sorry guys, it wasn't the 0x9b causing this, it was an 0x11 character. Which...drumroll... is an XON/XOFF character. I mistakenly had flow control as xon/xoff on the computer, and no flow control on the device! Thanks for the help anyway.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在 ANSI 转义序列中，
0x9B是一个字符控制序列介绍符 （更熟悉的多字符版本是ESC-[。In ANSI escape sequences,
0x9Bis the one-character Control Sequence Introducer (the multi-character version which is more familiar isESC-[.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 is the CSI or "Control Sequence Introducer" its part of the C1 set of control codes, see here: http://www.search.com/reference/C0_and_C1_control_codes
Assuming the data is passing through a layer that processes C1 control codes it not surprising that there are a few bytes missing after this character as it is used to indicate the beginning of an ansi escape sequence. The bytes are disappearing because some layer is pealing them off as part of an instruction. More info on that here: http://en.wikipedia.org/wiki/Control_Sequence_Introducer
Obviously can't guarantee this is your problem but its where I would start digging in the api documentation based on the symptoms you described.
如果 0x9B 之前的字符是 0x10（DLE - 数据链接转义字符），则可以解释您看到的丢失字符。有些设备使用DLE作为控制命令指示符，后面的字符就是命令。如果 DLE 字符未转义，通常的迹象是流中丢失 2 个字符，或者设备出现奇怪的行为。
使用 DLE 转义 DLE 字符。因此，在您的情况下，如果您的数据流包括：
... 0x10 0x9b ...
您将不得不写
... 0x10 0x10 0x9b ...
If the character before 0x9B is 0x10 (DLE - data link escape character) that might explain the lost characters you see. Some devices use DLE as a control command indicator and the subsequent character is the command. If DLE characters aren't escaped, the usual sign is a loss of 2 characters in the stream, or strange behavior from the device.
Escape DLE characters with DLE. So, in your case if your data stream includes:
... 0x10 0x9b ...
you would have to write
... 0x10 0x10 0x9b ...
我猜这是一个 0x1B，即 ASCII 转义字符，在第 8 位位置有一个奇偶校验位（它来自串行通信等）。
从技术上讲，ASCII 集中的字符都小于或等于 0x7F，0x80 到 0xFF 之间的字符是扩展 ASCII的一部分。 0x7F 以上代码的含义通常有所不同，允许使用大小恰好为一个字节的代码来处理多个字符集之一。不幸的是，这一功能引入了歧义，因为人们需要知道正在使用的特定额外字符集（“代码页”，如果你愿意的话）。
例如，问题中引用的“ASCII”表似乎没有任何与 0x9B 关联的字符，而许多其他扩展 ASCII 集将其用作“普通”/可显示字符（例如：
> 在 ISO-8859-1 中查找字符、分号（类似 c 的字符）与另一组等。因此，0x9B 字符的可能含义可能取决于底层应用程序使用的[隐含]字符集。但正如之前所说，字符看起来更像是用 7 位（因此很可能是“纯”ASCII 字符）和一个奇偶校验位进行编码的。
I'm guessing this is a 0x1B, i.e. the ASCII escape character, with a parity bit in the 8th bit position (it coming from serial communication and all).
Technically, the characters in the ASCII set are all smaller or equal to 0x7F, characters between 0x80 to 0xFF are part of the extended ASCII. The meaning of the codes above 0x7F typically varies, allowing one of multiple characters sets to be handled with codes exactly one byte in size. This capability unfortunately introduces ambiguity for one needs to know the particular extra character set in use (the "code page" if you will).
For example the "ASCII" table referenced in the question doesn't appear to have any character associated with 0x9B, while many other extended ASCII set use this for a "plain" / displayable character (ex: a
>looking character in ISO-8859-1, the cent sign (a c-like character) with another set etc.The possible meaning of the 0x9B character could therefore depend on the [implied] character set in use with the underlying application. But as said, earlier, it looks more like the characters are encoded on 7 bits (hence are likely "pure" ASCII characters) with one parity bit.
对于仅仅因为标题而提出这个问题的人： ASCII 表中缺少
0x9B/155因为它不是 ASCII 字符。 ASCII 字符只有 7 位宽，这意味着只有 128 个字符，根本没有字符 155。[社区 Wiki，因为它实际上并没有回答问题，只回答了标题。]
For anyone coming to this question just because of the title:
0x9B/155is missing from ASCII tables because it isn't an ASCII character. ASCII characters are only 7 bits wide, meaning there are only 128 of them, there simply is no character 155.[Community Wiki because it doesn't actually answer the question, only the title.]