为什么 Visual Studio 会向新文件添加字节顺序标记，这会导致问题吗？

Question

在我的项目中启用 eslint 后，它现在在我的打字稿和 JavaScript 文件中报告大量警告

Unexpected Unicode BOM (Byte Order Mark) unicode-bom

。为什么 VS 在我的文件中包含 BOM，这实际上是一个问题吗？

当我在 VS 二进制编辑器中打开这些文件时，我看到文件开头确实有一个 BOM，例如

00000000 EF BB BF 69 6D 70 6F 72 74 20 52 65 61 63 74 20 ...import React 在二进制编辑器中查看其他一些文件类型（例如 C# 代码）表明它们也以 BOM 开头。我正在使用 VS 2022，但是

是否有任何情况从 Visual Studio 2008 创建的 Js 文件中删除 BOM 会导致问题？表明 VS 已经这样做了很多年，并且该问题的答案表明它是也许最好将它们删除。

据我所知，字节顺序标记用于每个字符使用多个字节的文本编码中，以指示每个字符中的字节是首先呈现最高有效字节还是首先呈现最低有效字节（大端或小端）。然而，我的文件每个字符仅使用一个字节，因此 BOM 似乎超出了要求。所以我想我有两个问题

为什么 Visual Studio 将这个看似毫无意义的 BOM 添加到每个文件的开头？
为什么 eslint 认为这些 BOM 似乎并没有阻止任何工作，但需要警告我？

我知道我可以在 eslint 配置中禁用此规则，但我不喜欢在不理解为什么可以这样做的情况下禁用代码分析规则。

Answer 1

如果源代码文件包含 unicode 字符，例如，源代码文件中的 BOM 会很有帮助。如果其中有非英文文本或字符。否则是无关紧要的。由于大多数现代工具（文本编辑器、工具、编译器、版本控制等）都能正确处理 BOM 或至少忽略它，因此将其留在那里应该没问题。您可以使用

.editorconfig

 文件来指定哪些文件应该有 BOM，哪些文件没有，以防您想加以区分：

[*.{js}]
charset = utf-8
indent_style = tab
tab_width = 4

[*.{cs}]
charset = utf-8-bom
indent_style = space
tab_width = 4