哈希生成器与校验和比对工具

纯浏览器本地高效计算并验证字符串与本地文件的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 与 CRC-32 摘要或 HMAC 密钥签名。

输入文本 / 字符串

输入格式：

常用示例：

字符数： 13 字符•字节数： 13 B

哈希计算结果6 种算法

MD5(128-bit)

存在碰撞风险 (仅供校验)

...

SHA-1(160-bit)

已弃用 (仅供兼容)

...

SHA-256(256-bit)

高强度安全 (主流标准)

...

SHA-384(384-bit)

高强度安全

...

SHA-512(512-bit)

最高安全强度

...

CRC-32(32-bit)

仅作校验 (非密码学)

...

如何使用哈希生成器与校验和比对器

选择计算模式：处理字符串或 Token 选择 文本哈希；校验软件包与本地镜像选择 文件校验和；比对官方签名摘要选择 校验和比对；生成带密钥的接口通信签名选择 HMAC 签名计算。
输入或导入数据：在文本框内直接键入或粘贴内容（支持 UTF-8 纯文本、原始 Hex 十六进制字节串或 Base64 编码流）；对于本地文件，直接将文件拖拽至上传区域即可开启本地极速分块计算。
配置编码格式：在右上角工具栏中自由切换小写十六进制（abc）、大写十六进制（ABC）或紧凑型 Base64 编码。
快速提取结果：点击单行结果卡片或右侧复制按钮提取指定算法哈希值；点击 复制全部 可一键导出所有算法摘要的结构化清单。
一键比对验签：切换至 校验和比对 标签页，粘贴软件官网或版本发布日志中公布的预期哈希值，系统将自动进行多算法匹配并提示校验结论。

常用密码学哈希函数架构与特性对比矩阵

全面梳理主流标准化哈希算法的底层架构参数、分组分块规格、安全合规状态及工程选型建议。

算法名称	标准规范	摘要长度	分组大小	内部字长	安全状态	典型工程场景
MD5	RFC 1321 (1992)	128 位 (16 字节)	512 位 (64 字节)	32 位	已失效 (已证实存在碰撞)	S3 ETag 文件指纹、非对抗性数据去重、历史遗留缓存键
SHA-1	FIPS 180-4 (1995)	160 位 (20 字节)	512 位 (64 字节)	32 位	已弃用 (SHAttered 碰撞)	历史 Git 提交 ID、早期数字证书兼容、BT 种子 Infohash
SHA-256	FIPS 180-4 / SHA-2	256 位 (32 字节)	512 位 (64 字节)	32 位	工业基准 (NIST 推荐)	TLS 1.3 握手证书、比特币 PoW、Docker 镜像摘要、软件发布签名
SHA-384	FIPS 180-4 / SHA-2	384 位 (48 字节)	1024 位 (128 字节)	64 位	高强度安全 (截断 SHA-512)	NSA Suite B 商用密码、高安全级企业 VPN、金融级 TLS 连接
SHA-512	FIPS 180-4 / SHA-2	512 位 (64 字节)	1024 位 (128 字节)	64 位	最高强度 (NIST 推荐)	Ed25519 数字签名、Shadow 密码盐值派生、64 位服务器管道处理
CRC-32	IEEE 802.3 (1975)	32 位 (4 字节)	按位流式处理	32 位	非密码学 (仅差错检测)	ZIP/GZIP 压缩包头校验、以太网数据帧校验 (FCS)、PNG 数据块检验

底层架构机制：Merkle–Damgård 结构与长度扩展攻击

分组填充与迭代压缩机制

MD5 与 SHA 系列算法均基于经典的 Merkle–Damgård 结构 设计。在进入循环计算前，输入消息会被附加一个比特 1，填充若干个 0，最后在末尾嵌入一个 64 位（SHA-512 为 128 位）的原始消息长度整型，使得填充后的总长度恰好为固定块大小的整数倍：

512 位分组 (64 字节)：MD5、SHA-1、SHA-256。
1024 位分组 (128 字节)：SHA-384、SHA-512。

每个数据块依次输入单向压缩函数，与上一轮压缩生成的中间状态向量（首轮使用算法固定的初始向量 IV）进行复杂的位运算与混淆，逐轮迭代输出。

长度扩展缺陷与 HMAC 防御方案

由于 SHA-256 的最终摘要实质上就是最后一个分组压缩完成后的内部寄存器状态，若简单使用 Hash(Secret || Message) 进行接口签名，将面临严重的 长度扩展攻击（Length Extension Attack）。攻击者在不知道通信密钥的情况下，仅凭已知消息长度与当前摘要，即可在消息末尾追加恶意数据并准确构造出合法签名。

