我的c＃程序接收字符串数据（通过Windows消息队列），有时在字符串中包含char-133。
这是c＃中的有效值吗？
例如，如果我这样做：
string x = "a" + (char)133 + "b"; // 133 = 0x85
我可以看到字符串x的长度为3，但在Visual Studio调试器中我只能看到x =＆＃34; ab＆＃34;。
如果我执行以下操作，我会得到＆＃34;省略号＆＃34;字符（我认为133也应该来自提供它的程序）：
string y = "a" + (char)8230 + "b"; // 8230 = 0x2026
感谢您的任何指示。
答案 0 :(得分：5)
string中的 char没有“无效”值。存在“无效的Unicode代码点”，但string可以毫无问题地包含它们，因为string是一个“愚蠢的容器”（但请注意，某些string方法“更加智能”并且不喜欢非常无效的代码点......通常他们会跳过它们/用一些替换字符替换它们）
现在......“visualizers”（必须“显示”一个字符串的模块/函数/方法）经常有局限性，不能显示所有字符（甚至是完全有效的字符）......一个典型的例子是{ {3}}和Zalgo。这是你的问题，但这是另一个问题： - ）
举一个例子，在Windows中，至少有4个“官方”API将文本写入屏幕：GDI，GDI +，Uniscribe，DirectWrite。然后许多程序（主要是游戏）使用FreeType库作为替代...这些库中的每一个都与Unicode的某些部分兼容。
我将添加为您创建问题的字符（0x85）称为Zalgo。它是一个控制角色，所以不应该“显示”它有一个NEL or Next Line，这可以解释为什么它有时显示为省略号：
NEL的代码已被用作Windows-1252中的省略号（'...'）字符。
例如：
YAML [8]不再认为它们是特殊的，以便与JSON兼容。
ECMAScript [9]接受LS和PS作为换行符，但考虑U + 0085（NEL）空格，而不是换行符。
Microsoft Windows 2000在默认文本编辑器记事本中不会将任何NEL，LS或PS视为换行符
在Linux上，一个流行的编辑器gedit将LS和PS视为新行，但不适用于NEL。