文本 SHA 系列

如何使用文本 SHA 系列

关于文本 SHA 系列的常见问题

文本 SHA256 在线计算会上传我的内容吗？

不会。文本 SHA 全程在你的浏览器本地完成，粘贴的文字、盐和算出的摘要都不会上传到任何服务器。这一点对本工具格外重要，因为往这里粘的常常就是接口签名的密钥、token、订单号或身份证号：本页只把算法勾选、输出写法、编码、加盐位置这几项参数偏好写进本机 localStorage，原文、盐、期望值与结果一律不落盘，也绝不会把参数同步到网址里（那等于把密钥写进浏览器历史与 Referer）。想自证就打开 F12 的网络面板再算一次：计算过程零请求，断网照样出结果（页面本身会加载一个访问统计脚本，它不读取也不上报你粘贴的内容）。

SHA256 加密后能解密还原成原文吗？

不能，本页也不提供任何反查入口。严格说 SHA 不是加密而是单向摘要：不管原文多长，SHA-256 的输出固定是 256 位，信息在压缩过程中已经丢掉，数学上不可能还原。网上所谓「SHA256 解密」都是查彩虹表，也就是拿库里预先存过的常见明文比对——123456 这种能查到，换成一句没人存过的话就查不到，所以它既不通用也不是真的解密。要验证一段文本对不对，正确做法是把它算一遍 SHA 再和已有的值比对，本页的「期望值比对」做的就是这件事。

SHA-1、SHA-256、SHA-512 有什么区别？

它们是同一族里摘要长度不同的三个算法：SHA-1 输出 160 位、写成 40 个十六进制字符，SHA-256 是 256 位、64 个字符，SHA-512 是 512 位、128 个字符，长度越长碰撞越难。SHA-1 已经在 2017 年被 SHAttered 实用地构造出碰撞（两份内容不同的 PDF 拿到同一个 SHA-1），2020 年又实现了选择前缀碰撞，所以不要再用于数字签名与证书；SHA-256 是当前的默认选择，SHA-512 更长，在 64 位环境里也很常见。本页默认把这三个一次算全，省得你为了对一个值来回切算法。

SHA-2 和 SHA256 是同一个算法吗？

SHA-2 是一族算法的总称，SHA-256 是这一族里最常用的那一个，所以接口文档里写「SHA2」而没说位数时，绝大多数情况指的就是 SHA-256，对不上再问对方要位数。这一族的成员是 SHA-224、SHA-256、SHA-384、SHA-512（另有 SHA-512/224 与 SHA-512/256 两个截断变体），共用同一份规范 FIPS 180-4，彼此的区别只在摘要长度与内部运算字长，本页给出其中最常用的五个。真正要分清的是 SHA-3：它是 2015 年才定稿的另一套算法，内部是完全不同的 Keccak 海绵构造，不是「更新版的 SHA-2」，同一段文字用两者算出的值毫无关系，本页不提供 SHA-3，看到对方要 SHA3-256 就不要拿这里的 SHA-256 去交差。

SHA256 会不会算出重复值，碰撞概率多大？

理论上会，实际上碰不到。SHA-256 一共有 2 的 256 次方个可能的输出，而输入是无限的，所以两段不同的文本共用一个摘要（碰撞）在数学上必然存在；但按生日界估算，要让碰撞概率达到一半，需要试大约 2 的 128 次方次，这个量级超出了现实算力，截至目前也没有公开的 SHA-256 碰撞实例。所以拿 SHA-256 做去重 key、文件指纹、缓存标识是稳妥的。要区别对待的是 SHA-1：它的碰撞在 2017 年已经被 SHAttered 实际构造出来（两份内容不同的 PDF 拿到同一个 SHA-1），2020 年又出现成本更低的选择前缀碰撞，凡是依赖「难以伪造」的用途都不要再用它。顺带说一句，日常遇到的「两条数据摘要一样」几乎都不是碰撞，而是两条数据本来就一字不差，或者其中一条根本是空的（空串的 SHA-256 恒等于 e3b0c442 开头那一串）。

为什么我算的中文 SHA256 和别人不一样？

