本文目录
理解 URL 结构
URL（统一资源定位符）是网络上某个资源的地址。每个 URL 都遵循一种结构化格式，告诉浏览器要去往何处以及如何到达。理解这一结构对于 Web 开发者、SEO 专家，以及任何与 Web API 打交道的人来说都至关重要。
一个完整的 URL 最多可以包含七个不同的组成部分：协议（scheme）、用户名和密码（身份验证）、主机（域名）、端口、路径、查询字符串以及片段（hash）。大多数 URL 只用到其中几个，但了解全部这些部分有助于你调试复杂的 URL 并正确地构建它们。
URL 解析的工作原理
URL 解析会根据 RFC 3986 将一个 URL 字符串拆分为各个独立的组成部分。每个部分对于允许使用哪些字符以及它们的含义都有特定的规则。
- 协议（scheme）——用于访问资源的方法：http、https、ftp、mailto，或诸如 myapp:// 之类的自定义协议
- 主机（Host）——服务器的域名或 IP 地址。可以包含子域名（api.example.com），也可以是 IPv4/IPv6 地址
- 路径（Path）——服务器上资源的具体位置。各段由正斜杠分隔，并且可能包含经过编码的字符
免费试用 —— 无需注册
解析 URL →处理查询参数
查询参数是附加在 URL 问号（?）之后的键值对。它们是在 GET 请求中传递数据的最常见方式，被大量用于 API、分析追踪和搜索功能中。
- 基本格式——参数使用 key=value 键值对，各对之间以「和」号分隔：?page=2&sort=name&order=asc
- URL 编码——特殊字符必须进行百分号编码：空格会变成 %20 或 +，值中的「和」号会变成 %26
- 数组参数——有些 API 使用重复的键（color=red&color=blue）或方括号表示法（color[]=red&color[]=blue）来表示数组
- 空值与缺失值——在许多服务器框架中，?key=（空字符串）与 ?key（无值）是有区别的
- 参数顺序——从技术上讲 URL 参数是无序的，但有些 API 会依赖顺序来进行缓存或签名校验
URL 调试技巧
乍看之下正确的 URL 可能隐藏着微妙的编码问题、缺失的组成部分或意料之外的字符。以下技巧能帮你快速发现常见问题。
- 阅读前务必先解码——经过百分号编码的 URL 很难阅读。先解码，才能看到实际发送的值
- 检查是否存在双重编码——%2520 意味着百分号本身被编码了（%25 = %），这表明该 URL 被编码了两次
- 留意尾部斜杠——/api/users 和 /api/users/ 可能会因服务器配置不同而被路由到不同的位置
- 检查片段——hash 片段（#section）绝不会被发送到服务器。如果你的服务端代码需要用到它，就必须采用另一种方式
- 校验主机——域名中的拼写错误很常见。检查是否缺少点号、字符是否颠倒，或顶级域名（TLD）是否错误
常见问题
URL、URI 和 URN 有什么区别？
URI（统一资源标识符）是对任何资源标识符的统称。URL（统一资源定位符）是一种包含位置和访问方法的 URI——它告诉你在何处（WHERE）以及如何（HOW）访问该资源。URN（统一资源名称）则是一种为资源命名而不指定其位置的 URI。在实践中，大多数人会将 URL 和 URI 混用，因为网络上几乎所有的 URI 都是 URL。
为什么有些 URL 字符会用百分号编码？
URL 编码（百分号编码）会将那些在 URL 中具有特殊含义或不被允许的字符转换为一种安全的格式。例如，空格会变成 %20，因为空格在 URL 中是无效的。「和」号（&）用于分隔查询参数，因此值中出现的字面「和」号必须编码为 %26。如果不进行编码，URL 解析器就会错误地理解其结构。
URL 可以有多长？
HTTP 规范中并没有官方的长度上限。不过，大多数浏览器支持长度约 2,048 个字符的 URL（这是 Internet Explorer 历史上的上限）。像 Chrome 这样的现代浏览器最多可支持 2MB。服务端的限制则各不相同——Apache 默认为 8,190 字节，Nginx 为 8KB。为获得最大的兼容性，请将 URL 控制在 2,000 个字符以内，并对大量数据负载使用 POST 请求。