前端

一个典型的坏链接 你拼了一个搜索链接，英文下一切正常，用户一输入中文就崩： https://example.com/search?q=书签管理 & page=2 服务器收到的 q 是 书签管理 ，还多了一个叫 page 的参数——本该属于查询值的 & 被当成了分隔符。#、=、?、+ 和空格也有同样的问题。 解决办法是百分号编码（URL 编码）：把不安全字符替换成 % 加两个十六进制数字，表示它的 UTF-8 字节。 书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86 & → %26 空格 → %20 哪些字符是安全的 RFC 3986 把字符分成"未保留"和"保留"两类，只有未保留字符可以原样出现： 类别 字符 说明 未保留 A–Z a–z 0–9 - _ . ~ 任何位置都安全 保留（结构类） : / ? # [ ] @ 在 URL 中有结构含义 保留（子分隔符） ! $ & ' ( ) * + , ; = 在查询串中有含义 其他 空格、"、<、>、%、{}、中文… 必须编码 保留字符不是"不能用"，而是"有含义"。关键问题永远是：这个 & 是想表达结构，还是想表达数据？如果是数据，就编码它。 ...

Base64 要解决什么问题 很多系统只传"文本"：邮件协议为 7 位 ASCII 设计，JSON 定义为文本，HTML 属性里放的是字符串。但我们真正想传输的东西——图片、PDF、密钥、二进制协议数据——是字节流，里面很容易混进控制字符、引号和换行。 把原始二进制直接塞进文本通道，迟早会出问题：换行被改写、引号提前结束字符串、代理服务器吃掉一个字节。Base64 的做法是：只用 64 个所有文本系统都认的字符重新表示这些字节。 A–Z a–z 0–9 + / 末尾的 = 只用于补齐。整个字母表就这些。 Base64 的原理 Base64 每处理 3 个字节（24 位），就把它们重写成 4 个字符（4 × 6 位）： 输入 位数 输出 Man 24 位 TWFu Ma 16 位 + 补齐 TWE= M 8 位 + 补齐 TQ== 由此直接得到两个结论： 结果大约比原文大 33%（3 个字节变成 4 个字符）； = 的数量告诉解码器最后一组缺了几字节，一个或两个 = 表示末尾不完整。 Base64 是可逆的、完全公开的编码，没有密钥，也没有任何保密性。 日常开发中在哪里遇到 Base64 Data URI：background-image: url(data:image/png;base64,...) 把小图标直接内嵌进 CSS。 JSON 接口：在 JSON 字段里传文件、缩略图或签名。 邮件附件：MIME 用 Base64 编码附件，让它们能穿过只支持文本的邮件服务器。 HTTP Basic 认证：Authorization: Basic dXNlcjpwYXNz 就是 user:pass 的编码结果。 JWT：Token 的 header 和 payload 两段都是 Base64URL 字符串。 Base64 不是加密 这是最重要的一点：Base64 不提供任何保密性。 ...