SHA 吃的是字节不是字符，中文取字节的编码不同，算出来的摘要就不同。同样一句「你好」，UTF-8 下是 6 个字节，SHA-256 是 670d9743542cae3ea7ebe36af56bd53648b0a1126162e78d81a32934a711302e；GBK 下是 4 个字节（c4 e3 ba c3），SHA-256 是 6b5b97ebb913939e7f50ee8ce76ab9542af504a77485f63e7e0805d728322075——两个都对，只是取字节的口径不同。把本页的编码开关切成和对方一致即可对上；如果切了还是不同，再依次检查末尾换行、首尾空格和加盐顺序。

SHA256 结果的 hex 和 Base64 怎么互相换？

它们是同一个摘要的两种写法，不需要「换算」，本页两种一起给。关键点是 Base64 编的是摘要的 32 个原始字节，不是那串 64 位十六进制文本——把 hex 当字符串去 Base64 会得到一个 88 字符的串，那是错的。以「小鹿tools」为例，hex 是 55b93f1f2e35e710c362e3e192c4610c24bb7652b0fa6e28198643223b74bf06，正确的 Base64 是 Vbk/Hy415xDDYuPhksRhDCS7dlKw+m4oGYZDIjt0vwY=，共 44 个字符。命令行里 sha256sum 给 hex，openssl dgst -sha256 -binary 再管道给 base64 得到的就是后者；网页 SRI 的 integrity="sha384-…" 用的也是 Base64。注意 JWT 签名段用的是 Base64URL：字母表与标准 Base64 只差加号、斜杠、等号这三个字符（换成减号下划线、去掉等号补齐），但摘要里只要出现过加号或斜杠，两串写出来就对不上。

网页 SRI 的 integrity 值怎么用 SHA256 生成？

integrity 的值就是「算法名 + 短横线 + 标准 Base64」，例如 integrity="sha256-Vbk/Hy415xDDYuPhksRhDCS7dlKw+m4oGYZDIjt0vwY="，短横线后面那串正是本页 SHA-256 结果卡的第三行，末尾的等号补齐要保留，别手抖删掉。要注意 SRI 校验的是被引用文件的原始字节：给 js、css 文件生成 integrity 请到「文件 MD5/SHA 校验」那页直接喂文件，把文件内容复制进文本框再算往往对不上，CRLF 与 LF 换行、末尾多一个空行都会让摘要变样。本页更适合另外两件事：核对别人给的 sha256- 值格式对不对（整串粘进「期望值比对」框即可，本页认这个形态，会剥掉前缀按 Base64 比），以及给 CSP 的 script-src "sha256-…" 算内联脚本的摘要——那一处算的恰好就是标签里的那段文本，一个字符不差。

SHA-224 是 SHA-256 的前 56 位截出来的吗？

不是。SHA-224 与 SHA-256 用的是完全不同的初始向量，只是最后再截断输出，所以两者的结果毫无关系。空字符串就能当场验证：SHA-224 是 d14a028c2a3a2bc9476102bb288234c415a2b01f828ea62ac5b3e42f，SHA-256 是 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855，前 4 个字符就分道扬镳了。SHA-384 与 SHA-512 同理。顺带一提，浏览器自带的 crypto.subtle 支持 SHA-1/256/384/512 却没有 SHA-224，而且它只在 HTTPS 或 localhost 这样的安全上下文里存在，所以本页统一用 WASM 实现，五个算法口径一致。

sha256(密钥+内容) 能当 HMAC 用吗？

不能等同，两者结果完全不同。HMAC-SHA256 有固定构造：密钥先补齐到分组长度，再分别和 0x36、0x5c 两个常量异或，做两轮哈希；而本页的加盐只是把盐和原文拼成一个字符串再算一次。更要紧的是，自制的 sha256(密钥+内容) 存在长度扩展攻击——攻击者不需要知道密钥，只要拿到一组合法的内容与签名，就能算出「内容+填充+任意追加内容」的合法签名，SHA-1、SHA-256、SHA-512 都是 Merkle–Damgård 构造，都受影响（SHA-224 与 SHA-384 因为只给出被截断的内部状态，同样的手法用不上）。这正是 HMAC 存在的理由。本页只做拼接后计算并如实标注，不提供 HMAC。

批量 SHA256 计算一次最多支持多少行？

批量模式一行一条，单次上限 10000 行、2MB（按所选编码下的字节数计算）。批量只输出一个算法列（默认 SHA-256，可切）——128 个字符的 SHA-512 铺满表格既读不了、CSV 也会大到没法用，要另一个算法就切一次再导一次。结果表只渲染前 500 行，避免上万行一次性塞进页面把手机卡死，但「复制全部」「复制摘要列」和「下载 CSV」拿到的都是全部数据。输入超过 200KB 或 2000 行时会自动关掉「边输入边算」，改成参数调好后点按钮触发；超过上限会明确提示，请拆成几批再算。

