decodeURIComponent vs unescape，unescape有什么问题？

在回答另一个问题时，我意识到我的Javascript / DOM知识已经过时了，因为我仍然使用escape / unescape来编码URL组件的内容，而现在我应该使用encodeURIComponent / decodeURIComponent 。

我想知道的是escape / unescape有什么问题？ 有一些模糊的建议，说Unicode字符存在某种问题，但我找不到任何明确的解释。

我的网站体验相当有偏见，几乎所有的网站都在编写与Internet Explorer绑定的大型Intranet应用程序。 这涉及到很多escape / unescape的使用，并且涉及的应用程序已经完全支持Unicode很多年了。

那么escape / unescape应该有哪些Unicode问题？ 有没有人有任何测试案例来证明问题？

---

我想知道的是escape / unescape有什么问题？

它们不是“错误的”，它们只是它们自己特殊的字符串格式，看起来有点像URI参数编码，但实际上不是。 尤其是：

'+'意味着加号，而不是空格

有一种特殊的“％uNNNN”格式用于编码Unicode UTF-16码点，而不是编码UTF-8字节

因此，如果使用escape（）来创建URI参数值，那么对于包含加号的字符串或任何非ASCII字符，您将得到错误的结果。

escape（）可以用作内部的纯JavaScript编码方案，例如用于转义cookie值。 但是现在所有的浏览器都支持encodeURIComponent（本来不是这种情况），没有理由优先使用escape。

我所知道的escape / unescape只有一个现代用途，那就是通过利用URIC组件处理中的UTF-8处理，实现UTF-8编码器/解码器的快速方法：

utf8bytes= unescape(encodeURIComponent(unicodecharacters));
unicodecharacters= decodeURIComponent(escape(utf8bytes));

---

escape仅对范围在0到255之间的字符（ISO-8859-1，这实际上是用一个字节表示的unicode代码点）进行操作。 （*）

encodeURIComponent适用于所有字符串javascript可以表示（这是unicode基本多语言平面的全部范围，即unicode代码点0到1,114,111或0x10FFFF，它们涵盖了当前使用的几乎所有人类书写系统）。

这两个函数都生成只使用代码点0到127（US-ASCII）的url安全字符串，后者通过首先将字符串编码为UTF-8，然后将从escape的%XX十六进制编码应用于任何代码点这不会是URL安全的。

这就是为什么你可以在没有任何循环或垃圾生成的情况下，通过组合这些原语来取消除UTF-8处理的所有副作用以外，还可以在javascript中创建一个双通道的UTF-8编码器/解码器，就像unescape和decodeURIComponent版本反过来也一样。

（*）脚注：一些现代浏览器（如谷歌浏览器）已经调整为％uXXXX以上255字符范围内的字符转义最初并未定义，但Web服务器对解码该编码的支持不如解码IETF标准的基于UTF-8的编码。

---

最好的答案是这是它在这个网站上在线工作http://meyerweb.com/eric/tools/dencoder/

function decode() {
    var obj = document.getElementById('dencoder');
    var encoded = obj.value;
    obj.value = decodeURIComponent(encoded.replace(/+/g,  " "));
}

链接地址: http://www.djcxy.com/p/2907.html

上一篇: decodeURIComponent vs unescape, what is wrong with unescape?

下一篇: Authoritative position of duplicate HTTP GET query keys