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

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

它们支持Unicode，我们都同意Unicode是什么。在我们不同意的地方，我们的lexers反对

最近的MS IDE似乎都以UTF-8格式读/写源代码文件。。。我不确定这是否总是真的。是否有一些参考文件明确说明MS将如何编写源代码文件？有或没有字节顺序标记？它是否因IDE版本而异？（我无法想象旧的VB6开发环境除了写一个8位字符集之外还写了什么，我猜它应该是在由语言环境建立的CP xxxx编码中，对吗？）

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

关于“MS将如何编写源代码文件”：VS可以保存带BOM和不带BOM的文件，以及整组其他编码。默认为带BOM的UTF-8。你可以自己尝试，通过文件->保存。。。as->单击“保存”按钮上的三角形并选择“编码保存”

---

在实际代码中使用FEFF-从未见过有人在代码中使用它。。。维基百科建议，如果它发生在第一个位置（）以外的任何地方，则应将其视为零宽度空间。

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

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

U+FEFF应仅显示为BOM表 但是，从Unicode版本3.2开始，U+FEFF作为ZWNBSP的用法已被弃用，目前U+FEFF的用途是充当BOM。Unicode联盟强烈推荐使用U+2060（字连接符）字符，而不是ZWNBSP作为分隔符。它们在文件中间出现的任何U+FEFF都可以当作不支持的字符来对待，它们应该被显示为不可见的。我想到的另一个可能的解决方案是用U+ 2060替换文件中间出现的任何U+FEFF，或者忽略它。 意外添加U+FEFF

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

U+FEFF和UTF-8

---

当文本编码为UTF-8时，作为BOM的U+FEFF没有实际效果，因为它总是具有相同的字节顺序。UTF-8中的BOM会干扰依赖于某些前导字符和协议存在的系统，这些前导字符和协议明确规定了编码或编码标识方法。现实世界的经验还表明，一些应用程序在使用BOM的UTF-8上受阻。因此，在使用UTF-8时，通常不鼓励使用BOM。从UTF-8编码文件中删除BOM不应导致文件的错误解释（除非有与文件字节流相关的校验和或数字签名）。C++中的< /P> < P>，该文件是带有BOM的Unicode，或者将被解释为ANSI（即系统代码页，不一定是1252）。是的，您可以使用您想要的任何编码进行保存，但是如果您试图在系统代码页为1252的操作系统上编译Shift-JIS文件（日语，代码页932），编译器将阻塞

事实上，即使是编辑也会弄错。您可以将其保存为1252系统上的Shift JIS，看起来还可以。但是关闭项目并打开它，文本看起来就像垃圾。所以信息不会被保存在任何地方

所以这是你最好的猜测：如果没有BOM，假设ANSI。这就是编辑器/编译器所做的

另外：VS 2008和VS 2010，不支持Unicode的旧编辑器。

---

C++的规则不同于C++（C++中的文件默认为ANSI，对于C是UTF-8）

，如果你的东西符合语言规范，你的问题还不清楚。例如，我相信C#是默认的UTF-16，UTF-8和UTF-16除了字符的存储方式外没有什么不同。VS2010的直接实验表明，保存一个新文件会得到一个UTF8文件，当读取一个没有BOM表的文件时，IDE会假定字符编码为UTF-8。是的，我们的材料是符合我们对语言有良好定义的语言。我在问这是什么，如果是，或者不是，人们到底知道什么。。。。关于UTF-8。。。我们的工具根据文件的“显式”或声明的编码读取文件，并在读取时在内部将字符转换为UTF-16。因此，我们的C#解析器只能看到UTF-16字符。当没有明确的字节顺序标记时，我们很难知道各种IDE生成的文件的编码是什么。我们在文件中间发现的代码点FFF也有问题。