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只有一个现代用途,这是通过利用URIComponent处理中的UTF-8处理来实现UTF-8编码器/解码器的快捷方式:

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

escape仅对0到255(ISO-8859-1)范围内的字符进行操作(ISO-8859-1,它实际上是用单个字节表示的unicode代码点).(*)

encodeURIComponent 适用于javascript可以表示的所有字符串(这是unicode基本多语言平面的整个范围,即unicode代码点0到1,114,111或0x10FFFF,几乎涵盖当前使用的任何人类书写系统).

这两个函数都生成url安全字符串,只使用0到127的代码点(US-ASCII),后者通过首先将字符串编码为UTF-8,然后将%XX熟悉的十六进制编码escape应用于任何不符合的代码点来完成.是安全的.

顺便说一下,为什么你可以在没有任何循环或垃圾生成的情况下在javascript中制作一个双功能UTF-8编码器/解码器,通过组合这些原语来消除除了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,  " "));
}

我遇到的另一种“现代”用法是解析URI编码的字符串，该字符串可能包含无效的UTF8字节序列。在某些情况下，decodeURIComponent可能引发异常。您可能需要捕获此异常，然后退回到使用unescape。

一个例子是将“tür”编码为“ t％FCr”，我见过Firefox产生（将字符粘贴到地址栏后的？）。