由于 HttpResponse.TransmitFile() 而在 ASP.NET 响应中间的ï»¿ 字符 (UTF-8 BOM)答案

【问题标题】：ï»¿ character (UTF-8 BOM) in middle of ASP.NET response due to HttpResponse.TransmitFile()由于 HttpResponse.TransmitFile() 而在 ASP.NET 响应中间的ï»¿ 字符 (UTF-8 BOM)
【发布时间】：2011-03-20 14:48:58
【问题描述】：

我看过这个帖子：ï»¿ characters appended to the begining of each file。

在那种情况下，作者是手动读取源文件并写入内容。就我而言，我通过 HttpRequest.TransmitFile() 将其抽象出来：

public void ProcessRequest(HttpContext context)
{
    HttpRequest req = context.Request;
    HttpResponse resp = context.Response;

    resp.ContentType = "application/javascript";

    resp.TransmitFile("foo.js");
    resp.TransmitFile("bar.js");
    resp.TransmitFile("baz.js");
}

.js 文件确实以 UTF-8 编码。这意味着 ï»¿ BOM 错误地出现在除第一个文件之外的每个文件的开头。

TransmitFile() 的优点在于 (a) 它抽象出整个读写过程，并且 (b) 它经过优化，不会先将文件读入内存——这在文件很大时非常重要和/或您有许多并发请求。但另一方面是我无法在没有 BOM 的情况下将其重新编码为 UTF-8。（我想这是一个泄漏抽象的例子。）

有什么优雅的方法可以解决这个问题吗？谢谢！

【问题讨论】：

这在实践中真的是个问题吗？ BOM 是一个空白字符（零宽度不间断空格，代码点 U+FFFE）。 JS 解释器是不是被它噎住了？
最重要的是，IE7 及以下版本卡住了（无效字符）。不太重要但仍然很烦人，JSLint 窒息它。
我不认为 TransmitFile 实际上对传输做了任何神奇的优化，没有什么是你不能用流读/写泵重新创建的
@meandmycode 很抱歉回复晚了，但是你是对的 if 你读/写了原始字节。如果您将文本内容读/写为字符串，则不会出现此问题。

标签： asp.net encoding utf-8 byte-order-mark

【解决方案1】：

就此结束循环：TransmitFile() 传输文件的原始字节，因此如果文件以带有 BOM 的 UTF-8 编码并且您传输多个文件，您将传输多个 BOM。

如果您自己将文件作为字符串读入内存并传输这些字符串，则不会出现此问题。我们最终只是将文件编码为 UTF-8，没有 BOM 或 ANSI。

【讨论】：