在网络通信中，URL（统一资源定位符）是定位资源的坐标，但它只能传输一套受限制的字符。RFC 3986标准将字符划分为非保留字符（字母、数字、连字符、下划线、点号、波浪号）和保留字符（如/、?、#、&、=等）。保留字符在URL中有特定用途：?用于分隔路径和查询字符串，&用于分隔参数，#用于标识片段。如果你的数据中包含了这些保留字符，或者使用了中文、日语等非ASCII字符，就必须将其转换为百分号编码（percent-encoding）格式，否则URL的解析会发生错误。例如，你想搜索关键词“C#教程”，如果直接写成 search=C#教程，#会被浏览器视为片段分隔符，导致后续内容丢失。正确的做法是将#编码为%23，将“教程”两个中文字按照UTF-8编码为%E6%95%99%E7%A8%8B。使用我们的URL编码工具，你只需输入文本，选择适当的模式，就能得到安全传输的编码字符串。对应的解码操作可以交给URL解码工具。
当你使用编程语言处理URL时，可能会遇到encodeURIComponent和encodeURI两个函数。它们的区别直接对应我们的URL编码工具中的两种模式。完整URI模式（类似encodeURI）旨在编码一个完整的URL，它会保留那些在URL结构中具有特殊意义的字符，如斜杠/、问号?、连接符&和等号=。如果你编码一整条链接，需要保持其结构，就使用这种模式。组件模式（类似encodeURIComponent）则用于编码一个单独的URI组件，最常见的就是查询字符串中某个参数的值。它会将?、&、=等所有保留字符都转换成百分号形式，因为不这么做的话，参数值内部出现的&会被误认为另一个参数的分隔符。举个例子，假设你要传递的查询参数值是“red&blue”，如果使用了完整模式，&会保留，导致服务器接收到的是color=red和blue=两个参数。组件模式将&编码为%26，保证了color=red%26blue的完整性。你可以在编码后使用URL解码检查结果是否符合预期。选择正确模式，是保证数据精准传递的第一步。
在Web表单发展的早期，application/x-www-form-urlencoded规范将空格编码为加号+。当你提交一个HTML表单时，浏览器默认会将输入中的空格替换为+号添加到查询字符串中。而RFC 3986标准规定，空格的百分号编码是%20。这就造成了两种空格表示法并存的现状。在实际应用中，查询字符串的键值对里，许多后端框架（如PHP的$_GET）会自动将+解析为空格，但对于URL的路径部分，+就是字面量的加号，不会被解析为空格。我们的URL编码工具提供了“将空格编码为+号”的选项，激活后在查询参数的值中会将空格转成+号，迎合传统表单格式。如果你想要与严格遵循RFC的API交互，或者编码URL的路径部分，建议不勾选该项，保留%20。最稳妥的做法是：路径中只使用%20，查询字符串值中根据目标服务器的预期选择。无论哪种，编码后字符串均可安全传输。
UTF-8已成为Web的通用字符编码。URL编码工具处理非ASCII字符时，会先将字符转换为UTF-8字节序列，再对每个字节输出%后跟两位十六进制数。例如“你”的UTF-8字节为0xE4 0xBD 0xA0，最终编码为%E4%BD%A0。emoji“😊”则占用四个字节F0 9F 98 8A，变成%F0%9F%98%8A。现代浏览器在地址栏会对这些序列进行解码显示，方便阅读，但当你复制链接时，得到的仍然是百分号编码形式。这对于包含中文关键词的营销链接尤其重要：如果未编码直接在微信等平台分享，可能导致部分字符丢失或被截断。使用我们的URL编码工具，你可以预览任何中文或emoji文本的编码结果，然后放心地拼接URL。若你收到一串看不懂的百分号序列，也可以借助URL解码将其还原为可读文字。
构建动态查询字符串时，最安全的流程是单独对每个参数的值使用组件模式进行编码，然后再拼接完整的URL。假设你需要传递一个参数keyword，原始值为“北京&上海=必玩”。如果直接拼出 keyword=北京&上海=必玩，&和=会破坏参数结构。正确做法：打开URL编码工具，选择“编码组件”模式，输入“北京&上海=必玩”，点击编码得到 %E5%8C%97%E4%BA%AC%26%E4%B8%8A%E6%B5%B7%3D%E5%BF%85%E7%8E%A9。然后将该编码后的字符串作为keyword的值拼接到URL中。最终链接为 https://example.com/search?keyword=%E5%8C%97%E4%BA%AC%26%E4%B8%8A%E6%B5%B7%3D%E5%BF%85%E7%8E%A9。这样可以确保服务器收到准确的参数。编码完成后，你还可以用URL二维码生成器将安全链接转为二维码，便于线下物料传播。
&符号在URL中默认作为参数分隔符。如果你的某个参数值里包含&，比如公司名“AT&T”、分类“糖果&糕点”，直接写入URL就会产生计划外的参数切分。例如：https://shop.com?company=AT&T&type=retail 实际上会被解析为company=AT，T和type=retail两个参数。要避免这一问题，必须对参数值中的&进行编码。使用URL编码工具的组件模式，输入“AT&T”，会得到AT%26T。此时再拼接的URL便是 ...?company=AT%26T&type=retail，服务器解码后就能还原出正确的公司名。类似的，加号+在查询字符串中可能被解释为空格，如果你的值需要保留字面加号，也要将其编码为%2B。建议对所有参数值都进行编码，不管当前是否含有特殊字符，以消除隐患。编码后可用URL解码验证。
UTM参数是营销人员追踪流量来源的关键。由于UTM参数的值经常包含中文活动名称、渠道信息等，如果直接拼贴，链接中的特殊字符和Unicode会导致统计偏差或链接失效。例如在微信推广中，链接形如 https://shop.com?utm_source=weixin&utm_campaign=春节大促&utm_content=优惠券，其中的“春节大促”必须编码。使用我们的URL编码工具，选择组件模式，逐一编码utm_campaign和utm_content的值，得到安全字符串后再拼接完整URL。这样可以保证Google Analytics或百度统计等工具正确记录中文活动名。如果想在宣传海报上展示该跟踪链接，还可以借助URL二维码生成器将编码后的URL制作成二维码，用户扫码即可进入统计链路。此外，若需要在链接中携带更复杂的数据，可以了解Base64编码作为另一种编码方案，但Base64生成的字符串可能包含+和/，再次嵌入URL时仍需注意百分号编码。总之，使用专门的URL编码工具是一步到位的最佳实践。
因为 & 在URL里是参数分隔符，如果参数值本身包含 &，就必须进行URL编码，把它转成 %26，这样浏览器才不会误以为那是新的参数开始。用我们的URL编码工具，选择“组件编码”模式，它会把你值里的 &、=、? 等保留字符都安全转义。
工具提供了两种模式：如果你要编码一段完整的网址，保持其中的协议、域名、路径分隔符不被转义，就可以选“全URI编码”模式，类似于JavaScript的encodeURI。如果你只是给某个查询参数的值做转义，比如一段中文或一段网址作为参数值，就选“组件编码”模式，它会转义所有对查询结构有意义的字符，确保值安全注入，这和encodeURIComponent行为一致。
两者的区别主要和编码场景有关。%20是通用的百分号编码空格方式，任何地方都有效。+ 则是早期表单提交时，对query string中空格的替代符号。如果你的编码目标是放在URL的查询参数值里，并且想兼容传统表单风格，可以在工具里勾选“空格编码为+”；而如果你在路径部分或者为了最严格的兼容，选择%20更稳妥。
表情符号和带重音字母都属于非ASCII字符，编码时会先按UTF-8转成字节序列，再对每个字节加上%前缀。例如ü的UTF-8编码是0xC3 0xBC，结果就是%C3%BC。微笑表情😊的编码会长一些，变成%F0%9F%98%8A。我们的工具自动识别字符集，你只需要把原始文本粘贴进去就行，不需要自己计算。
用途不同。URL编码（百分号编码）适合把任意字符变成可在URL中直接使用的安全形式，它不会增大数据长度太多，并且解码后能完全还原原内容。Base64编码则会把二进制或文本数据转成A-Z、a-z、0-9、+、/的字符集，虽然也能在URL使用，但长度会增加约33%，而且标准Base64里的+、/还需要额外URL编码。如果需要把数据嵌入URL，优先用URL编码；如果是数据传输或存储需要纯文本表示，才考虑Base64编码。
编码后的URL有时会很长，你可以用短链接服务压缩，也可以直接用URL二维码生成器把它做成二维码图片。这样打印出来或放在屏幕上，别人扫码就能直接访问。在分享前记得先用URL编码工具确保链接里的中文和特殊字符不会导致扫码后打开错误地址。
你可以复制整个URL或部分参数值，粘贴到URL解码工具里解码看看。如果解码后出现了乱码、空格变成奇怪符号，或者&、=等意外把参数拆开了，就说明之前的编码方式不对。反过来，你也可以在URL编码和解码之间来回倒腾，直到确认数据干净为止。
