url编码格式：为什么你的链接总在奇怪的地方断掉

链接断掉的那一下，发生了什么

先看一个日常场景：你在搜索框输入“开发者 工具”，浏览器地址栏里实际出现的是 q=开发者%20工具。那个 %20 就是空格的编码结果。如果空格原样留在链接里，很多客户端在解析时会把空格当作参数结束的标志，后半截内容就被截掉了。

类似的还有 &。它本身是分隔查询参数的符号，如果某个参数值里恰好包含 &，不编码就会被误认为多了一个参数。# 更典型，它代表页面内锚点，出现在查询值里会让后面的内容变成片段标识，服务端根本收不到。这些字符在 url编码格式 里被称为保留字符，意思是它们有语法作用，不能随便当普通文本用。

百分号后面跟什么，不是随便填的

编码后的样子总是 % 加两位十六进制数字，比如 %20、%2F、%3F。这背后是把字符按某种字符集转成字节，再对每个字节做十六进制表示。这里有个容易踩的坑：同一个汉字在不同字符集下的字节序列不同，编码结果也不同。如今绝大多数场景默认用 UTF-8，但如果你对接的是一个老系统，它可能期待 GBK 编码的字节，直接套用 UTF-8 的结果就会对不上。

所以看到一串 %E5%BC%80 这样的内容，先别急着解码，确认对方用的字符集更省事。另外，% 本身也要编码成 %25，否则解析器会把后面的字符当成转义序列，轻则乱码，重则解析失败。

哪些字符可以偷懒不编码

并不是所有字符都必须转成百分号形式。字母、数字以及 -、_、.、~ 这几类通常可以原样保留，它们被称为非保留字符。但实际写代码时，很多人会采取更保守的策略：除了明确安全的字符，其余一律编码。这样做的好处是省去逐个判断的麻烦，坏处是链接会变长、可读性下降。

如果你只是手工拼一个查询参数，可以只处理空格、&、=、#、?、+ 这些高频“肇事者”。其中 + 在查询字符串里有时被解释为空格，具体取决于解析方，所以更稳妥的做法是把空格编码成 %20，而不是依赖 +。这种细节在调试时很磨人，用 url编码格式工具 对照一下编码前后的结果，往往比盯着代码猜更快。

编码和解码，方向别弄反

编码是把原始文本转成适合放进链接的形式，解码则是把链接里的百分号序列还原成可读文本。两个方向都可能出错：编码时漏掉某个保留字符，链接在传输中会被截断；解码时对已经解码过的内容再解一次，% 后面跟的数字可能被误读成转义序列，结果越解越乱。

一个实用的判断方法是看数据来源。如果字符串来自用户输入或拼接的查询参数，通常需要编码后再放入链接；如果是从链接里取出来的参数值，才需要解码。拿不准的时候，把待处理的内容贴进 URL编码工具 里，分别看编码和解码的输出，能快速确认自己处在哪个环节。

相关文章

• 极客解码base64：为什么解出来的常是乱码

  从乱码、填充符到字符集差异，讲清解码 Base64 时容易踩的坑，以及排查思路。

• 易语言base64解码怎么用才不容易出错

  面向易语言开发者的Base64解码说明，讲清字符串与字节集转换、编码识别和乱码排查的实用思路。

• 文件转换为base64编码：为什么需要以及如何正确使用

  了解文件转换为base64编码的含义、典型场景与常见误区，掌握在开发中处理二进制文件编码的实用思路。

• 文件base64解码：为何解码后还是乱码？

  文件base64解码后出现乱码或打不开？本文从文件类型、字符集、二进制处理等角度分析原因，并给出排查思路与工具选择建议。

• 文件base64在线编码和解码：如何避免传输乱码？

  了解文件base64在线编码和解码的用途与操作要点，避免文件在传输中损坏或乱码，并掌握常见问题的处理方法。

常见问题