URL特殊字符的转义
特殊符号 十六进制值 转义符为 %2B 空格 转义符为 + 或 %20 / 转义符为 %2F ? 转义符为 %3F % 转义符为 %25 # 转义符为 %23 & 转义符为 %26 = 转义符为 %3D 前些时间做了个文件下载的应用，由于中文名文件的原因，所以在拼URL的时候，会提前把文件名转义 fileName = URLEncoder.encode(fileName,"UTF-8"); 问题来了，如果文件名中带空格的话，出问题了，空格被转成了+，而不是%20，再向下载服务器进行下载请求时，Servlet不认，直接出错。 于是再考虑了一下，把代码中的空格转成%20。 代码如下： fileName = URLEncoder.encode(fileName,"UTF-8"); fileName = fileName.replaceAll("\\+","%20"); 如上，问题解决了，再decode也可以正常得到正确的文件名。 为什么会这样呢，网上搜了一把，原理如下： 一个URL的基本组成部分包括协议(scheme),域名，端口号，路径和查询字符串（路径参数和锚点标记就暂不考虑了）。路径和查询字符串之间用问号?分离。例如www.example.com/index?param=1，路径为index，查询字符串(Query String)为param=1。URL中关于空格的编码正是与空格所在位置相关：空格被编码成加号+的情况只会在查询字符串部分出现，而被编码成%20则可以出现在路径和查询字符串中。 造成这种混乱局面的原因在于：W3C标准规定，当Content-Type为application/x-www-form-urlencoded时，URL中查询参数名和参数值中空格要用加号+替代，所以几乎所有使用该规范的浏览器在表单提交后，URL查询参数中空格都会被编成加号+。而在另一份规范(RFC 2396，定义URI)里, URI里的保留字符都需转义成%HH格式(Section 3.4 Query Component)，因此空格会被编码成%20，加号+本身也作为保留字而被编成%2B，对于某些遵循RFC 2396标准的应用来说，它可能不接受查询字符串中出现加号+，认为它是非法字符。所以一个安全的举措是URL中统一使用%20来编码空格字符。 具体的做法上面也给出了。