算出的 SHA256 和 sha256sum、certutil 一致吗？

一致。SHA-256 的规范只有一套（FIPS 180-4），没有方言实现，差异只可能来自喂进去的字节与大小写写法，本页用 WASM 实现计算，与系统 sha256sum 逐位相同。需要特别注意命令行的一个坑：echo hello | sha256sum 会在文本末尾多算一个换行，得到 5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03，而 printf hello | sha256sum 才是 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824，后者与本页默认口径相同。Windows 的 certutil 给的是大写十六进制，本页结果卡第二行就是；要 Base64 就看第三行。

Python、Java、JS 算出的 SHA256 和这页一致吗？

一致，各语言标准库实现的都是同一套 FIPS 180-4 规范，只要喂进去的字节相同，结果就逐位相同。以本页示例文本「小鹿tools」为例，下面这几种写法算出来都是 55b93f1f2e35e710c362e3e192c4610c24bb7652b0fa6e28198643223b74bf06：Python 用 hashlib.sha256(s.encode("utf-8")).hexdigest()，Node.js 用 crypto.createHash("sha256").update(s, "utf8").digest("hex")，PHP 用 hash("sha256", $s)，Java 用 MessageDigest.getInstance("SHA-256").digest(s.getBytes(StandardCharsets.UTF_8))，Go 用 sha256.Sum256([]byte(s))。对不上的原因永远在字节这一侧：取字节时编码选了 GBK 而不是 UTF-8、文本末尾多了一个换行、或者拿到 byte[] 之后转 hex 那步写错了（Java 侧最经典的坑是用 Integer.toHexString，它会把小于 0x10 的字节吐成一位，结果不足 64 个字符）。正文的「各语言等价写法」一节把每种写法默认给到的形态列成了表。

SHA256 加密还能用来存密码吗？

不建议。SHA 系列的设计目标之一就是快，显卡每秒可以试上百亿次，常见口令几乎瞬间被撞出来；加盐能挡住彩虹表、拖慢批量破解，但改变不了「算得太快」这个根本问题。存密码请改用 bcrypt、scrypt、Argon2 这类刻意放慢、可调工作因子的算法。但也不必一刀切地否定 SHA：拿它做文件指纹、接口签名、缓存 key、数据去重比对，或者写网页 SRI 的 integrity 值，都仍然是合适且推荐的用法，本工具正是为这些场景准备的。

手机上能用文本 SHA256 在线计算吗？

可以。本页是纯网页实现，手机、平板、电脑浏览器打开即用，免安装免注册，算出来的结果和电脑上完全一致。小屏下参数区、输入框与结果区上下堆叠而不是并排，128 个字符的 SHA-512 结果会自动折行显示不会被截断，每个写法都有独立的复制按钮方便直接粘到别处；批量模式的结果表可以横向滚动，页面本身不会横向溢出。

SHA-1/224/256/384/512 是什么关系，该选哪个

SHA 是一族单向摘要算法：不管原文多长，输出都是固定位数的一串值。 SHA-1 出 160 位，SHA-2 家族出 224 / 256 / 384 / 512 位。顺手澄清一个高频误会：SHA-2 不是某一个具体算法，而是这一族的统称，平时说的 SHA256 就是 SHA-2 家族里最常用的那一个，问「SHA2 和 SHA256 有什么区别」等于问 「水果和苹果有什么区别」。它们的规范（FIPS 180-4） 只有一套，所以「算法本身」从来不是分歧点——真正会让两个人算出不同结果的，是 喂进去的字节和写法。下面这张长度对照表是本页最实用的一条速查，也是「64 位的哈希是 什么算法」这类问题的答案：

选哪个：没有特殊要求就用 SHA-256，它是当下的默认；对接老系统、 或者只是要个非安全用途的指纹，SHA-1 仍然能算；要更长的摘要用 SHA-512。本页默认 把 SHA-1 / SHA-256 / SHA-512 一次全给，另外两个按需勾选，省得你为对一个值来回切。 把对方给的摘要粘进「期望值比对」框，本页会先按长度告诉你它像哪个算法，再逐个比对。