HMAC（RFC 2104） 通过嵌套的双重散列结构与内部/外部填充常量彻底免疫了此类攻击：

HMAC(K, M) = H((K' ⊕ 0x5c) || H((K' ⊕ 0x36) || M))

工程避坑指南：为什么实际环境中的校验和会不一致？

1. CRLF 与 LF 跨平台换行符陷阱

Windows 系统与开启了 core.autocrlf=true 的 Git 仓库会在行尾使用回车换行符（\r\n / 0x0D 0x0A），而 Linux 与 macOS 默认仅使用换行符（\n / 0x0A）。虽然屏幕上渲染的文本字面完全相同，但字节级哈希值截然不同。跨平台比较前务必统一剥离回车符。

2. 终端 echo 命令自带末尾换行

在 Linux Bash 或 zsh 终端中执行 echo "password" | sha256sum 时，echo 会隐式在末尾追加一个换行字节（0x0A），导致实际计算的是 9 字节数据而非 8 字节。在终端测试中，应改用 echo -n "password" | sha256sum 或 printf "%s" "password" | sha256sum。

3. 十六进制字符串大小写敏感

哈希算法输出的是原始二进制字节流，十六进制只是其编码展现。e3b0c442... 与 E3B0C442... 在数值上完全等价，但在未预先转换大小写的严格字符串比较（如 JavaScript 的 ===）中会判定为不相等。比对前务必统一转为小写。

4. 大文件读取引发的内存溢出 (OOM)

若尝试通过 fs.readFileSync() 将数吉字节的系统镜像一次性读入内存，将直接引发 Node.js 或浏览器标签页堆内存崩溃。生产级哈希系统必须采用受控的流式分块机制（通常每块 64 KB 至 1 MB）进行增量哈希计算（hasher.update(chunk)）。

安全红线提示：切勿直接使用快速哈希存储用户密码

通用密码学哈希函数（如 SHA-256、SHA-512 与 MD5）的底层架构是专门为高吞吐量数据处理而设计的。一块现代消费级独立显卡每秒可并发计算 超过 100 亿次 SHA-256 哈希。如果数据库泄露了仅经过简单哈希的密码，黑客通过字典或彩虹表攻击只需数分钟即可批量还原明文。

在用户身份鉴权场景中，必须强制使用计算缓慢且强内存依赖的专门密钥派生函数（KDF）：

Argon2id (RFC 9106)

国际密码哈希竞赛冠军方案，融合数据依赖与独立内存访问，有效抵御 GPU 并行计算与侧信道缓存攻击。

bcrypt (OpenBSD)

基于 Blowfish 加密算法的自适应密码哈希方案，内置可调工作因子与 128 位强随机盐，业界应用极广。

scrypt (RFC 7914)

强内存依赖设计，要求极大的动态工作内存开销，大幅拉高了定制 FPGA 或 ASIC 专用破解硬件的研发成本。

命令行终端常用校验指令速查

主流操作系统内置的原生哈希计算与校验指令，完全无需安装任何第三方二进制文件：

# Linux / POSIX 终端:
sha256sum release.tar.gz
md5sum release.tar.gz
printf "%s" "raw-string" | sha256sum

# macOS (BSD coreutils):
shasum -a 256 release.dmg
md5 release.dmg
printf "%s" "raw-string" | shasum -a 256

# Windows PowerShell:
Get-FileHash -Algorithm SHA256 .\installer.msi
Get-FileHash -Algorithm MD5 .\installer.msi

# Windows 命令提示符 (CMD):
certutil -hashfile .\installer.msi SHA256

# OpenSSL (跨平台通用):
openssl dgst -sha256 release.tar.gz
openssl dgst -sha256 -hmac "secret-key" payload.json

多编程语言哈希计算标准实现

涵盖前端、后端及系统级主流编程语言中原生或官方推荐的 SHA-256 与 HMAC-SHA256 计算范例。

语言环境

Node.js•node:crypto 原生流式与 Buffer 哈希计算

nodejs

import { createHash, createHmac } from 'node:crypto';

// 计算字符串的 SHA-256 哈希
const hash = createHash('sha256').update('data').digest('hex');

// 计算 HMAC-SHA256 签名
const hmac = createHmac('sha256', 'secret-key').update('payload').digest('hex');

Web Crypto•现代浏览器与 Edge Runtime 标准 API

webcrypto

// 在浏览器中原生计算 SHA-256
const encoder = new TextEncoder();
const data = encoder.encode('data');
const hashBuffer = await crypto.subtle.digest('SHA-256', data);
const hashArray = Array.from(new Uint8Array(hashBuffer));
const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');

Python•Python 标准库 hashlib 与 hmac 模块

python

