创作场景

   工作中遇到了一个带中文的URL链接，因为是文件预览，在文件名为uuid的情况下需要将中文名展示在导航栏，所以将文件中文名拼接在了URL后面，但是出现了IE报400错误的情况，经过排查是URL带中文的问题，特此记录。

前端JS对URL的三种编码和解码方式

1. escape 和 unescape

   这两个一般是用于对某个变量进行编码的，无法直接作用与URL，除了ASCII字母、数字、标点符号"@ * _ + - . /"以外，对其他所有字符进行编码。在u0000到u00ff之间的符号被转成%xx的形式，其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。

   一般这个是不常用的，不过对于变量进行编码的时候要注意，如果变量中有特殊符号+会自动编码为空格。

2. encodeURI 和 decodeURI

   这两个是对特殊含义的符号"; / ? : @ & = + $ , #"，也不进行编码。主要对URL进行部分编码，编码后，它输出符号的utf-8形式，并且在每个字节前加上%。它对应的解码函数是decodeURI()，一般在URL中我们常常使用的就是这个，而且大多数情况都是对链接中拼接对象时进行编码，接收时进行解码。

3. encodeURIComponent 和 decodeURIComponent

   与encodeURI()的区别是，它用于对整个URL进行编码。“; / ? : @ & = + $ , #”，这些在encodeURI()中不被编码的符号，在encodeURIComponent()中统统会被编码。它对应的解码函数是decodeURIComponent()。这种适用场景比较少，一般我们的链接除了对象和中文外都需要暴露在外面以便用户查看和复制。

   以上就是前端中常用的三类编码和解码方式，当然也都比较常见，如果需要将中文传递给后台，一般也需要进行编码，而后台也有对应的解码方法，这里就不做赘述了。

本文重点

   一定要养成一个好习惯，如果URL中出现了中文，一定要使用编码方法进行编码，虽然现在的浏览器大多数都进行了兼容处理，对于一些老旧的浏览器比如IE或者一些平板啊手机都会出现不兼容报错的情况，而400错误大多数情况就是我们的URL错误啦，而有时候可能不是拼接问题，编码也会影响。