excerpt <!-- more --> ## 组成 ![image.png|1000](https://imagehosting4picgo.oss-cn-beijing.aliyuncs.com/imagehosting/fix-dir%2Fpicgo%2Fpicgo-clipboard-images%2F2024%2F08%2F12%2F01-10-54-7b84072f8369bfbafa3228c2c76511dc-202408120110374-6b0cd5.png) ```Java http://nginx.org/en/download.html ``` 视为 协议名 +(主机名 + 端口号)+ 路径 或者 schema://authority+path ![image.png#pic_center|650](https://imagehosting4picgo.oss-cn-beijing.aliyuncs.com/imagehosting/fix-dir%2Fpicgo%2Fpicgo-clipboard-images%2F2024%2F06%2F05%2F22-13-29-3fe38d619d8422e8e489527a231cf2ec-20240605221328-103ab4.png) "://" 就像我做那个设计 excel 上传数据的需求,规定一个比较不常见的符号分割数据便于 splitter 拿内容一样 > URI 的创造者蒂姆·伯纳斯 - 李也曾经私下承认 "://" 并非必要,当初有些 " 过于草率 " 了。 主机名可以是 [域名](域名.md),也可以是 IP 地址 ## Encoding URI 是 ASCII 编码 刚才我们看到了,在 URI 里只能使用 ASCII 码,但如果要在 URI 里使用英语以外的汉语、日语等其他语言该怎么办呢?还有,某些特殊的 URI,会在 path、query 里出现 "@&?" 等起界定符作用的字符,会导致 URI 解析错误,这时又该怎么办呢?所以,URI 引入了编码机制,对于 ASCII 码以外的字符集和特殊字符做一个特殊的操作,把它们转换成与 URI 语义不冲突的形式。这在 RFC 规范里称为 "escape" 和 "unescape",俗称 " 转义 "。URI 转义的规则有点 " 简单粗暴 ",直接把非 ASCII 码或特殊字符转换成十六进制字节值,然后前面再加上一个 "%"。例如,空格被转义成 "%20","?" 被转义成 "%3F"。而中文、日文等则通常使用 UTF-8 编码后再转义,例如 " 银河 " 会被转义成 "%E9%93%B6%E6%B2%B3"。有了这个编码规则后,URI 就更加完美了,可以支持任意的字符集用任何语言来标记资源。不过我们在浏览器的地址栏里通常是不会看到这些转义后的 " 乱码 " 的,这实际上是浏览器一种 " 友好 " 表现,隐藏了 URI 编码后的 " 丑陋一面 ",不信你可以试试下面的这个 URI。 **当然,我理解您想要将** **URL** **中的单词用连字符(****-****)连接起来。这是一种常见的** **URL** **友好化处理方式,通常称为** **"slug"****。我们可以修改函数来实现这一点。** 需要对JSON数据进行URL编码(也称为百分号编码)处理主要有以下几个原因: 1. 特殊字符处理: URL中有许多字符是保留的或有特殊含义的,比如 `&`, `=`, `?`, `/` 等。JSON数据中可能包含这些字符,如果不进行编码,可能会导致URL解析错误。 2. 空格和换行符: JSON数据中的空格、换行符等在URL中是不允许直接使用的。编码可以将这些字符转换为合法的URL字符。 3. 非ASCII字符: 如果JSON数据中包含非ASCII字符(如中文),编码可以确保这些字符被正确传输和解析。 4. 避免歧义: 编码可以避免服务器在解析参数时产生歧义。例如,未编码的JSON中的冒号可能被误解为URL中的端口分隔符。 5. 安全性: 编码可以防止一些基于注入的攻击,因为它会转义潜在的危险字符。 6. 兼容性: 不同的服务器和客户端可能对URL中允许的字符有不同的限制。编码可以提高跨平台兼容性。 在你的具体例子中,JSON数据包含了大量的特殊字符(如 `{}`, `"`, `:` 等),这些都需要被编码以确保它们能作为一个完整的参数值被正确传递和解析。 虽然对于小型的、简单的数据,直接在URL中传递未编码的数据可能也能工作,但对于复杂的JSON数据,编码处理是一个更安全、更可靠的做法。这也是为什么在之前的回答中,我建议使用POST请求,将JSON数据放在请求体中,而不是直接放在URL中,因为这样可以避免URL长度限制,并且更适合传输大量复杂数据。an