为什么每个 IIS 响应的末尾（作为最后一个字节）可能会有一个 UTF-8 BOM？答案

【问题标题】：Why might there be a UTF-8 BOM at the end (as the last bytes) of each IIS response?为什么每个 IIS 响应的末尾（作为最后一个字节）可能会有一个 UTF-8 BOM？
【发布时间】：2021-11-04 18:53:54
【问题描述】：

在通过 IIS 管道运行的每个页面的末尾，该管道发出带有字符集的 Content-Type（根据 <globalization> 元素），UTF-8 BOM添加在末尾em>响应。这是无效的，并且会破坏 UpdatePanel 的使用。

如果添加了BOM，应该是第一个字符..

curl | xxd 将最后三个字节显示为EF BB BF，或 UTF-8 BOM。

0002b830: 2f62 6f64 793e 0d0a 3c2f 6874 6d6c 3eef  /body>..</html>.
0002b840: bbbf                                     ..

注意事项：

此问题不会影响来自静态文件处理程序的响应。这表明问题出在托管/ASP.NET 管道中。
如果在写入一些虚拟数据后立即调用Request.End()，仍然会出现此问题。这应该意味着该问题不是由任何进一步的请求处理程序或软包装器引起的，因为它会导致 ThreadAbortException 传播。
MVC 和 ASP.NET WebForm 页面受到同样的影响。
ASHX 请求不受影响。
在改用 <globalization responseEncoding="utf-8" ..> 时，问题开始出现，或者至少变得非常明显。
这样的 BOM / 字符确实没有出现在请求中使用的源文件的末尾，更不用说每个受影响的文件了..（代码库没有非启动/BOM出现\xEF\xBB\xBF，也没有出现\xFE\xFF 或\xFF\xFE。）

所有不附带 IIS 或 ASP.NET MVC 的 IIS 模块已被删除，问题仍然存在。

可能是什么问题，故障排除的后续步骤是什么？

【问题讨论】：

应用在本地有这个问题吗？还是只发生在 iis 上？
有人应该提醒我检查一些严重损坏的过滤器，这些过滤器可能会或可能不会通过 Global ASAX 添加：-/
@samwu 它发生在本地（也在运行 IIS）。一些旧的 janky 代码正在通过一些代码设置一个（损坏的）流过滤器/代理，该代码作为一种迂回方法从 Global.asax 中注册的过滤器（以及基本 Page 控件..）中执行 sigh

标签： asp.net iis utf-8 globalization .net-framework-4.8

【解决方案1】：

这个问题完全与 ASP.NET 管道相关，因为一些很棒的“处理程序”被添加到 MVC 管道（通过在 Global.asax 中注册的过滤器）和 WebForms（通过基本页面添加..） ;这两种形式最终都将HttpContext.Response.Filter 重新分配给了一个特殊的代表……或者在这种情况下，是多个包装的代表。

这些“处理程序”有效地导致写入一个流的内容，然后是来自另一个“处理程序”的空除 BOM 响应，效果类似于：

 _stream.Write(someOutputBuffer, ..);
 _stream.Write(originalBuffer, ..);

因此，如果 originalBuffer 碰巧是空的，除了 BOM，输出将在“末尾”附加 BOM，而不是响应中间某处同样无效的位置..

切换到 UTF-8 响应编码会导致该行为，因为这些“处理程序”中的每一个都使用当前响应编码打开了一个流，该响应编码已切换到 UTF-8，并且默认的 UTF-8 编码将发出一个 BOM默认情况下。

修复是针对create the UTF-8 encoding used in a way that specifies not to emit the BOM by default，而不是直接使用Response.ContentEncoding（带有BOM 的UTF-8）。（代码完全值得怀疑，尽管这是另一天的任务..）

tldr; janky“处理程序”并不总是作为 IIS 模块/处理程序安装。

【讨论】：