做过电子公文、电子发票、档案系统的同学，大概率都被 OFD 坑过。这篇文章记录一下我们团队自己做浏览器端 OFD 编辑引擎的过程，给有同类需求的同行做个参考。
最近在迭代协同文档产品的过程中，我们接触了大量 OFD 文档处理需求，也基于对 AI 办公领域的技术积累，尝试做了一款浏览器端的 OFD 编辑器。这篇文章主要记录其中的技术思路和踩过的坑。
先聊聊背景
OFD 作为我国国标版式文档格式（GB/T 33190‑2016），已经深度渗透到电子公文、增值税电子发票、电子合同、档案归档、电子证照等政企核心业务场景。但行业长期存在一个现实矛盾：标准落地快，工具生态跟不上。
我们总结出三个核心痛点：
- 现有 OFD 工具以桌面客户端为主，处理文档必须下载安装专用软件；
- 浏览器原生不支持 OFD 解析渲染，业务系统想集成预览编辑，往往要面对组件笨重、依赖服务端上传、移动端适配差、大文档卡顿、转曲文字无法编辑等一系列问题；
- 很多 OA、档案、合同系统只能做到简单预览，一旦需要二次修改，只能下载到桌面软件处理、再回传系统，流程割裂、效率大打折扣。
针对这些问题，我们尝试用浏览器端渲染与编辑 的思路来解决，做了一版名为 JitOFD 的 Web 端 OFD 编辑引擎：
基于 Canvas + 虚拟 DOM 双端渲染架构，在浏览器环境完成从打开、高保真渲染、二次编辑到标准 OFD 文件回写的全链路。
解析运算全部在浏览器本地完成，原始文件不上传服务器------这既兼顾功能完整与访问便捷，也在架构层面天然规避了文档外泄风险。
核心能力是怎么实现的
1. 高保真预览
渲染层采用 Canvas，精确绘制文字、图形、图像、复合对象、模板页、注释与电子签章；发票表格线、印章、二维码等复杂元素也能保持较高精度，实测渲染效果与主流桌面办公软件基本一致。
2. 二次编辑OFD文件
支持选中、移动、缩放、旋转，双击修改文本，同时能改字号 / 字形 / 颜色 / 透明度，增删对象、层级调整、页面增删排序等。
3. 转曲文字原位编辑
支持双击已转曲的矢量文字做原位编辑，配合离线 OCR 预填，自动识别原字体、字号、颜色，按原行距排版保持版式。
4. 电子签章与书签
按 StampAnnot 精确渲染印章外观并展示签名元数据；侧栏读取书签树，点击跳转到目标页与位置。
5. 文档支持加密
支持口令加密（GM/T 0099‑2020 方案，SM3 KDF + SM4‑CBC）解密阅读编辑，并可为导出文件设置打开口令。
6. 支持导出，合并和打印
回写标准 .ofd（仅覆盖被修改的 XML），可导出 PDF / 打印 / 当前页 PNG，并支持合并另一份 OFD 的全部页面。
7. 多端适配，手机，电脑，平板都是使用
一套渲染与适配引擎，手机、电脑、平板均可使用，也能以组件形式嵌入 OA、ERP、手机 APP。
踩坑记录：直面 OFD 真实业务的技术痛点
市面上很多 OFD Web 组件仅实现简单预览，编辑能力薄弱，尤其面对政务、发票场景大量 "转曲文字（路径化矢量文字）" 文档，只能看不能改，这也是很多项目落地的卡脖子点。
我们自研的 OFD 编排引擎（如上图所示架构设计）针对性解决了多个高频痛点：
-
转曲矢量文字，是政务场景最大的拦路虎
政务红头文件、部分电子发票里有大量文字被转成 Path 路径（路径化矢量文字），普通工具只能看不能改，这是很多项目落地的卡脖子点。市面上很多 OFD Web 组件只做简单预览、编辑能力薄弱，尤其面对这类文档只能看不能改。
我们的处理思路是：内置离线 OCR 预识别，双击即可原位编辑转曲文字，自动还原字体、字号、颜色、行距，保持原有版式不变，不用重新绘制页面。这里踩的坑主要是三个：OCR 识别精度会直接影响版式还原质量；字形轮廓与文本块之间的对应关系需要单独建立；原位编辑后如何保证行距、位置与原版一致，而不是简单替换字符。
-
超大文档的性能，靠"净变更回写"兜底
100 页+级别的大型 OFD 文档要做到快速打开、流畅重绘，单靠渲染优化不够。我们的实测数据是：打开控制在 3 秒左右，单页重绘 5‑11ms。更关键的是编辑后的回写策略------我们采用净变更回写机制，只重写被修改的 XML 片段，图片、字体、签章、附件等未改动条目直接原字节保留输出。这样既保证档案场景的原件完整性，撤销全部修改后还能与原文件字节对齐，满足档案归档的严苛要求。
-
国密加密文档，浏览器端解密可行
兼容 GM/T 0099‑2020 口令加密方案（SM3 KDF + SM4‑CBC），浏览器端完成解密阅读编辑，同时支持导出文档设置打开口令，适配加密公文、涉密业务文档的处理需求。
落地验证情况：贴合政企真实业务，三种接入模式
JitOFD 面向真实业务打磨，已经在增值税电子发票处理、政务红头公文、带签章合同、档案归档系统验证可用性，同时提供三种使用模式，适配不同企业诉求：
-
在线即用
直接访问站点，拖拽 OFD 文件即可预览编辑，适合快速技术评估、个人临时处理 OFD 文件。
-
私有化部署
源码交付，部署企业内网环境，完全离线运行，适配信创环境、国产浏览器，满足等保、自主可控采购要求，敏感文档全程不出企业内网。
-
业务系统集成
基于模块化封装，支持 iframe 嵌入或组件集成方式，无缝嵌入 OA、ERP、档案管理、合同平台、工单系统，业务无需改造现有流程即可获得 OFD 全生命周期处理能力。
重要安全特性：浏览器本地计算，解析、渲染、编辑全部在客户端执行，文件不会上传到服务端。对于政务、国企、金融，涉及红头公文、涉密合同、会计发票档案场景，从架构层面规避文档外泄风险。
思考复盘：OFD 生态不止 "能打开"，更要 "能融入现有业务"
OFD 国标落地这么多年，大家讨论最多的是合规、归档、防篡改，却常常忽略业务体验。很多系统为了满足政策要求引入 OFD 格式，结果反而增加员工操作负担：只能预览、编辑必须导出桌面软件来回折腾、多端体验割裂、移动端几乎不可用。
我个人认为，OFD 想要真正壮大，同样需要走向轻量化、Web 化、组件化，把能力嵌入到用户日常工作的 OA、档案、报销系统里面，而不是强迫用户切换独立客户端。我们做 JitOFD 的出发点，不是简单复刻桌面 OFD 软件到网页，而是想验证一个问题：Web 端能否做到完整的 OFD 编辑能力，同时符合国标规范、档案完整性、数据安全这三条底线。
目前我们团队还在做更有价值的 AI 办公方案，比如 JitWord 协同 AI 文档、JitKnow AI 知识库，后续也会持续补充国产办公环境的文档处理能力。如果这条路走得通，国产版式文档的 Web 工具生态就有更多可能性，也欢迎有同款需求的开发者、政企伙伴一起交流实现方案。
