URL 编解码

URL 为什么需要编码

URL 里只能出现有限的一部分 ASCII 字符。空格、中文、`&`、`#`、`%`、`+` 以及非拉丁字母, 都必须先转成 `%XX` 形式的转义序列, 才能安全地经过浏览器、服务器与代理。这个工具负责正反两个方向的转换。

component 模式 vs 整条 URI 模式

• component(查询值) —— 把会破坏取值的字符全部转义: 空格变 `%20`, `&` 变 `%26`, `/` 变 `%2F`。把值放进查询串或表单字段时用这个。
• 整条 URI —— 保留 URL 结构(`/`、`?`、`&`、`=`、`#` 仍可读), 只转义真正非法的字符。用来展示或记录整条链接。

模式选错是"我这儿能打开、服务器却 404"的头号原因: component 模式会把嵌套链接里的 `/` 和 `?` 也转义掉。

常见任务

• 修好含空格的链接(`my file.pdf` → `my%20file.pdf`)
• 看懂从开发者工具里复制的乱码跳转链接
• 手写一个查询参数
• 解开统计/跳转链接, 看清里面是什么

说明

• 输入不合法时(单独一个 `%`)解码会明确报错, 这通常意味着内容被二次编码了
• `+` 只有在表单编码里代表空格, 路径里不是。处理 `application/x-www-form-urlencoded` 时要注意
• 不上传任何内容, 转换在浏览器里完成

FAQ

该用 component 还是整条 URI?

放进查询串或表单的值用 component; 想让整条链接保持可读就用整条 URI。

为什么编码后链接打不开?

基本都是模式问题: component 把嵌套 URL 的 / 和 ? 也转义了。改用整条 URI 模式, 或只对取值部分编码。

中文能处理吗?

可以。非 ASCII 字符会先按 UTF-8 编码再转义, 这是现代服务器的标准做法。