Skip to content

URL 编码解码在线工具 — 内置 URL 结构解析

粘贴 URL 即时编码或解码,实时显示结果。内置 URL 解析器将协议、域名、路径、查询参数拆解为可编辑字段。支持 encodeURI 和 encodeURIComponent 双模式切换,检测双重编码问题。纯浏览器端运行,数据不离开设备。

无追踪 浏览器中运行 免费
已解码
已编码
已审核 RFC 3986 合规性、encodeURI/encodeURIComponent 正确性和 UTF-8 编码准确性 — Go Tools 工程团队 · 2026年4月7日

什么是 URL 编码(百分号编码)?

URL 编码,正式名称为百分号编码,是 RFC 3986 中定义的一种机制,用于表示统一资源标识符(URI)中不允许出现或具有特殊含义的字符。它将每个不安全的字节转换为百分号(%)后跟两个十六进制数字——例如,空格变成 %20,& 号变成 %26,中文字符「中」变成 %E4%B8%AD(其三个 UTF-8 字节,每个都进行百分号编码)。

URL 只能包含 ASCII 字符集中的有限字符。字母、数字和少量符号(- _ . ~)被视为「非保留」字符,可以直接出现。所有其他字符——包括空格、标点符号和整个 Unicode 范围——必须进行百分号编码才能在 URL 中安全传输。保留字符如 ?、&、= 和 # 在 URL 语法中充当结构分隔符,因此当它们作为字面数据而非分隔符使用时,也必须进行编码。

百分号编码在 Web 中无处不在:浏览器编码表单提交,API 需要编码的查询参数,OAuth 流程依赖正确编码的重定向 URI,国际化域名依赖编码处理非 ASCII 字符。编码错误会导致链接断裂、安全漏洞(如开放重定向攻击)和数据损坏。

本工具提供 encodeURI 和 encodeURIComponent 两种模式、内置 URL 结构解析器、实时转换和双重编码检测——所有操作均在浏览器中私密运行。

URL 编码经常与其他 Web 开发工具配合使用。您可能需要将 URL 进行 Base64 编码以嵌入 JWT 令牌或 API 载荷,或使用 JSON 格式化工具检查包含 URL 字符串的 JSON 数据的结构。

// Encode a query parameter value
const param = encodeURIComponent('hello world & goodbye');
console.log(param); // → 'hello%20world%20%26%20goodbye'

// Encode a full URL (preserves structure)
const url = encodeURI('https://example.com/path name?q=hello world');
console.log(url); // → 'https://example.com/path%20name?q=hello%20world'

// Decode a percent-encoded string
const decoded = decodeURIComponent('hello%20world%20%26%20goodbye');
console.log(decoded); // → 'hello world & goodbye'

// Build a URL with encoded parameters
const base = 'https://api.example.com/search';
const query = `?q=${encodeURIComponent('你好')}&lang=zh`;
console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh'

核心功能

双重编码模式

在 encodeURI(保留 URL 结构)和 encodeURIComponent(为参数值编码所有字符)之间切换,精确匹配您的需求。

内置 URL 解析器

自动将任何 URL 分解为协议、主机、端口、路径、查询参数和片段——每个字段均可编辑,并可重建为新 URL。

实时转换

输入时即时编码和解码——无需点击按钮,每次按键结果立即显示在另一区域。

100% 浏览器端处理

所有处理均在浏览器本地使用原生 JavaScript API 完成。数据绝不离开您的设备——无服务器上传、无追踪。

完整 UTF-8 支持

通过正确的 UTF-8 字节编码和解码,完美处理中文、日文、韩文、阿拉伯文、emoji 及任何 Unicode 文本。

双重编码检测

自动检测并警告双重编码问题(如 %2520 代替 %20),帮助您避免最常见的 URL 编码错误。

示例

解码乱码 URL

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den
https://example.com/search?q=hello world&lang=en

将完全百分号编码的 URL 解码为可读形式,还原原始查询参数和结构

中文字符

https://example.com/search?q=你好世界
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