import hashlib
import hmac

# 计算 SHA-256 摘要
data = b"data"
sha256_hex = hashlib.sha256(data).hexdigest()

# 计算 HMAC-SHA256 签名
sig = hmac.new(b"secret-key", data, hashlib.sha256).hexdigest()

Go•Go 标准库 crypto/sha256 与 crypto/hmac

package main

import (
	"crypto/hmac"
	"crypto/sha256"
	"encoding/hex"
)

func Sha256(data []byte) string {
	sum := sha256.Sum256(data)
	return hex.EncodeToString(sum[:])
}

func HmacSha256(key, message []byte) string {
	mac := hmac.New(sha256.New, key)
	mac.Write(message)
	return hex.EncodeToString(mac.Sum(nil))
}

Rust•RustCrypto 体系 sha2 与 hmac crate

rust

use sha2::{Sha256, Digest};
use hmac::{Hmac, Mac};

// 计算基础 SHA-256
let mut hasher = Sha256::new();
hasher.update(b"data");
let result = hex::encode(hasher.finalize());

// 计算带密钥的 HMAC-SHA256
type HmacSha256 = Hmac<Sha256>;
let mut mac = HmacSha256::new_from_slice(b"secret-key").unwrap();
mac.update(b"payload");
let hmac_hex = hex::encode(mac.finalize().into_bytes());

C# / .NET•.NET 7+ 现代零内存分配 HashData API

csharp

using System.Security.Cryptography;
using System.Text;

byte[] bytes = Encoding.UTF8.GetBytes("data");
string hashHex = Convert.ToHexStringLower(SHA256.HashData(bytes));

byte[] key = Encoding.UTF8.GetBytes("secret-key");
string hmacHex = Convert.ToHexStringLower(HMACSHA256.HashData(key, bytes));

Java•Java 17+ 原生 MessageDigest 与 HexFormat

java

import java.security.MessageDigest;
import java.nio.charset.StandardCharsets;
import java.util.HexFormat;

MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] digest = md.digest("data".getBytes(StandardCharsets.UTF_8));
String hashHex = HexFormat.of().formatHex(digest);

PHP•PHP 8+ 内置原生 hash 与 hash_hmac 函数

php

<?php
$data = 'data';
$key = 'secret-key';

$sha256 = hash('sha256', $data);
$hmac   = hash_hmac('sha256', $data, $key);

软件工程中的核心应用场景

二进制发布件完整性校验：软件发布时附带官方 SHA-256 校验清单，包管理器与下游用户下载后可校验防篡改，确认安装包未被劫持植入后门。
内容寻址存储系统 (CAS)：Git 底层将所有提交对象与文件快照依据哈希值建立不可变 DAG 图谱；Docker 与 OCI 容器镜像直接以 Layer 的 SHA-256 摘要作为唯一寻址指纹（sha256:7f3b...）。
Webhook 回调防篡改签名 (HMAC)：GitHub、Stripe、AWS、微信支付等开放平台在发送事件推送时，均在 HTTP Header 中附带基于 HMAC-SHA256 的签名，供业务服务器检验消息确实来源于官方且未被伪造。
前端静态资源缓存失效 (Cache Busting)：现代化构建工具（Vite、Webpack、Rollup）将代码内容的哈希后缀嵌入产物文件名（如 app.[contenthash].js），实现强缓存最大化并确保版本更新秒级生效。
子资源完整性 (SRI)：现代浏览器通过静态 script 标签的 integrity 属性（integrity="sha384-..."）校验第三方 CDN 加载的脚本，杜绝 CDN 节点被入侵投毒的供应链风险。

Frequently Asked Questions

如何使用 SHA-256 或 MD5 校验下载文件的完整性？

将下载的本地文件直接拖拽至“文件校验和”标签页中，工具将在浏览器本地流式计算各算法的校验值；随后切换至“校验和比对”标签页，粘贴软件官网、GitHub Release 或安全通告中提供的哈希值，系统会自动与所有已计算的摘要比对并高亮提示校验结果。在终端中，亦可通过原生命令行进行验证：Linux 下执行 "sha256sum 文件名"，macOS 下执行 "shasum -a 256 文件名"，Windows PowerShell 下执行 "Get-FileHash 文件名 -Algorithm SHA256"。

SHA-256 与 MD5 有何本质区别？不同场景下应如何选型？

MD5 输出固定 128 位（32 位十六进制字符）摘要，因早已在学术界与工程界被证实存在碰撞漏洞，严禁用于密码散列、数字证书与安全签名；但因其计算速度极快，仍广泛用于非对抗性场景的存储去重与偶然性传输错误校验（如 Amazon S3 ETag 与对象存储缓存标识）。SHA-256 输出 256 位（64 位十六进制字符）摘要，具备极高的抗原像性与强抗碰撞性，是当前工业界软件发布、TLS/SSL 证书签发、Git 进阶存储及区块链共识机制的标准算法。

