URL / Base64 编解码

URL 编码与 Base64，各自解决什么问题

这两件事经常被混为一谈，其实解决的是完全不同的问题。 URL 编码（百分号编码）的目的是让一段文本能安全地放进 URL 里。 :、/、?、&、=、# 这些字符在 URL 里有结构含义，一旦出现在数据中就必须写成 %XX 形式： 空格在路径里是 %20，在表单编码的查询串里也可以写成 +。

encodeURI 与 encodeURIComponent 的区别值得记住： 前者保留 URL 的结构字符，用于编码一整条 URL； 后者把保留字符一并编码，用于编码单个查询参数的值。 用错这两个函数，是「链接只在特定输入下失效」最常见的原因。

Base64 与 URL 无关：它把任意字节用 64 个可打印字符表示， 让二进制数据能穿过只接受文本的通道——JSON 报文、邮件、data URI、Basic 认证头。 代价是体积膨胀约 33%，而且它只是编码，不是加密：任何人都能无需密钥地还原， 绝不能用来保护数据。

标准 Base64 使用 + 和 /，而这两个字符在 URL 里另有含义， 于是有了 URL 安全 Base64：用 - 和 _ 替代，并去掉尾部补位的 =， 这样结果可以直接放进网址、令牌与 JWT 中而不会被改写。

最后再强调一次编码、哈希与加密的分工：编码可逆、不需要密钥，用于「换个写法」； 哈希不可逆、定长，用于校验与指纹；加密可逆但需要密钥，用于保密。 需要保密时，编码和哈希都不是答案。 本工具四种模式都在浏览器本地完成，中文与 Emoji 按 UTF-8 处理，输入内容不会上传。

还有两个实践细节。其一是中文与 Emoji：它们必须先按 UTF-8 编码成字节再做 Base64， 否则还原时会乱码；本站已统一按 UTF-8 处理，因此与其他语言的实现结果一致。 其二是什么时候不该用 Base64：把大文件塞进 JSON 会让体积膨胀约三分之一， 还要多付一次编码解码的开销，二进制内容应当走 multipart 上传或对象存储， JSON 里只放一个 URL。反过来，内嵌几 KB 的图标用 data URI 则完全合理。