中文字符被转换为 UTF-8 字节序列并进行百分号编码

查询参数

https://example.com/api?name=John Doe&role=admin&lang=en&sort=date desc
https://example.com/api?name=John%20Doe&role=admin&lang=en&sort=date%20desc

查询参数值中的空格和特殊字符被百分号编码,同时保留 URL 结构

完整 URL

https://user:pass@example.com:8080/path/to/page?key=value&arr[]=1#section-2
https://user:pass@example.com:8080/path/to/page?key=value&arr%5B%5D=1#section-2

包含凭证、端口、路径、带括号的查询参数和片段标识符的完整 URL

OAuth 重定向 URI

https://auth.example.com/authorize?redirect_uri=https://myapp.com/callback?code=abc&state=xyz
https://auth.example.com/authorize?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz

redirect_uri 值本身包含一个完整 URL,必须编码以避免其特殊字符被解析为外层 URL 的一部分

使用方法

  1. 1

    输入 URL 或编码字符串

    在解码区域粘贴 URL 进行编码,或在编码区域粘贴百分号编码的字符串进行解码。根据用途选择 encodeURI 或 encodeURIComponent 模式。

  2. 2

    查看结果和解析结构

    另一个区域会在您输入时即时更新。URL 解析器将 URL 分解为协议、主机、端口、路径、查询参数和片段——所有字段均可编辑。

  3. 3

    复制或重建

    点击复制按钮复制编码或解码结果。编辑各个 URL 组件,然后点击重建按钮从修改后的部分构造新 URL。

常见错误

双重编码(%2520 而非 %20)

当已编码的 URL 被再次编码时,就会发生双重编码。%20 中的 % 被编码为 %25,将 %20 变成 %2520。这会破坏 URL,因为服务器看到的是字面的 %20 字符串而非空格。

✗ 错误
https://example.com/path%2520with%2520spaces
✓ 正确
https://example.com/path%20with%20spaces

路径段中空格编码为 +

+ 字符仅在 application/x-www-form-urlencoded 格式(HTML 表单的查询字符串)中表示空格。在 URL 路径段中,+ 被解释为字面加号而非空格。路径段中的空格应始终使用 %20。

✗ 错误
https://example.com/my+file+name.pdf
✓ 正确
https://example.com/my%20file%20name.pdf

对查询参数值使用 encodeURI

encodeURI() 不编码 &、= 或其他保留字符,因此对包含这些字符的参数值使用它会破坏查询字符串结构。

✗ 错误
encodeURI('key=value&more')  → 'key=value&more' (& not encoded!)
✓ 正确
encodeURIComponent('key=value&more')  → 'key%3Dvalue%26more'

假设非 UTF-8 编码

一些旧系统使用 Latin-1 或 Shift-JIS 等编码处理 URL 参数。现代标准要求使用 UTF-8。用 UTF-8 解码器解码 Shift-JIS 编码的参数会产生乱码文本。

✗ 错误
Decoding %82%B1%82%F1 as UTF-8 (this is Shift-JIS for こん)
✓ 正确
Using UTF-8: %E3%81%93%E3%82%93 correctly decodes to こん

不考虑上下文编码相对路径

使用 encodeURIComponent 编码相对路径如 ../images/photo.jpg 会将斜杠和点转换为百分号编码序列,破坏路径结构。应使用 encodeURI() 或仅编码单个路径段。

✗ 错误
encodeURIComponent('../images/photo.jpg')  → '..%2Fimages%2Fphoto.jpg'
✓ 正确
Encode each segment: '../images/' + encodeURIComponent('my photo.jpg')

常见使用场景

调试乱码 URL
解码来自服务器日志、错误消息或浏览器开发者工具中的百分号编码 URL,读取原始的人类可读文本。
API 开发
为 REST API 调用编码查询参数值,确保 &、= 和空格等特殊字符不会破坏请求 URL。
OAuth 流程设置
在 OAuth 授权 URL 中正确编码 redirect_uri 和其他 URL 参数,防止认证失败。
国际化 URL
编码和解码包含中文、日文、韩文、阿拉伯文或其他非 ASCII 字符的 URL,用于国际化 Web 应用。
营销链接分析
解码来自电子邮件营销活动和广告平台的跟踪 URL,了解嵌入的 UTM 参数和重定向链。
URL 结构检查
将复杂 URL 解析为组件部分——协议、主机、端口、路径、查询参数和片段——用于分析和修改。

