javascript - HTML5 History.pushState 破坏包含百分比编码的非 Ascii (Unicode) 字符的 URL

Question

在 OSS 网络应用程序中，我们有执行一些 Ajax 更新的 JS 代码(使用 jQuery，不相关)。页面更新后调用html5历史接口(interface)History.pushState，代码如下:

var updateHistory = function(url) {
    var context = { state:1, rand:Math.random() };
    /* -----> bedfore the problem call <------- */
    History.pushState( context, "Questions", url );
    /* -----> after the problem call <------- */
    setTimeout(function (){
        /* HACK: For some weird reson, sometimes something overrides the above pushState so we re-aplly it
                 This might be caused by some other JS plugin.
                 The delay of 10msec allows the other plugin to override the URL.
        */
        History.replaceState( context, "Questions", url );
    }, 10);
};

[请注意:完整的代码段是为上下文提供的，HACK部分不是本题的问题]

该应用程序是国际化的，并且在 URL 中使用 URL 编码的 Unicode 段，因此在上面的代码中在标记的问题调用之前，URL 参数包含(如在 Firebug 中检查的那样):

"/%D8%A7%D9%84%D8%A3%D8%B3%D8%A6%D9%84%D8%A9/scope:all/sort:activity-desc/page:1/"

编码段为百分号编码的utf-8。浏览器窗口中的 URL 是:(只是为了完整性，并不重要)

http://<base-url>/%D8%A7%D9%84%D8%A3%D8%B3%D8%A6%D9%84%D8%A9/

在调用之后，浏览器窗口中显示的 URL 变为:

http://<base-url>/%C3%98%C2%A7%C3%99%C2%84%C3%98%C2%A3%C3%98%C2%B3%C3%98%C2%A6%C3%99%C2%84%C3%98%C2%A9/scope:all/sort:activity-desc/page:1/

URL 编码段只是 mojibake，是在某种程度上使用错误编码的结果。正确的 URL 应该是:

http://<base-url>/%D8%A7%D9%84%D8%A3%D8%B3%D8%A6%D9%84%D8%A9/scope:all/sort:activity-desc/page:1/

此行为已在 FF 和 Chrome 上进行了测试。

历史界面specs不要提及有关编码 URL 的任何内容，但我假设在接口(interface)的函数调用中使用 URL 时将应用 URL 形成的默认标准(utf-8 和百分比编码等)。

关于这里发生的事情的任何想法。

编辑:

我没有注意 History 中的大写 H - 这段代码实际上使用了 History.js历史界面的包装器。我替换为直接调用 history.pushState(注意小写的 h)而不通过包装器，据我所知，代码按预期工作。原始代码的问题仍然存在 - 因此 History.js 库似乎存在问题。

Answer 1

更新

作为Doug S在下面的评论中解释说，最新版本的 History.js 包含针对此行为的修复。他还发现我的解决方案在浏览器(例如 IE 9 及以下版本)中使用时会导致双重编码，这需要哈希回退，所以我建议不要使用下面详述的修复方法，而是使用 download the latest version .

我在下面保留了我的原始答案，因为它确实更详细地解释了正在发生的事情。

---

巴塞尔找到了某种解决方案，但对于引擎盖下发生的事情仍然存在一些困惑。该答案详细介绍了问题并提出了更好的解决方案。 (如果需要，您可以直接跳到修复。)

问题

首先，打开浏览器的 JS 控制台并运行:

window.encodeURI(window.unescape('%D8%A7%D9%84%D8%A3%D8%B3%D8%A6%D9%84%D8%A9'))

是不是很眼熟？它应该——这就是您的 URL 被破坏的结果。问题出在执行 History.unescapeString ，特别是这一行:

tmp = window.unescape(result);

window.unescape是 DOM Level 0函数——也就是说，一个来自 Netscape 2 古老时代的非标准化遗迹。它使用 RFC 2396 中定义的转义规则。 , 根据未保留范围之外的字符(字母数字和一小组标点符号)被编码为八位字节。

这适用于 US-ASCII 范围，但并非所有(实际上是绝大多数)UTF-8 字符都可以用单个字节表示。由于 URI 没有内置的方式来表示正在使用的字符集，window.unescape只是假设每个字符都映射到一个八位位组，并愉快地破坏任何不映射的字符。

在此示例中，您的网址中的第一个字母是 Arabic letter alef (ا) ，由两个字节表示:0xD8 0xA7 . window.unescape将这些解释为两个单独的字符: 0x00 0xD8 (Ø—capital O with stroke)和 0x00 0xA7 (§—section sign) .

这是一个 known issue使用 History.js。

修复

正如提问者上面提到的，可以通过使用 History API 的 native 实现而不是 History.js 包装器来回避这个问题，即 <em>h</em>istory.pushState而不是 <em>H</em>istory.pushState .

这适用于支持 History API 的浏览器，但对于那些不支持的浏览器则失去了 polyfill 的好处。幸运的是，有更好的解决方法。打开您引用的 History.js 源并找到这一行(在我的副本中为 ~1059):

tmp = window.unescape(result);

替换为:

tmp = window.unescape(encodeURIComponent(result));

或者，如果您使用的是压缩源，请替换 a.unescape(c)与 a.unescape(encodeURIComponent(c)) .

为了测试此更改，我在本地 Web 服务器上以阿拉伯​​语命名的目录中运行了 History.js HTML5 jQuery 测试套件。在进行更改之前，测试 14 失败；更改后，所有测试均通过。

致谢

尽管我独立找到了问题和解决方案，Damien Antipa值得称赞的是首先找到它并制作了pull request with the fix .