我们有针对各种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有某种规范化标识符来处理诸如复合字符之类的事情，从而允许将不同的标识符字符串视为相同？
最佳答案
这在某种程度上是无法回答的，因为它不能告诉微软说什么，但是告诉标准是什么。希望无论如何会有所帮助。
U + FEFF作为常规字符
如您所述，U + FEFF在文件开头应被视为BOM（字节顺序标记）。从理论上讲，它也可能出现在文本中间，因为它实际上是表示零宽度不间断空格（ZWNBSP）的字符。在某些语言/书写系统中，一行中的所有单词都连接在一起（=一起书写），在这种情况下，该字符可以用作分隔符，就像英语中的常规空格一样，但不会造成印刷上可见的间隙。我实际上并不熟悉此类脚本，因此我的观点可能并不完全正确。
U + FEFF应该仅显示为BOM
但是，自Unicode版本3.2起，已不建议使用U + FEFF作为ZWNBSP，并且当前U + FEFF的目的是充当BOM。 Unicode联盟强烈建议使用U + 2060（单词连接符）字符代替ZWNBSP作为分隔符。他们在文件中间出现的任何U + FEFF的FAQ also suggests可被视为不受支持的字符，应显示为不可见。我想到的另一种可能的解决方案是用U + 2060替换文件中间出现的所有U + FEFF或忽略它。
意外添加了U + FEFF
我猜想U + FEFF出现在文本中间的最可能原因是，这是字符串连接的错误结果（或副作用）。合并了BOM用法的RFC 3629表示，在串联字符串时，有必要剥离前导U + FEFF。这也意味着在文本中间找到字符后就可以将其删除。
U + FEFF和UTF-8
当文本编码为UTF-8时，U + FEFF作为BOM并没有实际效果，因为它始终具有相同的字节顺序。 UTF-8中的BOM会干扰依赖于某些明确要求编码或编码识别方法的某些前导字符和协议的系统。现实世界的经验还表明，某些应用程序在使用BOM的UTF-8上遇到问题。因此，在使用UTF-8时通常不建议使用BOM。从UTF-8编码的文件中删除BOM应该不会导致对该文件的错误解释（除非存在与文件的字节流相关的某些校验和或数字签名）。