还有一条容易踩的环境差异：浏览器自带的 crypto.subtle.digest 支持 SHA-1 / SHA-256 / SHA-384 / SHA-512，但没有 SHA-224，而且 crypto.subtle 只在安全上下文（HTTPS 或 localhost）里存在，普通 http 页面上它直接是 undefined。 为了五个算法口径一致、也不因部署环境不同而「有时能算有时不能」，本页统一用一份 WASM 实现来算。

SHA256 Base64、大写 hex 与小写 hex：同一个摘要的三种写法

摘要本身是一串字节，写到屏幕上才需要选一种写法。同一个 SHA-256 结果，命令行 sha256sum 给你小写十六进制，Windows 的 certutil 给大写，而网页 SRI 的 integrity 属性用的是 Base64——换算不过来，就是「我算的和人家给的对不上」的一大类原因。 本页三种一起给，每种一个独立的复制按钮：要 SHA256 大写值就复制第二行，要 Base64 就复制第三行。

最后一条差别值得单独记：JWT 的签名段用的是 Base64URL，把加号和斜杠 换成了减号和下划线、并去掉末尾的等号补齐——两套字母表就差这三个字符，但只要摘要里 出现过加号或斜杠，同一个值的两种写法看着就不一样。 所以别拿本页的 Base64 直接去对 JWT 的签名——要看 JWT 的结构请用「JWT 解码器」。 本页刻意不提供第四种输出格式，避免开关变成三态。

中文 SHA256 为什么会算出两个值：UTF-8 SHA256 与 GBK SHA256

这是整页最要紧的一条：SHA 吃的是字节，不是字符。英文和数字不会出 问题，因为 ASCII 区各种编码都一样；中文就不同了，同一个字在 UTF-8 和 GBK 下是完全 不同的两串字节，喂给同一个 SHA-256 自然得到两个不同的值——而且两个都对。

所以「中文 SHA256 对不上」这类问题，答案几乎总是：你和对方取字节的编码不一样。 本页把这一步显式化成一个开关，字节数就写在结果旁边，切一下就能对齐。判断对方用的 是哪种也有个土办法：让他算一遍「你好」，出 670d 开头就是 UTF-8，出 6b5b 开头就是 GBK。

本站的 GBK 是从浏览器内置的 gb18030 解码器反推出来的一张反查表，共收录 23939 个字符，覆盖 GB2312 全部汉字、GBK 扩展汉字、日文假名与全角 符号。不覆盖的是 emoji、韩文谚文和 GB18030 四字节区的生僻字（如 𠮷）： 遇到这些字符本工具会明确报出来是哪几个，绝不静默替换成问号——静默 替换会给出一个「看着对其实错」的摘要，比直接报错危险得多。批量模式下这样的行只标失败， 其余行照算。这张表与「文本 MD5」那页共用同一份实现，同一个会话里从那边跳过来时已经 建好，第二次切到 GBK 是零成本。

SHA256 和别人算的不一样？按这六条挨个查

把对方给的摘要粘进「期望值比对」框，不一致时本页会自动按下面六条判据各算一遍做对比， 命中哪条就直接告诉你哪条。全部不命中就如实说「常见原因都不匹配」，不硬凑结论。

SHA256 加盐怎么算，加盐为什么不等于 HMAC

加盐就是把盐和原文拼成一个字符串再算 SHA，位置必须和对方系统完全一致：前缀是 sha256(盐 + 文本)，后缀是 sha256(文本 + 盐)，两者结果毫无关系。以 123456 加盐 deer 为例，后缀得 1fdf33495a985e3dc97e014f84de3ab5bf87844278ca1b42a69c7d26c341bbb4，前缀得 e8d9c7f23e5701f4efd33e34c013add50cce5e53a9a8b1099e2ba677bc699ad9。本页参数区下方会 实时显示当前口径的公式，盐同样只在本地参与计算，不上传也不保存；盐里有中文时会按你 选的编码一起取字节。

还有一件相关的事顺带说清：比特币里的「双重 SHA」（SHA256d）是对第一次算出的32 个原始字节再算一次，而本站「文本 MD5」那页提供的双重 MD5 是 PHP 口径、对 32 位十六进制字符串再算一次——两者语义正好相反。在同一个 站点上并列两个叫法一样、口径相反的「双重」开关是给用户挖坑，所以本页只解释、不提供 这个开关；真要算 SHA256d 的场景处理的是二进制交易数据，本来也不该用文本工具来做。

