IIS错误地解码包含系统区域设置以外字符的URL

如果URL包含当前系统语言环境不支持的UTF-8编码字符，则IIS似乎会将请求URL错误地传递到web应用程序。所有“不支持的”字符均替换为问号（“？”）

示例：系统区域设置为挪威语。 以下URL工作正常：

/myapp/Blåbærsyltetøy/

以下URL不起作用：

/myapp/черничный-джем/

在这两个URL中，非ASCII字符编码为UTF-8，然后百分比编码，因此实际URL如下所示：

/myapp/Bl%C3%A5b%C3%A6rsyltet%C3%B8y/
/myapp/%D1%87%D0%B5%D1%80%D0%BD%D0%B8%D1%87%D0%BD%D1%8B%D0%B9-%D0%B4%D0%B6%D0%B5%D0%BC/

应用程序使用两种方式处理请求：

• wfastcgi+Python
• ISAPI+C++

两者都有相同的问题，如果URL只包含系统语言环境支持的字符，则两者都没有问题

在ISAPI的例子中，它看起来像是

EXTENSION\u CONTROL\u BLOCK:：lpszPathInfo

已经提供了一个百分比解码URL，其中所有“不受支持”的字符都被问号替换。

EXTENSION\u CONTROL\u BLOCK:：lpszPathInfo

属性是一个多字节字符串，没有此结构的宽字符串版本

---

有没有办法获取原始的百分比编码URL或阻止IIS解码URL来解决此问题？

ISAPI的解决方案

从服务器变量

HTTP\u URL

而不是

PATH\u INFO

获取请求URL。这将提供原始的百分比编码URL，然后可以正确解码（通过对字节数组进行百分比解码并将该字节数组解释为UTF-8编码字符串）

此变量包含URL重写之前的查询字符串和原始路径，这可能是不需要的，因此可能需要一些额外的处理

此外，对于错误处理程序请求，此变量包含格式类似于的字符串

<DLL_PATH>?<STATUS_CODE>;<ORIGINAL_HTTP_URL>

请注意，这将影响同一服务器上的所有wfastcgi应用程序，并可能破坏不希望变量为UTF-8编码的现有应用程序（不太可能，因为任何使用非ASCII URL的sane应用程序都将使用UTF-8编码…）

---

另请参见ISAPI的解决方案

从服务器变量

HTTP\u URL

而不是

PATH\u INFO

获取请求URL。这将提供原始的百分比编码URL，然后可以正确解码（通过对字节数组进行百分比解码并将该字节数组解释为UTF-8编码字符串）

此变量包含URL重写之前的查询字符串和原始路径，这可能是不需要的，因此可能需要一些额外的处理

此外，对于错误处理程序请求，此变量包含格式类似于的字符串

<DLL_PATH>?<STATUS_CODE>;<ORIGINAL_HTTP_URL>

请注意，这将影响同一服务器上的所有wfastcgi应用程序，并可能破坏不希望变量为UTF-8编码的现有应用程序（不太可能，因为任何使用非ASCII URL的sane应用程序都将使用UTF-8编码…）

---

另请参见

有关ISAPI，解决方案是从服务器变量

HTTP\u URL

获取URL，而不是

PATH\u INFO

。这将提供原始的百分比编码URL，然后可以正确解码。在wfastcgi脚本中，

HTTP\u URL

不可用，尝试在Python中访问该脚本会导致

KeyError

。尝试了wfastcgi的此解决方法：-结果：URL不再包含问号。相反，它们包含的编码字节百分比在解释为UTF-8时会变得杂乱无章。更正我之前的评论：这里描述的修补程序和注册表变量实际上解决了wfastcgi的问题。对于ISAPI，解决方案是从服务器变量

HTTP\u URL

获取URL，而不是

PATH\u INFO

。这将提供原始的百分比编码URL，然后可以正确解码。在wfastcgi脚本中，

HTTP\u URL

不可用，尝试在Python中访问该脚本会导致

KeyError

。尝试了wfastcgi的此解决方法：-结果：URL不再包含问号。相反，它们包含的编码字节百分比在解释为UTF-8时会变得杂乱无章。更正我之前的评论：这里描述的修补程序和注册表变量实际上解决了wfastcgi的问题。