经典 ASP 文本替换和 UTF-8 编码答案

【问题标题】：Classic ASP text substitution and UTF-8 encoding经典 ASP 文本替换和 UTF-8 编码
【发布时间】：2010-11-30 01:05:14
【问题描述】：

我们有一个使用经典 ASP 的网站。

我们发布过程的一部分会替换文件中的值，我们在其中发现了一个错误，它会将文件写为 UTF-8。

这会导致我们的应用程序开始吐出垃圾。撇号作为一些编码字符返回。

如果我们随后删除表明此文件为 UTF-8 的 BOM，则之前呈现为垃圾的文本现在可以正确显示。

在遇到 UTF-8 文件时，IIS 有什么不同的做法吗？

【问题讨论】：

【解决方案1】：

如果你使用 access db 你应该写

Session.CodePage=65001
Set tabtable= Conn.Execute("SELECT * FROM  table")

【讨论】：

【解决方案2】：

我昨天正在搜索相同的确切问题并遇到：

该页面的重要部分，以防它消失......

ASP 代码：

Response.ContentType = "text/html"
Response.AddHeader "Content-Type", "text/html;charset=UTF-8"
Response.CodePage = 65001
Response.CharSet = "UTF-8"

以及以下 HTML META 标签：

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />

我们正在使用元标记和 asp CharSet 属性，但页面仍未正确呈现。将其他三行添加到 asp 文件后，一切正常。

希望这会有所帮助！

【讨论】：

您不需要同时使用元标记和Response.CharSet = "UTF-8"，因为它们的用途相同，我个人更喜欢使用Response.CharSet = "UTF-8"，而不是在html 中明确将其设置为元标记.另外Response.AddHeader "Content-Type", "text/html;charset=UTF-8" 只是写Response.ContentType = "text/html" 和Response.CharSet = "UTF-8" 的显式形式，你的建议是没有意义的，坚持使用Response.ContentType 和Response.CharSet。
在元标记中隐式声明 charSet 和 contentType 符合 W3C 可接受实践标准。无论您决定如何在您的 asp 中声明标题，无论是否冗余，您仍然应该包含一个声明内容类型和字符集的元标记。如果您在validator.w3.org/i18n-checker 处通过 W3C 验证检查器运行页面，则如果没有用于类型声明的元标记，它将失败。在这种特殊情况下，声明过多总比声明少好。

【解决方案3】：

UTF-8 不使用 BOM；在某些 Microsoft 软件中，这是一个令人讨厌的错误功能，将它们放在那里。您需要找到发布过程的哪个步骤将 UTF-8 编码的 BOM 放入文件并修复它 — 即使您正在使用 UTF-8，您也应该停止这种情况，现在确实如此最好。

但我怀疑是 IIS 导致了显示问题。浏览器更有可能猜测最终显示页面的字符集，当它看到看起来像是 UTF-8 编码的字节时，它会猜测整个页面是 UTF-8。您应该能够通过使用 HTTP 标头声明明确的字符集来阻止它：

Content-Type: text/html;charset=iso-8859-1

和/或 HTML 中的元元素

<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1" />

现在（假设 ISO-8859-1 实际上是您的数据所在的字符集）它应该显示 OK。但是，如果您的文件在开始时确实有一个 UTF-8 编码的 BOM，那么您现在会在页面中看到它为“ï»¿”，这就是这些字节在 ISO-8859-1 中的样子。所以你仍然需要摆脱那个misBOM。

【讨论】：

对，这是有道理的。这实际上是一些专门为处理此类问题而编写的代码中的错误。谢谢。
我必须承认这个答案让我很困惑。 “UTF-8 不使用 BOM”你能详细说明一下吗？这在什么方面是“错误特征”？我从未遇到过使用包含此零宽度空格字符的 UTF-8 文件的问题，您遇到过什么问题？
任何基于字节的文本工具（例如 shell、配置文件加载器等）在文件开头出现“ï»¿”时都会立即崩溃； UTF-8 的明确目标是与对 Unicode 一无所知的工具兼容，但 UTF-8+BOM 打破了这一点。甚至一些支持 Unicode 的工具也会忽略它，因为 BOM 只希望存在并被 UTF-16 的 Unicode 解码过程自动删除。 UTF-8+BOM 会破坏应用程序，并且没有理由在 Unicode 规范中使用它；而且它甚至没有任何好处，因为 UTF-8 没有字节顺序问题。
还对“UTF-8 不使用 BOM”感到困惑，无需澄清，这只是一个错误的确认。