我们做的事很朴素：把 urlencode 这件事从「看着像天书」讲到「哦，原来是这么回事」，顺手把踩过的坑、查过的规范、写过的例子都摊开放在这儿，你随时来翻。
urlencode.cn 是一个专注 urlencode 与 URL 编码相关话题的中文内容站点。名字很直白，因为我们想解决的问题也很直白：你在浏览器地址栏、接口参数、表单提交里看到一串 %E4%B8%AD%E6%96%87 这样的字符，想知道它到底是什么、怎么来的、会不会出错——我们希望你在这一站里，十分钟之内就能弄明白。
我们不是一家做「大而全」的平台。团队规模不大，编辑和作者加起来也就几个人，日常干的事是：翻 RFC 3986 这类规范原文、在 PHP / Python / JavaScript / Java / Go 里各写一遍对照示例、把中文、空格、斜杠、加号这些最容易出事的字符逐个跑一遍，然后把结论写成正常人能读懂的中文。很多知识点不是我们发明的，但我们尽量把它讲得比搜索结果第一页更清楚一点。
我们解决的问题其实很具体。举几个真实场景：前端同学用 encodeURIComponent 拼了一个带中文的搜索链接，后端收到后解码出来是乱码；做爬虫的朋友发现同一个商品页在两次请求里参数长得不一样，怀疑自己抓错了；还有人把 Base64 和 urlencode 混为一谈，排查了半天。这些坑我们基本都踩过，所以更愿意把「为什么」讲透，而不是只丢一段代码让你抄。
坚持的理念就三条：能查证的才写、能跑通的才举例、看不懂的就说看不懂。我们不会为了凑字数编造某年某月某日发生过什么，也不会给一个查不到出处的「权威数据」；具体到某个库的默认行为，如果版本之间有差异，我们会把差异写出来，而不是挑一个版本当唯一答案。
搜「urlencode」出来的结果里，真正能用的其实没那么多。下面这几条是我们自己筛资料时的判断标准，也顺便把 urlencode 里最容易讲错的地方说清楚。
urlencode 其实不是一个函数，而是一类行为的统称。浏览器里至少有三种不同的入口：encodeURI 会保留 / ? & = # 这类结构字符，适合整条 URL；encodeURIComponent 会把这些也一起编码，适合拼单个参数值；escape 早就废弃了，但网上仍有一大批老文章在教。
一篇教程如果通篇只说「用 encodeURIComponent 就对了」，而不提场景差异，那基本可以打个折扣。真实情况是：你把整条 URL 丢进 encodeURIComponent，https:// 里的冒号和斜杠会被编成 %3A%2F%2F，请求直接发不出去。
这是提问率最高的一处。结论是：两者都存在，但归属不同。%20 来自 RFC 3986 的百分号编码规则，任何位置都成立；+ 表示空格则是 application/x-www-form-urlencoded 这种表单编码约定里的写法，只在该上下文里被解释为空格。
所以你会看到 PHP 的 urlencode() 把空格变成 +，而 rawurlencode() 变成 %20。路径段里用 +，服务器可能真的去找一个名字带加号的文件。判断一篇文章是否内行，看它有没有把这一点拆开讲就够了。
urlencode 本身只处理字节，不处理字符。一个汉字在 UTF-8 下通常占 3 个字节，每个字节再转成 %XX，于是「中」就变成了 %E4%B8%AD。如果你的页面是 GBK 编码，同一个字会变成另外两个百分号组合。
这就是「编码后乱码」的根源：编码端和解码端的字符集不一致。排查时别急着改代码，先确认两端到底用的是什么字符集，比反复试函数有效得多。
RFC 3986 把 URL 里允许直接出现的字符分成保留字符和非保留字符。字母、数字、-、_、.、~ 属于非保留字符，编不编码结果一样；: / ? # [ ] @ 这些是保留字符，含义取决于位置。
知道这条的实际好处是：调试时看到一长串百分号，可以快速判断哪些是「必须编的」，哪些是「某个库多编了」。有些老库会把 ~ 也编成 %7E，虽然多数服务端能兼容，但严格说并不符合现行规范。
参数被编码一次是正常的，被编码两次就出事了。%E4%B8%AD 再编一次会变成 %25E4%25B8%25AD，因为百分号本身也被编码成了 %25。服务端只解一次，拿到的就是字面量 %E4%B8%AD，而不是「中」。
常见诱因是：前端编了一次放进 query，中间层网关或 SDK 又对整个 URL 编了一次。排查办法很土但有效——把最终发出的完整 URL 打印出来，从头到尾数一遍百分号出现的层数。
我们自己的习惯是：先搜规范编号而不是搜函数名。搜「RFC 3986 percent-encoding」得到的是定义，搜「urlencode 怎么用」得到的多半是二手转述。其次，查具体语言行为时优先看官方文档对应版本的页面，因为默认行为在版本之间改过。
最后一条：遇到「某博客说可以这样」的说法，先在本地跑一个最小例子验证。编码这类问题，五行代码就能证伪，没必要靠信任。
先把话说在前面——本站的核心正文全部免费公开，下面这些只是给「想更省事」的人准备的选项，不买也完全不影响你读完任何一篇。
¥0 / 永久
¥0 / 订阅更新
按需 / 单独沟通
说明：以上价格仅描述本站自身服务，不涉及任何第三方产品；「团队内训」暂无公开价目表，需通过下方联系方式确认，我们不会在页面上摆一个看起来很唬人的「原价划线」。
我们不用「专业团队」四个字糊过去。下面几位是日常真正在写、在校对的人，名字用的是笔名，但活儿是实打实干出来的。
主笔 · 规范与原理
做后端十多年，习惯从 RFC 原文出发写东西，负责把标准里的措辞翻译成人话。
前端 · 示例与实测
负责所有 JavaScript 相关示例，坚持每段代码先在浏览器里跑通再写进文章。
校对 · 事实核查
每篇稿子发出前过一遍：出处有没有、版本说清没、有没有把「可能」写成「一定」。
运营 · 读者反馈
处理纠错邮件和侵权反馈，承诺 48 小时内给第一次回复，不确定的事会直说不确定。
我们不放任何第三方机构的奖牌或排名，因为那些东西既查不到出处，也说明不了内容质量。下面几项是站内可核对的规模数据。
以上数字仅用于描述 urlencode.cn 自身的运营规模，不构成任何第三方认证、评级或效果承诺；具体条目数会随更新变化，以页面实际内容为准。
下面这些话来自读者邮件与留言，征得同意后做了匿名处理，只保留原意，没有润色成广告词。
「之前一直搞不清为什么 PHP 里空格会变成加号，看完你们那篇讲 rawurlencode 和 urlencode 区别的，五分钟就通了。最有用的是它没直接给结论，而是把两种约定的来历说了一遍。」
后端开发 · 王先生 / 读者来信
「做数据采集的时候被二次编码坑了两天，最后是在你们排错那篇里看到『数百分号层数』这个土办法才定位到的。这种经验性的东西，官方文档里真没有。」
数据工程 · 匿名读者 / 邮件反馈
「我是非科班转行的，很多教程一上来就贴代码，这里是先讲清楚中文为什么变成三个百分号，再给例子。对我这种基础薄的人友好很多。」
前端新人 · 李同学 / 留言
这些问题在读者邮件里反复出现，答案我们尽量写得具体，能动手验证的地方都给了验证思路。
简单说，urlencode 是把「不适合直接出现在 URL 里的字符」转换成一种安全写法的过程。URL 这套规则定得比较早，能直接使用的字符有限，中文、空格、引号、换行这些要么不被允许，要么会破坏 URL 结构，于是统一用百分号加两位十六进制来表示，比如空格是 %20，汉字「中」在 UTF-8 下是 %E4%B8%AD。
你在地址栏看到的那一长串，其实是浏览器或程序在发送前自动做的转义。它并不是加密，任何人拿规则反推都能还原，所以别把敏感信息藏在 URL 参数里。
编码本身是中性的，它只是一种表示方法，既不安全也不危险。问题出在有人利用「编码后不易辨认」这一点，把真实地址藏起来。所以看到可疑链接时，别只看表面，先解码再判断。
本站只做知识讲解，不提供任何跳转代理，也不会替你打开外部地址。关于我们不做什么，可以看 内容说明与免责声明 那一节。
不需要。全部正文公开可读，没有账号体系，也不要求你订阅后才能看全文。我们只在「订阅更新」这一项里收集邮箱，且随时可以退订，除此之外不主动索取任何个人信息。
如果你只是想查一个字符编码成什么样，直接读对应小节即可，不必填任何表单。
没有放之四海皆准的一个函数，关键看你要编码的是「整条 URL」还是「某个参数值」。整条 URL 用保留结构字符的方式（如 JavaScript 的 encodeURI）；单个参数值用全量编码的方式（如 encodeURIComponent、PHP 的 rawurlencode）；只有在提交表单、且服务端明确按表单编码解析时，才用把空格变加号的那种。
更细的取舍和踩坑记录，写在 深度解读 里，建议顺着看完再动手改代码。
三者目的不同。urlencode 是为了让字符能安全地放进 URL；Base64 是把任意二进制数据转成可打印字符，常用于传输图片或证书，它不是为 URL 设计的，标准 Base64 里的 + 和 / 放进 URL 反而要再处理；HTML 实体转义（如 &）是为了在 HTML 文档里安全显示字符，跟 URL 无关。
常见的误解是把它们当成可以互相替代的「加密」，其实三者都不提供任何保密性。
没有固定排期，一般是遇到新的规范变化、读者反馈集中出现某类问题、或者我们自己踩到新坑时才更新。每篇文章顶部都标了更新时间，改过的地方会在正文里说明改了什么，不会悄悄替换。
纠错请发邮件到页面底部列出的邮箱，标题写明「纠错」加文章名即可，我们承诺 48 小时内首次回复。如果涉及版权问题，同样走这个渠道，并请附上可核实的权利证明。
把边界写清楚，对读者和我们都省事。以下几条是本站在内容上的自我约束，不是套话。