为什么文本哈希值会与终端命令行或其他工具计算出的结果不一致？

哈希不一致通常由不可见的隐式字符或字符编码差异导致：1) 末尾隐式换行符：类 Unix 终端中执行 'echo "hello" | sha256sum' 会默认在字符串末尾追加一个换行符（0x0A，即 \n），导致实际计算的是 6 个字节而非 5 个字节。建议使用 'printf "%s" "hello" | sha256sum' 或 'echo -n "hello" | sha256sum'；2) 跨平台换行符规范：Windows 采用 CRLF（\r\n），而 Linux/macOS 采用 LF（\n）；3) 字符集编码：确保源字符串均按同一字节流规范解释（如统一为 UTF-8，而非 UTF-16 或 GBK）。

什么是 HMAC？它与普通的密码学哈希有何区别？

普通单向散列（如 SHA-256）仅能证明数据在传输过程中是否被意外篡改（保证数据完整性）；而 HMAC（基于哈希的消息认证码，RFC 2104）在消息哈希过程中引入了仅通信双方知晓的共享通信密钥（Secret Key），通过嵌套的双重哈希结构进行计算。HMAC 既能验证数据完整性，又能确认消息发送方的身份合法性（确认消息确由持有该密钥的通信方签发），并彻底杜绝了普通 Merkle–Damgård 哈希固有的长度扩展攻击（Length Extension Attack）。HMAC-SHA256 是主流开放平台（如 GitHub、Stripe、AWS、微信支付、企微/飞书）Webhook 签名与 RESTful API 鉴权的标准方案。

十六进制输出的大小写转换或 Base64 编码会改变哈希本质吗？

不会。密码学哈希本质是一个固定长度的原始二进制字节数组（例如 SHA-256 永远由 32 个原始字节组成）。十六进制（Hex）只是为了便于人类阅读与文本传输而采用的表现形式，小写（a-f）与大写（A-F）对应的底层数值完全相同；Base64 则是以 64 个 ASCII 字符对该原始二进制字节进行紧凑编码（SHA-256 经 Base64 编码后为 44 个字符，而十六进制为 64 个字符）。本工具工具栏支持在十六进制（小写/大写）与 Base64 间无缝切换，方便开发者适配不同 API 接口规范。

本工具能否在浏览器中直接对大文件计算哈希？是否有体积上限？

可以。本工具完全利用浏览器底层的 Web Cryptography API 与 TypedArray 分块流式读取技术在本地计算，所有数据绝不上传服务器，彻底保障私密文件的安全性。由于在浏览器沙箱内运行，内存占用取决于当前标签页的可用堆内存：通常几百兆至 1 GB 到 2 GB 的文件均可顺畅完成本地哈希。若需要校验数十 GB 的超大操作系统镜像或海量归档文件，建议直接使用系统原生命令行工具（如 sha256sum、shasum 或 PowerShell Get-FileHash），以充分利用操作系统底层 Direct I/O 与硬件加速指令集。

像 SHA-256 或 MD5 这样的单向哈希能够被反向解密还原吗？

不能。密码学哈希在数学上被严格定义为“单向函数”（One-Way Function），其本质与对称/非对称加密有着根本区别。加密是通过密钥将明文转为密文并可逆还原；而哈希是将任意长度的数据不可逆地压缩映射为固定长度的摘要，在计算过程中已经丢失了绝大部分原始信息。攻击者无法在数学层面反向求解明文，只能通过暴力穷举（Brute-force）、预计算字典或彩虹表（Rainbow Table）对已知散列值进行碰撞撞库比对。

为什么在数据库中绝不能直接使用 SHA-256 或 MD5 存储用户密码？

通用密码学哈希算法在芯片底层专门针对高吞吐量数据处理进行了工程优化（每秒可处理数百兆甚至数吉字节数据）。使用现代消费级显卡（GPU）或 ASIC 集群，攻击者每秒可并发计算数十亿甚至数百亿次 SHA-256 哈希，使得未加盐或单次哈希的密码库在字典攻击下数分钟内即可被完全破解。存储用户口令必须采用计算缓慢且强内存依赖的密钥派生函数（KDF），例如当前业界强推的 Argon2id（RFC 9106）、bcrypt 或 scrypt。这些算法通过强制引入计算延迟与大内存占用，大幅增加专用硬件并发破解的门槛与经济成本。

十六进制 Hex 转换器

UUID / GUID 在线生成器

Base64 编码与解码器