经典 ASP 的 Request.Form 会丢失 8 位字符 - 有没有简单的方法来防止这种情况发生？

Question

我的一个客户正在使用经典 ASP 脚本来处理来自第三方支付处理器的表单（这是信用卡交易序列的最后一步，从客户的网站开始，转到第三方网站，然后返回到客户站点）。

客户位于奥地利，当其中一个字段包含 8 位字符时（例如，当字段值为 Österreich 时），当我以标准方式检索该字段的值时，会简单地删除 Ö；例如：

fieldval = Request.Form("country")
If fieldval = "sterreich" Then
    ' Code here will execute
End If

第三方页面正在 POST 的文字值为 %D6sterreich，我认为表明 POST 正在以 UTF-8 编码。

POST 请求具有以下可能相关的标头：

• Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
• Content-Type: application/ x-www-form-urlencoded

我绝不是字符编码专家，这是我第一次真正使用经典 ASP 做任何事情，所以我有点困惑。

通过一些谷歌搜索和搜索，我已将以下内容添加到处理 POST 的页面中：

<%@ Codepage=65001 %>
<%
Response.CharSet = "UTF-8"
Response.Codepage = 65001
%>

但这没有任何区别 - 我仍然丢失了最初的 8 位字符。有什么非常简单的事情我只是不知道吗？

Answer 1

尝试将以下内容添加到页面顶部：

<%
Response.CharSet = "utf-8"
Session.CodePage = 65001
%>

Answer 2

事实证明我的方向是错误的。有问题的 ASP 文件本身是用 UTF-8 编码的，这隐式地将 Response.CodePage 设置为 65001 —— 换句话说，显式添加 CODEPAGE 指令没有什么区别 —— 事实上 UTF-8 编码是问题的根源。

当我将文件重新编码为 Windows-1252 时，问题消失了。一般来说，我对字符编码非常无知，但我认为回想起来，POST 中的 %D6 应该是我的线索——如果我开始正确理解事情，那么单字节 < code>0xD6 不是有效的 UTF-8 字符。也许更熟悉这些事情的人可以证实或否认这一点。

Answer 3

如果在查询字符串中使用 Ascii 字符 0（编码为 (%00)），我可以检索整个值而不用 Ascii 0 终止吗？

http://localhost/Test_Authentication.asp?token=%13%23%02%00%01%01%00%01%01%05%02%02%03%00%02%02%0A%0A%0A%0A%0A%0A048


Response.CharSet = "utf-8";
Session.CodePage=65001;

var strToken = (Request.QueryString("token").Count > 0)?Request.QueryString("token")(1):"";

Answer 4

@Ben Dunlap：在页面顶部尝试这个 -

<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>

更新
如果您执行Response.Write Request.Form("country")，它会显示什么？

Answer 5

我使用的 2 个简单步骤是：

1. 在每个 asp 文件的顶部添加：

   Response.CharSet =“utf-8”

   Response.CodePage = 65001

2. 以“ANSI”编码（不是utf-8！） - 此选项通常位于高级文本编辑器的“保存”窗口

如果您以 utf-8 编码保存，或者如果您没有添加代码顶部指定的两行，则这将永远不会按您的预期工作。

Answer 6

我的问题是类似的（但很奇怪），并且在我的所有页面上添加以下两行已纠正它。非常感谢。

Response.CharSet = "UTF-8"
Response.Codepage = 65001

但是，为了解释一下，这就是我遇到的确切问题。人们在我的 ASP 输入页面上输入西班牙语字符，结果非常奇怪。例如，输入了“Peña”。ASP 页面将按照输入的内容显示此内容，但最终在数据库中显示的内容却显示为“Pe?a”。这应该没什么问题，除了实际存储在的十六进制值之外。数据库是 0x50653F6100。请注意，数据库存储的值末尾有一个额外的 NULL，因此，当我后来检索数据时，当“00”[null] 被击中时，屏幕变得有点疯狂。 。

无论如何，添加这两行似乎已经解决了问题，并且“ñ”按应有的方式存储在数据库中