c# - Microsoft IDE、源文件编码、BOM 和 Unicode 字符\uFEFF？

Question

我们有各种 Microsoft 语言(VB6、VB.net、C#、C/C++ 的 MS 方言)的解析器。

在我们都同意什么是 Unicode 的情况下，它们支持 Unicode。在我们不同意的地方，我们的词法分析者反对。

最近的 MS IDE 似乎都以 UTF-8 格式读取/写入它们的源代码文件……我不确定这是否总是正确的。是否有一些引用文档可以清楚地说明 MS 将如何编写源代码文件？有或没有字节顺序标记？它是否因 IDE 版本而异？ (我无法想象旧的 VB6 开发环境会写除 8 位字符集之外的任何内容，我猜它会在语言环境建立的 CP-xxxx 编码中，对吧？)

对于 C#(我假设 MS 支持的其他现代语言方言)，字符代码\uFEFF 实际上可以在文件中间找到。此代码定义为零宽度不间断空格。当它出现在标识符中间的空白处时，它似乎被 VS 2010 忽略，但在关键字和数字中很重要。那么，规则是什么？或者 MS 是否有某种规范化标识符来处理诸如复合字符之类的事情，从而允许将不同的标识符字符串视为相同？

Answer 1

这在某种程度上是一个非答案，因为它不告诉微软说什么，而是告诉标准说什么。希望它无论如何都会有所帮助。

U+FEFF 作为常规字符

如您所述，U+FEFF 应视为文件开头的 BOM(字节顺序标记)。理论上它也可以出现在文本中间，因为它实际上是表示零宽度不间断空格 (ZWNBSP) 的字符。在某些语言/书写系统中，一行中的所有单词都是连接在一起的(=一起写)，在这种情况下，这个字符可以用作分隔符，就像英语中的常规空格一样，但它不会导致打印上可见的间隙。我实际上并不熟悉此类脚本，因此我的观点可能不完全正确。

U+FEFF 应该只作为 BOM 出现

但是，从 Unicode 版本 3.2 开始，将 U+FEFF 作为 ZWNBSP 使用已被弃用，目前 U+FEFF 的目的是充当 BOM。 Unicode 联盟强烈推荐使用 U+2060(单词连接符)字符代替 ZWNBSP 作为分隔符。他们的FAQ also suggests文件中间出现的任何 U+FEFF 都可以视为不受支持的字符，应该显示为不可见。我想到的另一种可能的解决方案是用 U+2060 替换文件中间出现的任何 U+FEFF 或忽略它。

不小心加了U+FEFF

我猜 U+FEFF 出现在文本中间最可能的原因是它是字符串连接的错误结果(或副作用)。 RFC 3629 包含了 BOM 的使用，表示在连接字符串时必须剥离前导 U+FEFF。这也意味着当在文本中间找到该字符时可以将其删除。

U+FEFF 和 UTF-8

当文本编码为 UTF-8 时，作为 BOM 的 U+FEFF 没有实际效果，因为它始终具有相同的字节顺序。 UTF-8 中的 BOM 会干扰依赖于某些前导字符和协议(protocol)的存在的系统，这些协议(protocol)明确规定了编码或编码识别方法。现实世界的经验还表明，一些应用程序在使用 BOM 的 UTF-8 上会阻塞。因此，在使用 UTF-8 时通常不鼓励使用 BOM。从 UTF-8 编码文件中删除 BOM 不应导致对文件的错误解释(除非存在与文件字节流相关的校验和或数字签名)。