HTML表格实现基于Web Cryptography API的加密单元格展示-html教程-PHP中文网

加密单元格需分离渲染与解密逻辑，密文及元信息（算法、key-id、iv、密文base64）须存于data-属性而非内容中；解密时须严格传入iv和additionaldata，使用uint8array格式并标记已解密状态防重复调用，密钥应隔离管理、不可导出且持久化于indexeddb。

html表格实现基于web cryptography api的加密单元格展示

加密单元格需要先分离渲染与解密逻辑

直接在 <td> 里放密文并试图用 Web Crypto 解密后 innerHTML 替换，会触发浏览器的被动脚本执行限制（比如解密后插入含 <code><script></script> 的 HTML），也容易因异步解密未完成导致空白或闪烁。真实场景中，每个加密单元格应携带元信息：算法、密钥ID、IV（如适用）、密文 Base64 —— 这些必须作为 data- 属性存于 <td>，而非渲染内容本身。 <p>示例结构：</p> <pre class="brush:php;toolbar:false;"><td data-alg="AES-GCM" data-key-id="k123" data-iv="base64-encoded-iv" data-cipher="base64-encoded-ciphertext">? 加密中...</td></pre> <ul> <li>密文必须是标准 Base64（非 URL-safe），否则 <code>atob() 会失败

data-key-id 不是密钥本身，而是用于从 IndexedDB 或内存密钥库中查出 CryptoKey 实例的标识符

避免把 IV 或 AAD 拼进密文字符串；Web Crypto 要求它们作为独立参数传入 decrypt()

用 `subtle.decrypt()` 解密 AES-GCM 单元格时必设 `iv` 和 `additionalData`

AES-GCM 是主流选择，但它的 decrypt() 调用比 AES-CBC 多两个强制参数：iv（初始化向量）和 additionalData（可选，但若加密时用了就必须传）。漏掉任一都会抛 TypeError: The operation is not supported 或静默失败。

典型解密调用：

使用HTML,CSS,JavaScript开发Android应用程序英文文字pdf版附源文件

如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更

下载

const decrypted = await crypto.subtle.decrypt(
  { name: "AES-GCM", iv: ivBuffer, additionalData: aadBuffer },
  key,
  cipherBuffer
);

ivBuffer 必须是 Uint8Array，不能是 base64 字符串；用 Uint8Array.from(atob(ivB64), c => c.charCodeAt(0)) 转换
如果加密端没指定 additionalData，此处传 new Uint8Array(0)，不可省略或传 null
解密返回的是 ArrayBuffer，需用 new TextDecoder().decode(decrypted) 转字符串 —— 注意编码，默认是 UTF-8

表格重绘时重复解密会导致性能崩塌

滚动、排序、分页等操作若触发整表重渲染，而每个 <td data-cipher> 都重新调用 <code>decrypt()，CPU 会瞬间拉满。Web Crypto 的 decrypt() 是同步阻塞的（尽管返回 Promise），且无法被 requestIdleCallback 安排。

对已解密过的单元格加 data-decrypted="true" 标记，跳过二次解密
批量解密：收集所有待解密单元格，用 Promise.all( decryptPromises ) 并行处理，但注意浏览器并发限制（通常 6–10 个）
敏感字段（如身份证号）可延迟解密：监听 scroll 或 intersectionObserver，只解密可视区域内的单元格
避免在 render() 函数里调用 decrypt()；应在数据层完成解密，再交由 UI 渲染

密钥管理不隔离会导致跨表格泄露

一个页面多个加密表格共用同一套密钥管理逻辑时，常误把 keyId 当作全局唯一标识，结果 A 表格用 B 表格的密钥解密，报 DataError: The provided data is invalid。Web Crypto 的 CryptoKey 对象本身不可序列化，也不能跨 iframe 共享。

每个表格实例应绑定独立的密钥命名空间，例如 table-abc_user-id-key 而非单纯 user-id-key
用 crypto.subtle.importKey() 导入密钥时，extractable 设为 false，防止被 exportKey() 导出
密钥不应存在 localStorage；推荐用 IndexedDB + 封装的密钥库类，带 TTL 和作用域校验
若用户切换账号，必须显式调用 crypto.subtle.destroyKey()（虽目前多数浏览器未实现，但应预留接口）