URL 编码 vs Base64 编码：什么时候该用哪一个
对比 URL 编码和 Base64 编码在查询参数、API payload、token 调试和浏览器检查中的适用场景，说明什么时候使用 URL Encoder，什么时候使用 Base64 Encoder，帮助你在发送数据前选择正确编码方式，避免把编码误当成加密，并减少 API 请求和回调 URL 的格式错误。
URL 编码和 Base64 经常被混用，因为它们都会把一段内容变成“看起来更安全”的字符串。但它们解决的问题完全不同。URL 编码解决的是“这个值能不能安全放进 URL”；Base64 解决的是“这个二进制或结构化内容能不能放进文本字段”。两者都不是加密。
判断时不要从字符外观出发，而要从数据的下一个位置出发：它要进入 query string、path、JSON body、HTML、token，还是日志字段？位置不同，规则就不同。
先看数据会进入 URL 还是字段值
如果值会进入 URL，例如搜索参数、callback URL、redirect 参数或 UTM 字段，优先使用 URL Encoder。URL 里 &、=、?、#、空格和斜杠都有结构含义，不编码可能会把一个值拆成多个参数。
如果值会进入 JSON body 的某个字段，并且接口文档明确要求 Base64，才使用 Base64 Encoder。比如某些接口要求把证书、小图片、二进制片段或复杂 payload 作为 Base64 文本传输。没有文档要求时，不要因为“特殊字符很多”就自动 Base64。
按接收位置选择编码方式
- 放进 URL 参数：URL 编码。
- 放进 HTML 显示：根据上下文使用 HTML Encoder，而不是 URL 编码或 Base64。
- 放进 JSON 字段：先看接口文档，普通文本通常直接作为 JSON 字符串即可。
- 承载二进制或证书内容：Base64 可能合适，但要确认标准 Base64 还是 URL-safe Base64。
- JWT header/payload：它们使用 Base64URL，更适合用 JWT Decoder 查看完整 token。
这个判断顺序比“看到乱码就换编码”更可靠。编码错误通常不是工具问题，而是你把一个上下文的规则用到了另一个上下文。
特殊字符不等于需要 Base64
一个包含中文、空格、斜杠或等号的值，不一定要 Base64。只要它是 URL 参数，URL 编码就更合适；只要它是 JSON 字符串，JSON 转义规则就够了。Base64 会让内容更难人工排查，还会让长度增加。
反过来，Base64 字符串如果要放进 URL，也可能还要再 URL 编码。普通 Base64 的 + 在某些表单编码语境里会被当作空格，/ 可能影响 path，= 可能被错误处理。很多“服务端解不开”的问题，根源是 Base64 结果进入 URL 后没有再按 URL 规则处理。
编码前先判断是否该暴露
URL 编码和 Base64 都不能保护隐私。不要把密码、长期 API key、refresh token、客户信息或内部地址靠编码“隐藏”。如果这类值必须传输，应依赖 HTTPS、短期令牌、服务端鉴权、签名或加密。
调试时建议先用假值做同样格式的测试。例如把真实 callback 参数换成 user=demo&id=123，把真实证书换成短样本，确认编码层级正确后再处理受控数据。
FAQ
Base64 比 URL 编码更安全吗？
不是。Base64 和 URL 编码解决的是传输问题，不是安全问题。任何看到 Base64 值的人都可以解码它。
Base64 字符串还需要 URL 编码吗？
有时需要。如果 Base64 值要放进 URL，加号、斜杠和等号等字符可能需要再做 URL 编码。
查询参数应该用哪种编码？
查询参数应该使用 URL 编码。它专门用于避免空格、&、= 等保留字符破坏 URL 结构。
API payload 字段应该用哪种编码？
以 API 文档为准。只有当 API 明确要求 Base64 文本时才使用 Base64，否则应发送普通 JSON 或文档指定的字段格式。