在没有 BOM 的 c# utf-8 中编码文本答案

【问题标题】：Encode text in c# utf-8 without BOM在没有 BOM 的 c# utf-8 中编码文本
【发布时间】：2014-11-03 07:46:21
【问题描述】：

我试过但没有用，我想在没有 BOM 的情况下进行编码，但使用选项 false 仍然使用 BOM 编码为 utf-8。

这是我的代码

System.Text.Encoding outputEnc = new System.Text.UTF8Encoding(false);
                return File(outputEnc.GetBytes(" <?xml version=\"1.0\" encoding=\"utf-8\"?>" + xmlString), "application/xml", id);

【问题讨论】：

@DStanley：这个问题似乎不是重复的。另一个问题中接受的答案指出 false 必须传递给 UTF8Encoding 构造函数，这正是这个问题中所做的。因此，另一个问题没有帮助。被提名重新开放。
@O.R.Mapper 同意 - 我在代码示例中没有发现。
如何检查是否使用 BOM 编码？
@DStanley：要明确一点：false 应该起作用，我怀疑这里还有其他东西在起作用；也许 OP 正在以某种方式运行他们的应用程序的旧版本。但只要没有得到证实，这个问题就不同了。
我用记事本++检查

标签： c# encoding utf-8 byte-order-mark

【解决方案1】：

这个问题已有两年多了，但我找到了答案。您在输出中看到 BOM 的原因是因为您的输入中有一个 BOM。 XML 声明开头的空格实际上是一个 BOM，后跟一个空格。为了证明这一点，请从您的 XML 编码中选择文本 " <（开头的双引号、后面的空格和开头的 < 字符）并将其粘贴到任何告诉您 Unicode 代码点的工具中。例如，将该文本粘贴到 http://www.babelstone.co.uk/Unicode/whatisit.html 会得到以下结果：

U+0022 : QUOTATION MARK
U+FEFF : ZERO WIDTH NO-BREAK SPACE [ZWNBSP] (alias BYTE ORDER MARK [BOM])
U+0020 : SPACE [SP]
U+003C : LESS-THAN SIGN

您还可以从我在此答案中输入的" < 复制和粘贴：我从您的问题中复制了这些字符，因此它们在空格字符之前包含不可见的 BOM。

这就是我经常将 BOM 称为 BOM(b) 的原因——因为它静静地坐在那里，隐藏起来，等着在你最意想不到的时候向你袭来。您正确使用了System.Text.UTF8Encoding(false)。它没有添加 BOM，但是您从中复制和粘贴 XML 的源包含一个 BOM，因此无论如何您的输出中都有一个 BOM，因为您的输入中有一个。

个人咆哮：将 BOM 排除在 UTF-8 编码文本之外是一个非常好的主意。但是，如果文本不包含 BOM，一些损坏的工具（Microsoft，我正在看着你，因为你是其中的大多数的工具）会误解文本，因此将 BOM 添加到有时需要 UTF-8 编码的文本。但确实应该尽可能避免。 UTF-8 现在是 Internetde facto 的默认编码，因此任何编码未知的文本文件都应该被解析为 UTF-8first，回退到“legacy” " 仅当将文档解析为 UTF-8 失败时才使用 Windows-1252、Latin-1 等编码。

【讨论】：

我很抱歉，但这种咆哮在实践中是一个糟糕的建议，尤其是在（但不限于）Windows 上。它优化以避免这种罕见的情况，以更常见的情况为代价，例如twitter.com/curlyquotefails 。解析整个文本通常是不切实际的，而且我还没有发现很多文件系统能够可靠且肯定地将编码存储在文件数据之外。
当我看到特征 â€™（或其他序列）显示 UTF-8 字符被错误解析为 Latin-1 时，我不认为“哦，他们应该使用 BOM避免误读”。我想“哦，有一个程序员没有通过 Unicode 101”。通过 Google 快速搜索，我找到了 this list of encoding frequency on the Web，发现 90% 的网站都使用 UTF-8。我不知道他们的调查方法，但在 Web 上，解析为 UTF-8 应该始终是默认值。
另外，在个人经验层面，我倾向于发现 BOM 错误更难追踪，因为它们是不可见的。错误编码的 UTF-8 会立即脱颖而出，因此该错误往往会被迅速发现并修复。因此，尽管我认为我同意您的观点，即 BOM 错误比错误编码错误更罕见，但我仍然认为避免 BOM 是最好的默认行为，因为您将避免不可见的、难以追踪的错误。立即可见的错误，更容易发现和修复。（尽管理所当然，但有时这些错误在其他人的代码中是您无法修复的。）
基于数据的统计分析或快速假设的解析在大规模上不起作用。它也更慢且更昂贵。为什么要责怪程序员从 Word 粘贴的数据，或平台、框架、库和不同年龄和质量的工具，当你可以很容易地责怪他们没有正确处理 BOM（签名）时。为什么要针对用户影响较小的罕见情况进行优化？尤其是当任何涉及 Windows 的东西在没有 BOM 的情况下无法可靠地处理文本时（请参阅旧的“灌木隐藏事实”错误）。