实用文本编码往返演示

理解 Base64、URL 编码和 HTML 实体：不要把它们当成加密

让文本通过数据格式、URL 和 HTML 时保持原意的实用方法：明确每种编码解决什么问题，也明确它们不解决什么问题。

MV Tools 编辑团队更新于 2026-09-06约 8 分钟阅读

打开工具

先看目标位置，而不是只看“编码”二字

Base64、百分号编码和 HTML 实体解决的是不同的表示问题。它们不会加密消息、证明发布者身份、验证输入，也不会让一个值在所有上下文中都安全。先确认该值最终由哪里读取：字节字段、URL 的一个组成部分，还是作为文本显示的 HTML。

在接收系统正确接受并显示转换结果前保留原值。字符串转换后即使语法有效，也可能因为在错误层级编码或重复编码而不符合目标用途。

在浏览器中将 Unicode 文本编码为 Base64。 — Base64 改变 UTF-8 字节的表示形式，不会隐藏源文本。

Base64 用于把字节表示为文本，不用于保密

Base64 将字节映射为有限的 ASCII 字符集。此工具先把 Unicode 输入转为 UTF-8 字节，再编码为 Base64；有效的 UTF-8 Base64 可按相反方向解码。当纯文本格式需要承载字节序列时它很有用，但通常会增加体积，而且任何拿到该值的人都很容易还原。

不要把凭据、个人信息或访问令牌转成 Base64 后就认为它们受到了保护。应使用目标系统要求的加密和访问控制机制。需要互操作时，保留接收方要求的完整值和填充符；标准 Base64 与 URL 安全 Base64 并非总能互换。

将 Base64 值解码回原始文本。 — 往返测试只确认表示一致，不代表保密或授权。

先编码 URL 组件，再拼接 URL

搜索词等查询参数值可能包含空格、&、=、Unicode 或百分号。应先把这个值作为组件编码，再拼入查询字符串，这样值中的 `&` 或 `=` 不会变成 URL 结构。例如先编码值，再把它放在 `?q=` 后面；不要对已经完整的 URL 使用组件编码。

只有明确要保留 `://`、`?`、`&`、`=`、`#` 等分隔符时才使用完整 URL 编码。不要盲目解码整条 URL，更不要重复解码：一次解码后，已转义的百分号可能变成新的转义序列。可优先使用框架或 URL API 构造参数，并用含空格、非 ASCII 文字、`&`、`=`、`%` 的样例测试。