文本 SHA 实测算例：五个算法与三种写法逐个核对

单条模式点「填入示例」填进去的就是「小鹿tools」这 7 个字符（UTF-8 下 11 个字节），五个算法算出来是这样，你可以拿任何一个命令行工具复核：

把编码切成 GBK，同样这段文字只有 9 个字节（d0 a1 c2 b9 74 6f 6f 6c 73），SHA-256 变成 899449b1aaecb045bc85707ff0e0ec582fac608c0f3897016896c6cd20943275，同样是正确的值。 批量模式点「填入示例」填的是下面四行，按 UTF-8、不加盐、SHA-256 算出来是：

这四行同时演示了四件事：纯数字口令能和任何一处公开值对上；纯英文同理；中文按 UTF-8 是每字 3 个字节；中英混排按字节而不是按字符计——「小鹿tools」是 7 个字符却有 11 个字节。批量结果可以「复制全部（TSV）」直接粘进 Excel，也可以「复制摘要列」只拿摘要， 或者下载 CSV。CSV 带 UTF-8 BOM，Excel 打开中文不乱码；原文里的逗号、引号和换行按 RFC4180 用引号包住转义，不会把列冲乱。空行默认跳过且不占结果行，但行号仍按原文行号编， 方便你回到原始数据里定位。

Python、Java、JS 里的 SHA256 怎么算才一致

先给结论：只要喂进去的字节相同，各语言标准库算出的 SHA-256 就和本页逐位相同， 不存在「Python 的 SHA256 和 Java 的算得不一样」这回事——SHA-256 只有 FIPS 180-4 一套规范，没有方言实现。对不上的原因永远在字节这一侧：取字节时的编码、末尾的换行， 以及拿到字节数组之后转 hex 的那一步。下表以本页「填入示例」用的同一段文字「小鹿tools」 为例，每一行算出来的都应该是 55b93f1f2e35e710c362e3e192c4610c24bb7652b0fa6e28198643223b74bf06， 可以直接粘进本页的「期望值比对」框核对。

还有一点值得提醒：各语言标准库里都没有「加盐」这个参数。 本页的加盐做的就是字符串拼接后再算一次，对应到代码里是先把盐和原文拼好再送进 sha256()，前缀还是后缀由你选，参数区下方会实时显示当前算的是哪个公式，照着抄到代码里即可。 如果你要的是接口签名，请注意拼接不等于 HMAC，原因见前面「SHA256 加盐怎么算，加盐为什么不等于 HMAC」那一节。

SHA 现在还能不能用：能用的场景与不能用的场景

关于 SHA 的说法容易走两个极端，一种是「SHA 加密很安全」， 一种是「SHA-1 已经彻底不能用了」，两句都不准确。准确的说法是分算法看：SHA-1 已被实用地构造出碰撞（2017 年的 SHAttered 给出两份内容不同但 SHA-1 相同的 PDF，2020 年又实现了成本更低的选择前缀 碰撞），所以凡是依赖「难以伪造」的用途都不该再用它；SHA-256 与 SHA-512 目前没有已知的实用碰撞，仍是主流推荐。而速度快这一点对所有 SHA 都成立，它让 SHA 适合做指纹，同时也让它不适合存密码。

文本 SHA 工具的边界：这页做什么、不做什么

最后提一句叫法，方便你去查资料：本页做的是字符串 SHA256，也就是把文本框里那段文字算成摘要；当 SHA256 生成器用时它只生成、不反查。英文语境下这类工具通常叫 SHA256 hash generator 或 text to SHA256，搜 sha256 online、sha256 checksum of string 找到的都是同一件事。要算 文件而不是文字的话，请到「文件 MD5/SHA 校验」那一页，它支持分片流式处理大文件； 如果你手上已经有官方给的校验值清单，「文件校验和验证」更省事；要算 MD5 请到 「文本 MD5」。本页与它们互不重复，各吃各的场景。

相关教程

遇到格式选择、乱码或校验问题，可以先看这些说明再动手处理。

• 操作教程MD5、SHA-256 文件校验怎么做？下载完整性检查指南用 MD5、SHA-1、SHA-256 校验下载文件是否完整，讲清哈希值怎么比对、不同算法怎么选，以及校验通过和不匹配分别代表什么。