技术细节

RFC 3986 保留字符与非保留字符
RFC 3986 定义了永远不需要编码的非保留字符(A-Z、a-z、0-9、-、.、_、~),以及充当 URI 分隔符的保留字符(:、/、?、#、[、]、@、!、$、&、'、(、)、*、+、,、;、=),后者在用作数据时必须百分号编码。
UTF-8 字节编码流程
非 ASCII 字符首先转换为 Unicode 码点,然后编码为 UTF-8 字节(根据码点范围为 1-4 个字节),最后每个字节百分号编码为 %XX。例如:é(U+00E9)→ UTF-8 字节 C3 A9 → %C3%A9。emoji 🎉(U+1F389)→ UTF-8 字节 F0 9F 8E 89 → %F0%9F%8E%89。
URL 与 URI 术语
URI(统一资源标识符)是任何标识符字符串的通用术语。URL(统一资源定位符)是一种同时指定访问机制(如 https://)的 URI。RFC 3986 中的编码规则适用于所有 URI。JavaScript 的 API 使用 URI 术语(encodeURI、decodeURI),而日常用语更偏向使用 URL。

最佳实践

根据场景选择正确的模式
对单个查询参数的键和值使用 encodeURIComponent()。仅在有完整 URL 且想编码不安全字符而不破坏结构时使用 encodeURI()。对可能包含 &、= 或其他保留字符的参数值,绝不使用 encodeURI()。
避免双重编码
编码字符串之前,检查它是否已经被编码。查找现有的 % 序列。编码已编码的字符串会将 %20 变成 %2520,%3D 变成 %253D 等。如果不确定,先解码一次,再编码一次。
在服务器端解码
大多数 Web 框架在应用代码看到参数之前会自动解码 URL 参数。避免手动解码框架已经解码的参数——如果原始值包含字面百分号序列,这可能会导致问题。
为 OAuth 和 API 签名编码值
OAuth 1.0 签名基础字符串和许多 API 签名算法要求严格的 RFC 3986 百分号编码。使用 encodeURIComponent() 然后替换它未编码的剩余字符(如 !、'、(、)、*)为百分号编码等价物。

常见问题

什么是 URL 编码?为什么需要 URL 编码?
URL 编码,也称为百分号编码,是 RFC 3986 中定义的一种机制,用于表示 URI 中不允许出现或具有特殊含义的字符。URL 只能包含 US-ASCII 字符集中的有限字符——字母(A-Z、a-z)、数字(0-9)以及少数特殊字符如连字符、下划线、句点和波浪号。任何不在此安全集合中的字符必须编码为百分号(%)后跟两个十六进制数字,表示该字符的字节值。例如,空格变成 %20,斜杠变成 %2F,& 号变成 %26。这种编码是必要的,因为 &、=、? 和 # 等字符在 URL 中具有特殊的结构含义——它们用于分隔查询参数、片段和其他组件。如果不编码,参数值中的 & 会被误解为参数分隔符,导致 URL 结构被破坏。URL 编码确保数据能完整通过 HTTP 基础设施传输,无论其中包含什么字符。
encodeURI 和 encodeURIComponent 有什么区别?
这两个 JavaScript 函数用途不同,编码的字符集也不同。理解何时使用哪个对于避免 URL 错误至关重要。encodeURI() 用于编码完整的 URI,它保留 URL 中具有结构含义的字符——冒号(:)、斜杠(/)、问号(?)、井号(#)、& 号和等号(=)——因为这些分隔符对 URL 功能必不可少。当你有一个完整的 URL 字符串,只想确保其中的不安全字符(如空格或非 ASCII 文本)被编码而不改变其结构时,使用 encodeURI()。例如,encodeURI('https://example.com/path name') 生成 'https://example.com/path%20name',保留了 :// 和 /。encodeURIComponent() 则更加激进,它编码几乎所有非字母数字字符,包括 :、/、?、#、& 和 =。这使得它成为编码将放入 URL 中的单个值的正确选择——最常见的是查询参数值。如果对包含 & 的参数值使用 encodeURI(),& 会未编码通过,被误解为参数分隔符。encodeURIComponent() 会正确地将其编码为 %26。经验法则:对参数键和值使用 encodeURIComponent(),仅在编码完整 URL 且需要保留结构分隔符时使用 encodeURI()。混淆这两者是 Web 应用程序中 URL 相关错误最常见的原因之一。
URL 编码和 HTML 编码一样吗?
不一样,它们是完全不同的编码方案,设计用途也不同。URL 编码(百分号编码)将字符转换为 %XX 十六进制序列,用于 URL 中的安全使用,定义在 RFC 3986 中。HTML 编码(也称 HTML 实体编码)将字符转换为实体引用,如 & 表示 &,< 表示 <," 表示双引号,定义在 HTML 规范中。URL 编码用于 URL 中的数据传输,而 HTML 编码用于在 HTML 文档中安全显示内容。一个常见错误是将 HTML 编码应用于 URL 参数,或反之。例如,在 URL 中将空格编码为   是无效的——必须用 %20 或 +。同样,在 HTML 文本中使用 %3C 代替 < 不会达到预期的转义效果。
为什么我的 URL 在 curl 命令中会出错?
当你将包含特殊字符的 URL 粘贴到 curl 等 shell 命令中时,shell 会在 curl 看到之前就解释 &、?、(、) 和 # 等字符。& 号会告诉 shell 在后台运行前面的命令。问号(?)触发文件名通配。井号(#)开始注释,导致其后的所有内容被忽略。要解决这个问题,始终在 shell 中用单引号包裹 URL:curl 'https://example.com/api?key=value&page=2#section'。单引号可以防止 shell 解释任何特殊字符。也可以用反斜杠转义单个字符,但引用整个 URL 更简单且不易出错。如果 URL 中也包含单引号,请改用双引号并转义其中的美元符号或反引号。
为什么中文字符在 URL 中变成了 %E4%B8%AD 这样的字符串?
中文字符(和所有非 ASCII 字符)首先被转换为 UTF-8 字节表示,然后每个字节进行百分号编码。例如,「中」字的 Unicode 码点是 U+4E2D。在 UTF-8 中,它表示为三个字节:0xE4、0xB8、0xAD。每个字节写成百分号后跟两个十六进制数字,产生 %E4%B8%AD。这个三步过程——字符到 Unicode 码点、码点到 UTF-8 字节、字节到百分号编码十六进制——就是为什么单个中文字符可以在 URL 中扩展为 9 个字符(%XX%XX%XX)。同样的原理也适用于 emoji,它们通常需要 4 个 UTF-8 字节,因此在百分号编码时变成 12 个字符。解码时反过来:十六进制值转换回字节,字节解释为 UTF-8,恢复原始字符。
OAuth 的 redirect_uri 参数需要编码吗?
绝对需要。OAuth 流程中的 redirect_uri 是一个完整的 URL,作为查询参数值嵌入到另一个 URL 中。如果不编码,重定向 URI 中的特殊字符——尤其是 ?、& 和 =——会被误解为外层 URL 结构的一部分,而非参数值中的字面字符。例如,未编码的 redirect_uri=https://myapp.com/callback?code=abc&state=xyz 会导致授权服务器将 redirect_uri 视为仅 https://myapp.com/callback?code=abc,而 state=xyz 会被解析为外层 URL 的独立参数。正确编码的版本是 redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz。始终在将整个重定向 URI 值插入授权 URL 之前使用 encodeURIComponent()。
Node.js 的 querystring 和 URLSearchParams 有什么区别?
Node.js 提供两个处理查询字符串的 API:旧版 querystring 模块和较新的 URLSearchParams 类(WHATWG URL 标准的一部分)。querystring 模块使用自己的编码逻辑——特别是默认将空格编码为 %20,在数组处理上有一些特殊行为(key=1&key=2 变成 { key: ['1', '2'] })。URLSearchParams 遵循浏览器标准:在 application/x-www-form-urlencoded 格式中将空格编码为 +,通过 getAll() 自动处理重复键,并提供可迭代接口(entries()、keys()、values() 方法)。对于新项目,推荐使用 URLSearchParams,因为它与浏览器行为一致、符合标准,并且在 Node.js 和浏览器中工作方式完全相同。querystring 模块被视为旧版模块,不再积极开发,但出于向后兼容性仍然可用。
如何在 Python、JavaScript 和 Java 中编码 URL?
在 JavaScript 中,使用 encodeURIComponent() 编码参数值,使用 encodeURI() 编码完整 URL。示例:const encoded = encodeURIComponent('hello world'); 生成 'hello%20world'。在 Python 3 中,使用 urllib.parse.quote() 编码路径段,使用 urllib.parse.urlencode() 编码查询参数。示例:from urllib.parse import quote; quote('hello world') 生成 'hello%20world'。对于完整查询字符串:from urllib.parse import urlencode; urlencode({'q': 'hello world'}) 生成 'q=hello+world'。在 Java 中,使用 URLEncoder.encode(value, StandardCharsets.UTF_8) 编码参数值。注意 Java 的 URLEncoder 将空格编码为 +(表单编码),如果需要 RFC 3986 编码,需将 + 替换为 %20。要构建完整的 URI,请使用 java.net.URI 或 Apache HttpClient 的 URIBuilder 类。
URL 编码不编码哪些字符?
RFC 3986 定义了一组「非保留字符」,不需要编码:大写字母 A-Z、小写字母 a-z、数字 0-9、连字符(-)、句点(.)、下划线(_)和波浪号(~)。这 66 个字符可以在 URL 的任何部分中直接出现。此外,「保留字符」——:、/、?、#、[、]、@、!、$、&、'、(、)、*、+、; 和 =——在其指定的结构角色中可以出现,但作为字面数据使用时必须百分号编码。JavaScript 的 encodeURIComponent() 函数编码除 A-Z a-z 0-9 - _ . ~ 和 ! ' ( ) * 之外的所有字符,而 encodeURI() 还额外保留充当 URL 分隔符的保留字符。
空格编码为 + 和 %20 有什么区别?
+ 和 %20 都表示空格字符,但它们来自不同的规范。+ 约定源自 HTML 规范中定义的 application/x-www-form-urlencoded 格式,浏览器提交 HTML 表单时使用该格式。在此格式中,空格编码为 +,而 + 字符本身变成 %2B。%20 编码来自 RFC 3986(URI 语法),其中每个非保留字符都编码为百分号后跟两个十六进制数字。在现代实践中,%20 是通用安全的选择——它在 URL 的所有部分(路径、查询、片段)中都有效。空格的 + 编码仅在使用表单编码的查询字符串中有效。在 URL 路径段中使用 + 会被解释为字面加号,而不是空格。如果不确定,请使用 %20。
URL 编码如何处理 emoji?
Emoji 通过与其他 Unicode 字符相同的 UTF-8 百分号编码过程进行编码,但它们需要更多字节。大多数 emoji 使用 U+1F000 到 U+1FFFF(或更高)范围的码点,在 UTF-8 编码中需要 4 个字节。每个字节都进行百分号编码,因此单个 emoji 字符通常在 URL 中扩展为 12 个字符。例如,火箭 emoji(🚀,U+1F680)在 UTF-8 中编码为字节 F0 9F 9A 80,在 URL 中变成 %F0%9F%9A%80。一些带有肤色修饰符或 ZWJ 序列的 emoji 可能由多个码点组成,编码后可扩展到 30 个以上字符。尽管如此扩展,编码是完全可逆的——解码 %F0%9F%9A%80 正确产生 🚀。
URL 编码可以用于加密或安全吗?
不可以。URL 编码不是加密,不提供任何安全性。它是一种纯机械的、确定性的、完全可逆的转换——任何人都可以立即解码百分号编码的字符串,无需任何密钥或秘密。URL 编码的唯一目的是通过转义在 URL 中具有结构含义的字符,使任意数据在 URL 中安全传输。将 URL 编码视为一种混淆或安全措施是一个危险的误解。URL 中的密码、令牌或个人信息等敏感数据应通过 HTTPS(对整个请求进行 TLS 加密)来保护,而非 URL 编码。此外,URL 经常出现在服务器日志、浏览器历史和 referrer 头中,因此敏感数据通常应放在请求体中而非 URL 中。
URL 的最大长度是多少?
HTTP 规范(RFC 7230)没有定义最大 URL 长度,但在每一层都存在实际限制。大多数现代浏览器支持大约 2,048 个字符的 URL(Internet Explorer 的历史限制),尽管 Chrome 和 Firefox 可以处理超过 100,000 个字符的 URL。Web 服务器有自己的限制:Apache 默认 8,190 字节,Nginx 默认 8,192 字节,IIS 查询字符串限制为 16,384 字节。CDN 和代理可能有更严格的限制。当 URL 编码扩展字符——尤其是非 ASCII 文本——时,看似较短的 URL 可能会迅速接近这些限制。最佳实践是将 URL 长度保持在 2,000 个字符以下以获得最大兼容性。如果需要传输大量数据,请使用 POST 请求的请求体,而不是将所有内容编码到 URL 中。
URL 和 URI 有什么区别?
URI(统一资源标识符)是更广泛的概念——它是标识资源的任何字符串。URL(统一资源定位符)是一种特定类型的 URI,它还通过描述访问机制(协议)和网络位置来提供定位资源的方法。例如,https://example.com/page 既是 URI 也是 URL,因为它标识了一个资源并告诉你如何访问它(通过 HTTPS 在 example.com)。URN(统一资源名称)如 urn:isbn:0451450523 是 URI 但不是 URL——它通过 ISBN 标识了一本书但没有告诉你在哪里找到它。在日常 Web 开发中,URL 和 URI 这两个术语经常互换使用,RFC 3986 中定义的编码规则适用于两者。JavaScript 函数命名为 encodeURI/decodeURI,反映了更广泛的 URI 术语。

Base64 解码与编码工具

编码和格式化

免费在线 Base64 解码编码工具。实时转换,支持中文和 Emoji,100% 浏览器端运行,数据不离开设备,无需注册。

JSON 格式化与验证工具

编码和格式化

在浏览器中即时格式化、验证和美化 JSON。免费在线工具,支持语法验证、错误检测、压缩和一键复制,100% 隐私保护。

进制转换器 — 二进制、十六进制、十进制、八进制互转

转换工具

在线免费进制转换工具,支持二进制、八进制、十进制、十六进制及 2-36 任意进制互转。无需注册,数据不离开浏览器,即时获取结果。

在线压缩 JPEG、PNG、WebP 图片 — 免费批量处理

转换工具

免费在线压缩 JPEG、PNG、WebP 图片,体积缩小高达 80%。浏览器本地处理、图片不上传服务器。支持批量压缩 20 张、质量调节、前后对比预览。无需注册。

长度单位转换器 — 公制、英制、天文单位一键互转

转换工具

1 英寸 = 2.54 厘米,1 英尺 = 0.3048 米,1 英里 = 1.609 千米。支持公制、英制、海里、天文共 16 种长度单位即时互转。免费在线工具,所有计算在浏览器本地完成,数据不离开您的设备。

在线 MD5 哈希生成器与文件校验工具

安全工具

在线生成 MD5、SHA-256、SHA-1、SHA-512 哈希值 — 完全免费,浏览器本地运算,无需注册。支持文本和文件哈希、校验和验证、哈希值对比,一键复制,数据绝不离开您的设备。