防伪编码应存于标签中，如，不可用id/class或div/p包裹，须服务端生成签名并校验，前端仅安全呈现。

防伪编码不是靠 HTML 标签“标注”出来的，HTML 本身不提供防伪能力；它只是把已生成的唯一 ID 展示给用户看。真防伪得靠后端生成、签名、校验，前端只负责安全地呈现。

防伪编码该存在哪个 HTML 元素里

用 标签放最稳妥，比如塞进 里的 。这样既不干扰页面视觉，又方便自动化工具（如验证脚本、爬虫、审计系统）精准提取，还不容易被误删或覆盖。

别用

或

直接包裹编码——用户复制时可能多带空格、换行或前后文字；也别藏在 data- 属性里（如 data-cert-id），部分老旧爬虫或校验工具不识别自定义属性。

• 必须确保 content 值是纯字符串，不含 HTML 实体（如不用 ​ 隐形字符混淆）
• 避免把编码拼在 URL 参数或 JS 变量里展示，那属于运行时动态内容，无法被静态校验工具读取
• 如果证书要打印，记得在 @media print 里显式显示该 的对应提示文案（比如用 ）

id 属性不能当防伪编码用

id 是 DOM 标识符，不是业务凭证。它可被前端任意修改、重复、删除，浏览器也不校验其唯一性或格式。把防伪码硬塞进

，等于把密码写在门牌号上——看着像那么回事，其实毫无约束力。

更麻烦的是：一旦页面有多个证书模块，id 重复会触发 HTML 合法性警告，某些严格解析器（如 XML 工具、无障碍检测器）直接报错；而防伪系统依赖的往往是精确匹配，ID 一乱就全崩。

• 绝对不要用 id 或 class 存编码值
• 即使你控制全部前端代码，也不能假设用户不会右键审查元素后手动改掉 id
• 如果要用 DOM 定位展示区域，用独立的容器 id（如 id="cert-display"），编码本身走 或隐藏

怎么让防伪编码不被轻易批量抓取

做不到完全防抓，但可以提高门槛。核心思路是：不让编码以明文、固定位置、可预测结构暴露在 HTML 源码里。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

常见错误是把所有证书都用相同 name 的 ，比如统一叫 cert-id，结果一个正则 ]*name="cert-id"[^>]*content="([^"]*)"[^>]*/> 就全薅走。稍微改下策略就能卡住大部分脚本：

• 用动态 name 值，比如 name="cid-{{hash(cert_no)[:6]}}"，每次渲染不同
• 把编码拆成两段，一段放 ，一段放 <script></script> 内联变量，验证时需拼接（注意 XSS 过滤）
• 对编码做简单不可逆混淆，比如 Base64 + 固定位移，不为加密，只为打破正则通用性

记住：这些只是增加自动化采集成本，不是替代服务端签名。真正校验仍需用户访问官方验证页，传入编码并由后端比对签名、时效、状态。

最常被忽略的一点：防伪编码的生成和绑定必须发生在服务端，且与用户身份、发证时间、证书哈希强关联。前端哪怕把编码用 canvas 渲染成图片、用 SVG 路径描边、甚至藏在字体文件里，只要没服务端校验环节，就只是纸糊的锁。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！