编码、加密与哈希怎么选

4 个决策要点 · 涉及 21 款工具 · 编码 / 加密 / 哈希 · 内容最后核对 2026-10-25

这三件事经常被混为一谈，但选错一类就意味着「你以为加密了，其实什么都没保护」。

一句话结论

先问「要不要还原」和「要不要保密」：能还原不保密=编码，能还原要保密=加密，不能还原=哈希。Base64 是编码，不是加密。

「帮我加密一下这段文字」——这句话背后可能是三种完全不同的需求，而它们对应的工具在安全级别上差着十万八千里。Base64 经常被当成加密用，但它连一丁点保密性都没有：任何人拿到结果都能一键还原，因为它压根不需要密钥。把它当加密，等于把保险箱的钥匙插在锁上还贴了张「钥匙在此」的纸条。

要选对工具，先分清三件事的本质。编码（Encoding）：可逆、无密钥，目的是把数据变成另一种「安全的表示形式」，方便在网络里传输——它不提供任何保密性。加密（Encryption）：可逆、有密钥，只有拿到密钥的人才能还原，这才是真正的保密。哈希（Hashing）：不可逆、无密钥，把任意长度的数据压成固定长度的指纹，用来做校验或存密码。判断你该用哪一类，问自己一个问题：我需要还原回来吗？需要且不必保密 → 编码；需要且必须保密 → 加密；不需要还原 → 哈希。

选型对照表

看逐项详解 →

你要做的事	推荐工具	类别	注意
把二进制嵌进文本（如把图片写进 HTML）	Base64编码/解码	编码	体积会膨胀约 33%，不是压缩
在 URL 里安全传递中文或特殊字符	URL编码	编码	编码的是「参数值」而不是整个 URL
解析一段 URL，看它到底带了什么参数	URL 参数解析器	编码	注意区分查询串与路径部分
把 HTML 里的尖括号转成实体	HTML实体编码	编码	防止把用户输入当成标签解析
把 HTML 实体还原成原始字符	HTML实体编码/解码	编码	与上面成对使用，方向相反
处理混在一起的转义与实体	HTML转义处理	编码	适合清洗抓取来的网页文本
在 Base64 和十六进制之间来回转	Base64互转/Hex	编码	Hex 体积是 Base64 的两倍
把文件与 Base64 互转	Base64文件互转	编码	大文件会导致文本体积过大
把图片与 Base64 互转	图片Base64互转	编码	适合做内联小图标，大图不划算
处理 \u4e2d 这类转义序列	Unicode编码/解码	编码	注意区分「转义序列」与「UTF-8 字节」
修中文被错误解码产生的乱码	UTF-8 与中文互转	编码	只能修「UTF-8 被当 GBK 读」这类错配
自动识别并修复乱码	乱码修复工具	编码	先判断原始编码是否可推断
压缩数据以减少体积	Gzip编码/解码	编码	这是压缩不是加密，可逆
把文本编成摩尔斯电码	Morse电码	编码	仅用于趣味与通信练习
在不知道密钥的情况下查看 JWT 内容	JWT 解析与验证	编码	JWT 的 payload 只是 Base64URL，不是密文
对称加密（同一把钥匙加解密），如保护文件	AES加密/解密	加密	密钥强度决定安全，别用弱口令当密钥
非对称加密（公钥加密、私钥解密）	RSA加密解密	加密	RSA 很慢且有长度限制，适合加密密钥而非大文件
解析 SSL/TLS 证书的域名与有效期	SSL证书信息解析器	运维	证书内容本就是公开的，无需密钥
计算文本的哈希指纹	Hash生成器	哈希	不可逆，不能用于还原原文
校验文件有没有被改动	文件哈希校验	哈希	MD5 已不适合对抗人为篡改
生成 Apache 的 .htpasswd 密码行	.htpasswd生成器	哈希	必须用 bcrypt / APR1，别用明文

表格中列出的工具均可直接点击进入，全部免费、无需注册。

逐项详解

全部工具总览 →

1编码：可逆、无密钥，只负责「表示形式」

编码的唯一目的是让数据能在原本吃不消的通道里安全通过。URL 里不能直接放空格和中文，所以要先 URL 编码成 %E4%B8%AD 这样的形式；HTML 正文里不能直接写尖括号，所以要先转成实体；纯文本协议（如邮件、JSON 字符串）里不方便放二进制，所以要先 Base64。这类操作全部公开可逆、不涉及任何密钥——谁都能还原，这正是它们的设计目标。把 Base64 结果当成加密的人，往往是在「看起来是一串乱码」这一点上被误导了：乱码感不等于保密。

Base64编码/解码 URL编码 HTML实体编码 Unicode编码/解码 Gzip编码/解码

2加密：分对称与非对称两条路

对称加密（AES 是典型）加解密用同一把密钥，速度快、适合处理大量数据，问题是「怎么安全地把密钥交给对方」。非对称加密（RSA 是典型）用一对密钥：公钥可以随便公开，用它加密的内容只有私钥能解开，反过来用私钥签名的内容公钥可以验证来源。它解决了密钥分发难题，但运算慢、且有单次加密长度上限。所以工程上的标准做法是两者配合：用非对称加密传递一把临时对称密钥，之后的数据都用对称加密传——这就是 HTTPS 握手的核心思路。

AES加密/解密 RSA加密解密 SSL证书信息解析器

3被误读最多的一个：JWT

JSON Web Token 由三段用点号连接：头部、载荷、签名。很多人以为载荷经过「加密」所以别人看不到——恰恰相反，载荷只是 Base64URL 编码，任何人粘贴出来就能读到里面的用户 ID、角色、过期时间。JWT 真正保证的是「防篡改」：服务端用密钥验证签名，一旦载荷被改动，签名就对不上。所以 JWT 里绝不能放密码、身份证号之类的敏感信息，它解决的是「我怎么知道这个声明没被改过」，不是「我怎么让别人看不到这个声明」。

JWT 解析与验证 Base64编码/解码

4哈希：同一条路走不通两次

哈希把任意长度的输入压成固定长度的指纹，且有两个关键性质：不可逆（无法从指纹推回原文）和抗碰撞（很难找到两个不同输入产生同一指纹）。这正是它在密码存储与完整性校验上不可替代的原因——数据库里只存密码的哈希，即使被拖库，攻击者也拿不到明文。但要注意两点：一是 MD5 和 SHA-1 已经被证明能构造碰撞，用于对抗人为篡改已不安全，涉密场景请用 SHA-256 及以上；二是存储密码不能直接哈希，因为相同密码会产生相同哈希，会被彩虹表批量破解，必须加盐并采用慢哈希算法（bcrypt、scrypt、argon2），这也是为什么 Apache 的 .htpasswd 默认用 bcrypt 而不是 MD5。

Hash生成器文件哈希校验 .htpasswd生成器

关于「编码、加密与哈希怎么选」的常见问题

Base64 到底算不算加密？

不算。Base64 是纯粹的编码，不需要任何密钥，任何人拿到结果都能一键还原。它的用途是让二进制数据能安全地在只支持文本的通道里传输，顺便让内容变得「不容易一眼看懂」，但这与保密无关。需要保密请用 AES 等加密算法，并且妥善保管密钥。

AES 和 RSA 该选哪个？

看数据量和密钥分发条件。AES 是对称加密，加解密用同一把钥匙，速度快，适合加密大量数据；RSA 是非对称加密，用公钥加密、私钥解密，解决了「怎么安全地把钥匙给对方」的难题，但速度慢且有单次加密长度限制。工程上的标准做法是两者结合：用 RSA 传递一次性的 AES 密钥，之后的数据全部用 AES 加密。