我有一个C＃控制台应用程序，logging到控制台（使用Trace ）很多。 它logging的一些东西是networking消息的压缩表示（所以很多东西被渲染成时髦的非字母字符）。
每当应用程序运行时，系统都会发出蜂鸣声。 我正在写给控制台的一些“文本”是否可能导致它们？
（通过系统哔声，我的意思是来自PC机箱内的低技术扬声器，而不是任何种类的Windows声音schemeWAV）
如果是这样，有什么办法可以禁用我的应用程序？ 我希望能够输出任何可能的文本，而不会将其解释为声音请求。
如果您不想要发出哔声，则必须在输出之前替换0x7字符，或者禁用可在“非即插即用驱动程序”部分找到的“Beep”设备驱动程序您打开显示隐藏设备选项。 或者把扬声器拿出来。
这通常是由输出字符代码7，即BEL（钟形）字符CTRL-G引起的。
购买新电脑或主板时，我通常会做的第一件事是确保主板与扬声器之间的连线没有连接。 自从Keen指挥官的时代以来，我一直没有使用这个扬声器（并且除去这个线是停止声音的最佳操作系统不可知的方法:-)。
HKEY_CURRENT_USER\Control Panel\Sound
将“哔”键设置为“否”。
绝对的，如果你输出ASCII控制码“Bell”（0x7）给控制台，它会发出哔哔声。
即使您检查BELL字符的输入，它仍然可能会发出蜂鸣声。 这是由于字体设置和unicode转换。 有问题的角色是U + 2022 ，Bullet。
Raymond Chen 解释说 ：
在OEM代码页中，项目符号正在转换为嘟嘟声。 但为什么呢？
你看到的是MB_USEGLYPHCHARS相反。 Michael Kaplan不久前讨论了MB_USEGLYPHCHARS。 它确定某些字符在转换为Unicode时是否应该被当作控制字符或作为可打印字符处理。 例如，它控制是否将ASCII铃声字符0x07转换为Unicode铃声字符U + 0007或Unicode项目符号U + 2022。 您需要使用MB_USEGLYPHCHARS标志来决定转换为Unicode时要走哪条路，但是从Unicode转换时不会有相应的歧义。 从Unicode转换时，U + 0007和U + 2022都映射到ASCII铃声字符。
输出字符串中的\ b将导致蜂鸣声，如果在操作系统级别没有禁用。