URL 编码
将字符串编码为 URL 安全格式（encodeURIComponent）。
点击示例卡片自动填入输入框
URL 编码速查
→%20空格,→%2C逗号#→%23井号&→%26与号=→%3D等号?→%3F问号/→%2F斜杠:→%3A冒号@→%40@ 符号+→%2B加号%→%25百分号[→%5B左方括号]→%5D右方括号{→%7B左花括号}→%7D右花括号"→%22双引号什么是 URL 编码？
URL 编码（百分号编码）是将 URL 中不允许直接出现的字符替换为 %XX 格式的过程，确保 URL 在网络传输中不发生错误解析。
本工具使用浏览器原生的 encodeURIComponent 函数，对所有非字母数字字符（除 -_.!~*'()）进行编码，适用于将字符串作为 URL 查询参数传递。
使用步骤
- 在左侧输入框粘贴需要编码的原始字符串
- 点击「编码」按钮，右侧输出 URL 安全格式
- 点击「复制结果」将编码后的字符串复制到剪贴板
典型生产场景
将用户输入的搜索关键词、筛选条件编码后拼接到 URL query string 中，防止 &、=、空格等字符破坏参数结构。常见于列表页的过滤参数和搜索框的跳转链接。
在 HMAC-SHA256 签名流程中，需要对参数键和值分别编码后再拼接签名原串。encodeURIComponent 会编码 = 和 &，防止参数值中的这些字符与签名原串的分隔符混淆，导致验签失败。
redirect_uri 作为授权请求的参数值，必须先经 encodeURIComponent 编码再拼接到完整授权 URL 中。未编码的回调地址中的 ? 和 = 会被授权服务器误解析为顶层参数，导致回调接收不到 code。
S3 / COS 等对象存储的 object key 可能包含中文、空格或特殊字符，需对路径逐段编码。注意不要编码 / 分隔符，只编码每段文件名，否则文件路径会被当作单层路径处理。
在 javascript: URL 或 onclick 属性中拼接用户输入时，除了 HTML 实体编码，还需要对 URL 进行编码。双重编码可以阻断攻击者注入恶意 javascript 代码的常见绕过路径。
深度专题：三种编码方式对比与选择
JavaScript 提供两种 URL 编码函数，加上 HTML 表单编码，实际存在三种编码方式。encodeURI 保留 URI 结构字符（# / ? : @ & = + $ , ;），适用于对整个 URI 进行编码；encodeURIComponent 编码所有非字母数字字符（仅保留 -_.!~*'()），适用于编码参数键值。两者的核心区别在于对 &、=、? 的处理 —— 编码这些字符的场景必须使用 encodeURIComponent。
表单编码（application/x-www-form-urlencoded）是第三种且常见的编码方式：空格转为 + 而非 %20，换行符转为 %0D%0A。它的行为与 JavaScript 原生函数不完全一致。例如 fetch API 的 URLSearchParams 使用的就是表单编码规则。如果你在后端验签时用的是表单编码，但前端用 encodeURIComponent 编码，签名结果会不一致。
双重编码是生产事故的高发区。典型场景：前端 encodeURIComponent 编码后传入 API，而 Express 或 Spring MVC 的中间件又自动解码一次 URL 参数，开发者在后端代码中手动再编码一次，最终写入数据库的值是双重编码的。防御措施是团队统一约定编码边界：要么「前端编码、后端不解码」，要么「后端解码、前端不编码」，避免两端都操作。
常见错误模式
- 对完整 URL 使用 encodeURIComponent — 协议中的 :// 被编码为 %3A%2F%2F，导致 URL 在浏览器地址栏输入后无法正常导航。正确做法：只对参数值编码，或先拆分 URL 再对各段分别处理。
- 在多层链路上反复编码 — URL 经过 Nginx 反向代理的 proxy_pass 转发时，如果 location block 未正确配置 rewrite 或 proxy_set_header，后端收到的 URI 可能已被部分解码或二次编码。判断是否发生了双重编码：检查结果中是否出现 %25（% 本身被编码）。
- 混淆 path 段编码和 query 编码规则 — path 段中 / 是合法分隔符不应编码，但 ? # 空格是非法的必须编码。query 参数值中 = & 是合法分隔符不应编码但作为参数值的一部分时必须编码。
- 忘记对非 ASCII 字符编码 — 直接在 URL 的 query string 中传递中文（如 ?name=张三），虽然现代浏览器地址栏能渲染，但某些中间代理、Nginx 日志或爬虫会截断或显示乱码。