我遇到了问题，我无法理解导致它的原因。我正在使用经典ASP（哦，为什么是我）编写的遗留网站，有时在显然随机的时间没有任何解释，ADODB.Recordset的值是双重编码打印的。
使用双重编码我指的是“ UTF-8编码的UTF-8多字节字符串的ASCII表示”所以“é“看起来像”é“（使用完全相同的编码）。
让我发疯的事情是，这似乎发生在随机时间，50％的时间是正确编码，另外50％则不是。
让我指出它在不同时间发生在同一页面上，因此在多次页面加载后，您可以正确显示它们，然后打破它们，然后再次正确显示等等。
这件事发生在7年前的这个网站的早期，但在桥下已经过了很多水，并且只有一个在这个网站上工作的人仍然在公司工作。他不记得他们做了什么来解决这个问题，他让我只说“数据库连接编码被保存到会话中”，这或许可以解释为什么页面周围有这么多Session.CodePage = 65001
我甚至尝试通过查询强制将字符集强制转移到utf8，但显然它不起作用。
使用的驱动程序是olde MySQL ODBC 3.51 Driver。
提前感谢任何建议或解决方案（遗憾的是，摆脱经典ASP不是一种选择）。
[UPDATE]
这是一个情节扭曲，如果输出这样的内容，它会缩短次数：
Session.CodePage = 1252
Response.Write(Property)
Session.CodePage = 65001
实际上我几乎在网站的任何地方都发现了这个代码，好像数据库驱动程序根本不关心连接的字符集。
答案 0 :(得分：1)
我进行了一些测试，感谢@ webaware的建议，我说服自己将 ODBC驱动程序更新为版本 5.1 ，经过一些调整后，网站似乎趋于稳定，那就是我使用的代码：
Response.AddHeader "Content-Type", "text/html; charset=UTF-8"
Session.CodePage = 65001
Dim ConnString:ConnString = "driver={MySQL ODBC 5.1 Driver};server=localhost;port=3306;database=database;uid=uid;pwd=pwd"
其他组合似乎打破了输出编码，现在它开箱即用。
我希望这对未来有所帮助。
答案 1 :(得分：0)
找到这种行为的原因真的很棘手。但是，让我指出一些可能对你有帮助的经典ASP的事实......
Session.Codepage影响会话的整个持续时间，这意味着所有后续请求都将使用指定的代码页。通过再次指定另一个代码页，这不会阻止使用其他编码的单个asp文件。因此，请查看您的应用程序，以便通过 Session.Codepage 或 Response.Codepage 指定编码。
这里的事情变得非常混乱。当表单数据发布到服务器时，url编码标准中没有规定声明所使用的代码页。可以告诉浏览器使用什么编码，它们将默认为html页面的charset包含表单，但是没有机制将该选择传达给服务器。
ASP认为发布的表单字段的代码页与其即将发送的响应的代码页相同。花一点时间来吸收它....这意味着，相当反直觉的Response.CodePage值会对Request.Form返回的字符串产生影响。因此，尽早获取正确的代码页，进行一些表单处理，然后在发送响应之前设置代码页，这一点很重要，这可能会导致意外结果。
当脚本引擎解析文件时，文件中的内容块（脚本代码块之外的内容）被转换为特殊形式的Response.Write（包括字符串文字）。它的特殊之处在于脚本执行时会到达这些特殊的写入，处理器只是将文件中找到的字节直接逐字复制到输出流，再次没有尝试转换任何编码。
阅读此问题的答案以获取更多信息。 Internal string encoding, Classic ASP