在回答另一个问题时，我意识到我的 Javascript/DOM 知识已经有点过时了，因为我仍在使用escape/unescape来编码 URL 组件的内容，而现在看来我应该使用encodeURIComponent/decodeURIComponent代替。
我想知道的是escape/有什么问题unescape？有一些模糊的建议表明 Unicode 字符存在某种问题，但我找不到任何明确的解释。
我的网络经验相当有偏见，几乎所有的经验都在编写与 Internet Explorer 相关的大型 Intranet 应用程序。这涉及大量使用escape/unescape并且所涉及的应用程序已经完全支持 Unicode 多年了。
那么escape/unescape应该有哪些 Unicode 问题？有没有人有任何测试用例来证明问题？
我想知道的是 escape/unescape 有什么问题？
它们本身并没有“错误”，它们只是它们自己的特殊字符串格式，看起来有点像 URI 参数编码，但实际上并非如此。特别是：
因此，如果您使用 escape() 创建 URI 参数值，您将得到包含加号或任何非 ASCII 字符的字符串的错误结果。
escape() 可以用作内部仅 JavaScript 编码方案，例如转义 cookie 值。然而，现在所有浏览器都支持 encodeURIComponent（最初并非如此），没有理由优先使用转义。
我所知道的转义/取消转义只有一种现代用途，这是通过利用 URIComponent 处理中的 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，然后将%XX熟悉的十六进制编码escape应用于任何不会网址安全。
顺便说一句，这就是为什么您可以在没有任何循环或垃圾生成的情况下在 javascript 中制作两个功能的 UTF-8 编码器/解码器，通过组合这些原语来消除除 UTF-8 处理副作用之外的所有副作用，因为unescape和decodeURIComponent版本反过来一样。
(*) 脚注：一些现代浏览器（如 Google Chrome）已经过调整以生成 %uXXXX 用于 255 以上字符转义范围最初没有定义，但网络服务器对解码编码的支持不如实现解码 IETF 标准化的基于 UTF-8 的编码。
我遇到的另一个“现代”用途是解析一个 URI 编码的字符串，该字符串可能包含无效的 UTF8 字节序列。在某些情况下，decodeURIComponent 可能会引发异常。您可能需要捕获此异常并回退到使用 unescape。
一个例子是 'tür' 编码为 't%FCr' ，我见过 Firefox 产生的（当字符粘贴到地址栏中？后）。
最好的答案是它在这个网站上在线工作http://meyerweb.com/eric/tools/dencoder/
function decode() {
var obj = document.getElementById('dencoder');
var encoded = obj.value;
obj.value = decodeURIComponent(encoded.replace(/\+/g, " "));
}