HTML签名验证本质是比对哈希值，需从前端提取服务端指定的原文（如script标签内JSON），用相同算法和编码与签名比对；浏览器不自动处理，JS必须精准还原原文、统一编码与空格，否则校验失败。
签名验证本质是比对哈希值，不是解析 HTML
HTML 本身没有内置签名验证机制。所谓“HTML 签名”，实际是指在 HTML 文档中嵌入或关联一段由服务端生成的数字签名（比如 signature 字段），用于验证该 HTML 内容（或其对应数据）未被篡改。浏览器不会自动校验它，必须靠 JS 主动提取、计算、比对。
常见错误现象：Signature verification failed 不是因为 HTML 写得不对，而是 JS 拿错了原文、用了错误编码、漏了排序或忽略了空格。
- 使用场景：支付回调页、电子合同预览页、第三方 iframe 嵌入的可信内容页
- 关键点：签名原文 ≠ 整个 HTML 字符串，通常是某个
data对象序列化后的字符串（如 JSON） - 容易踩的坑：
JSON.stringify()默认不保证键顺序，不同环境可能生成不同哈希；直接用innerHTML取内容会混入浏览器自动修正的标签，导致原文不一致
如何安全提取待签名原文（以 JSON 数据为例）
绝大多数 HTML 签名验证流程里，“原文”其实是隐藏在页面中的结构化数据，比如一个 <script type="application/json" id="payload"></script> 块。必须从这里取，而不是拼 HTML 或读表单值。
示例结构：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
<script type="application/json" id="payload">
{"order_id":"ORD-123","amount":99.9,"timestamp":1717023456}
</script>
- 正确做法：用
document.getElementById('payload').textContent获取原始 JSON 字符串，再用JSON.parse()验证合法性（但不要直接用 parsed 对象重 stringify —— 键序可能变） - 为什么不用
JSON.stringify(parsed)：V8 和其它引擎对相同对象的键序不总一致；某些字段可能是undefined或null，JSON.stringify()会静默丢弃 - 兼容性注意：IE 不支持
textContent，需 fallback 到innerText或firstChild.nodeValue，但更稳妥是服务端输出时就确保格式稳定
签名比对必须用服务端同源算法（HMAC-SHA256 最常见）
前端 JS 无法真正“验签”，只能做 HMAC 校验（即服务端用私钥 + 原文算出签名，前端用公开的密钥 + 相同原文复现一次，比对结果）。RSA/ECDSA 等非对称验签必须在服务端完成，前端暴露公钥也不等于能安全验签。
- 典型错误：把 Base64 编码的签名直接和 JS 生成的 hex 字符串比对 → 编码方式不一致（
base64vshex） - 参数差异：
crypto.subtle.importKey()导入密钥时，format必须是"raw"（HMAC）或"jwk"（RSA），填错直接报OperationError - 性能影响：SHA256 在现代浏览器很快，但若原文超 1MB，
TextEncoder.encode()+crypto.subtle.digest()会阻塞主线程，建议用Web Worker
最容易被忽略的空白与编码陷阱
哪怕只差一个空格、换行或 UTF-8 BOM，哈希值就完全不同。而 HTML 容易在传输或编辑中悄悄引入这些。
- 服务端输出 JSON 时务必设置
Content-Type: application/json; charset=utf-8，并确认无 BOM（尤其 Windows 记事本保存的文件） - 前端取
textContent后，用str.trim()清除首尾空白，但不要用str.replace(/\s+/g, '')—— 会破坏 JSON 中合法的空格（如字符串值内） - 如果签名原文含中文或特殊符号，确保服务端和前端都用 UTF-8 编码处理字节流；Node.js 默认是 UTF-8，但 Python 的
json.dumps()需显式加ensure_ascii=False
复杂点在于：签名逻辑往往跨前后端、多语言、多部署环境。只要有一环默认配置不同（比如 Go 的 json.Marshal 和 PHP 的 json_encode 对 NaN 的处理），整个链路就失效。别假设“看起来一样就行”。
