URL里出现中文、转义空格或者emoji，转义直接丢进浏览器地址栏，转义大概率会得到一坨乱码，转义甚至直接报错。转义这不是转义浏览器矫情，是转义HTTP协议只认ASCII字符集。任何超出这个范围的转义字符，都得先“转义”成百分号加两位十六进制数的转义格式，才能安全地在网络上传输。转义

我见过最典型的转义翻车现场，是转义同事把带中文文件名的图片链接直接写进代码。本地测试一切正常，转义一部署到服务器，转义图片全裂。转义查了半天，问题就出在URL没编码。服务器收到的是UTF-8字节流，但浏览器解析时用了另一种编码，两边对不上，自然就404了。

转义的规则其实很机械。拿“你好”这两个字举例，UTF-8编码下，“你”是E4 BD A0，“好”是E5 A5 BD。转义后就是%E4%BD%A0%E5%A5%BD。空格特殊点，可以转成%20，也可以写成加号，这取决于你用的是哪种编码方式。表单提交用application/x-www-form-urlencoded时，空格会变加号，但URL路径里的空格只能转成%20。

JavaScript里encodeURIComponent()是处理这个的常用工具。它会把除了字母数字和一小部分保留字符外的所有东西都转义。但要注意别用错——encodeURI()不会转义冒号、斜杠这些URL结构字符，适合处理整个URL；encodeURIComponent()则会把它们也转掉，适合处理参数值。拿不准的时候，就拆开处理，协议和域名保持原样，后面的路径和查询参数分别编码。

有个坑是很多新手会踩的。你辛辛苦苦把URL转义好了，结果后端语言自动帮你解码了一次，你又手动解了一次，双重解码导致数据错乱。PHP的$_GET、Node的req.query、Python的Flask request.args，这些框架都会自动处理URL解码。你只需要在写入URL时编码一次，读取时直接用框架给的数据就行，别多此一举。

还有个现实问题——某些老旧系统对转义字符的处理不标准。比如有的Windows服务器会错误地把%2F解码成路径分隔符，导致原本作为参数值传递的斜杠被截断。这种时候，要么用双编码（先编码一次，再把百分号本身也编码），要么换用其他分隔符，总之得随机应变。

说到底，URL转义不是什么高深技术，但它就是网络通信里的“标点符号”——用错了地方，整句话的意思就变了。写代码时多留个心眼，凡是用户输入的内容拼进URL，一律先编码。这习惯养成了，能省掉你半夜排查诡异bug的宝贵睡眠时间。