javascript - 在 javascript 中编码了一个 unicode 字符串后，如何在 Python 中对其进行解码？

Question

平台:应用引擎框架:webapp/CGI/WSGI

在我的客户端 (JS)，我通过将 URL 与 unicode 字符串连接来构造一个 URL:

http://www.foo.com/地震

然后调用encodeURI获取

http://www.foo.com/%E5%9C%B0%E9%9C%87

我把它放在一个 HTML 表单值中。

表单已提交给 PayPal，我已将编码设置为“utf-8”。

然后 PayPal(通过 IPN)在上述 URL 上发出发布请求。

在我的服务器端，WSGIApplication 尝试使用我定义的正则表达式提取 unicode 字符串:

(r'/paypal-listener/(.+?)', c.PayPalIPNListener)

我会尝试通过调用对其进行解码

query = unquote_plus(query).decode('utf-8')

(或变体)但我会得到错误

/paypal-listener/%E5%9C%B0%E9%9C%87

... (ommited) ...

'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)

(第一行是请求URL)

当我检查 query 的长度时，python 说它的长度为 18，这向我暗示 '%E5%9C%B0%E9%9C%87' 无论如何都没有被编码.

Answer 1

原则上这应该可行:

>>> urllib.unquote_plus('http://www.foo.com/%E5%9C%B0%E9%9C%87').decode('utf-8')
u'http://www.foo.com/\u5730\u9707'

但是，请注意:

1. unquote_plus用于 application/x-form-www-urlencoded 数据，例如 POSTed 表单和查询字符串参数。在 URL 的路径部分，+ 表示文字加号，而不是空格，因此您应该使用普通的 unquote在这里。

2. 您通常不应取消引用整个 URL。在 URL 的组成部分中具有特殊含义的字符将丢失。您应该将 URL 分成几部分，获取您感兴趣的单个路径名组件 (%E5%9C%B0%E9%9C%87)，然后取消引用

(如果你想将一个 URI 完全转换为一个 IRI，比如 http://www.foo.com/地震 事情就有点复杂了。只有路径/查询/片段部分IRI 是 UTF-8-% 编码的；域名是使用古怪的“Punycode”IDN 方案在 Unicode 和字节之间映射的。)

This gets received in my python server side.

您的服务器端到底是什么？服务器、网关、框架？您如何获得 url 变量？

您似乎得到了一个 UnicodeEncodeError ，这是关于unquote 函数的输入 中意外的非ASCII 字符，根本不是解码问题。所以我建议某些东西已经将您的 URL 的路径部分解码为某种 Unicode 字符串。让我们看看那个变量的 repr!

不幸的是，一些 Web 服务器存在许多严重的问题，这使得在 URL 的路径名部分使用 Unicode 非常不可靠，不仅在 Python 中如此，而且在一般情况下也是如此。

主要问题是 PATH_INFO 变量被定义(由 CGI 规范，随后由 WSGI)进行预解码。这是一个可怕的错误，部分原因是上面的问题 (1)，这意味着您无法在路径部分获得 %2F，但更严重的是因为解码 %- sequence 引入了应用程序无法控制的 Unicode 解码步骤。服务器环境在处理 URL 中的非 ASCII % 转义符方面有很大差异，而且通常不可能重新创建 Web 浏览器传入的确切字节序列。

IIS 是一个特殊的问题，因为它会尝试默认将 URL 路径解析为 UTF-8，如果路径不是，则回退到极不可靠的系统默认代码页(例如，西方 Windows 安装上的 cp1252) t 一个有效的 UTF-8 序列，但没有告诉你。然后，您可能会遇到相当严重的问题，试图从环境变量映射中读取 PATH_INFO 中的任何非 ASCII 字符，因为 Windows envvars 是 Unicode，但被 Python 2 和许多其他作为字节访问系统代码页。

Apache 通过提供一个额外的非标准环境 REQUEST_URI 来缓解这个问题，它保存浏览器提交的原始的、完全未解码的 URL，这很容易手动处理。但是，如果您正在使用 URL 重写或错误文档，则未映射的 URL 可能与您认为的不符。

一些框架试图解决这些问题，并取得了不同程度的成功。 WSGI 1.1 预计会尝试对此进行标准化，但与此同时，我们所处的实际位置是 Unicode 路径不会在任何地方都有效，试图在一台服务器上修复它的黑客通常会在另一台服务器上破坏它.

您始终可以使用 URL 重写将 Unicode 路径转换为 ​​Unicode 查询参数。由于 QUERY_STRING 环境变量未在应用程序外部解码，因此更容易以可预测的方式处理。