光喻1. 医疗业务场景：为什么非要把PDF表格塞进富文本编辑器
先说个我实际遇到的场景。医院信息科提了个需求：门诊大夫在写病历时，想把患者外院带过来的检查报告——比如血常规、生化检验单、影像报告——直接以表格形式贴进病历的富文本编辑器里，而不是截图甩在文末或者作为附件挂载。乍一听很简单，不就是复制粘贴吗？真上手才发现，PDF表格和富文本编辑器之间，隔着一条挺宽的河。
这个需求的本质，是医疗文书的结构化沉淀问题。患者带来的PDF报告，大多是从医院PACS、LIS系统导出的正式检验单，带规范的边框、表头、单位、参考区间，甚至还有二维码和防伪水印。如果只是把整页PDF当作图片插入，问题很直接：病历系统里存的是一张"死图"，没法检索、没法统计、没法复制改错，打印出来放大还会糊。而富文本编辑器的价值恰好在"活"——它是HTML结构，文字可选中、内容可查询、样式可继承。所以医疗系统要的不是"把PDF放进去"，而是"把PDF里的结构化信息提取出来，重新组织成编辑器能认的HTML表格"。
再说得直白一点，这个功能卡在中间层：PDF是版式文档，HTML是流式文档。PDF把每个字、每条线的坐标都固定死了，HTML要靠标签和CSS流式排布。两者之间没有一个通用的"无损直转"通道，尤其是带复杂表头、合并单元格、跨行跨列的检验表格，转换过程稍有不慎就面目全非。
这篇文章我按自己实际趟过的路子，把整个导入过程拆成几个关键环节：选型、解析、HTML生成、边界处理。每一步我都会交代"为什么这么干"，以及在医疗场景下特别要注意的坑。
需要提前说明的是，下面涉及的实现方案，是基于我这边项目里的常见做法补充整理的，不同厂商的编辑器底座（比如UEditor、Quill、wangEditor，或者自研的contenteditable封装）在细节上会有差异，但底层的转换思路是通用的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选型定生死：PDF解析方案的优缺点对比与医疗适配性
先别急着写代码，选错解析库，后面能让你加班三个月。我梳理了市面上主流的几条技术路线，挨个说人话。
2.1 前端直解：pdf.js + 自绘表格
Mozilla的pdf.js能把PDF渲染到Canvas上，也能通过getTextContent()拿到文本块和位置信息。有人会想：既然能拿到文本和坐标，那我是不是可以照着坐标重建表格？理论上是，但实际非常痛苦。PDF里没有"表格"这个概念，只有一行行的文本块、路径和矩形。你要自己判断哪些文本处于同一行、哪些矩形组成了边框、哪个文本块落在哪个单元格里。对于规整的简单表格还能凑合，遇到检验单这种带合并单元格、竖排文字、上下标的，坐标反推算法会让你怀疑人生。
另一个问题是pdf.js体积不小，前端解析大PDF时主线程卡顿明显，在医院的旧电脑（很多门诊电脑还是Win7时代的配置）上体验很糟糕。
我的结论：pdf.js适合做预览，不适合做结构化转换。如果只是想让用户"看看PDF长什么样"，用它没问题；想把表格变成可编辑的HTML，这条路慎重。
2.2 后端解析：Apache PDFBox / iText
Java系医疗项目里，PDFBox和iText是绕不开的两个库。PDFBox专注于解析和提取，iText除了解析还能生成。两者都能通过PDFTextStripper拿到带坐标的文本，也能通过PDFRenderer把页面渲染成图片。
在表格结构还原这件事上，光靠文本坐标仍然不够——你依然要自己实现"行识别""列识别""单元格合并"这套算法，而且PDF里的线条不一定都是规则矩形，有些是用矢量路径画的，提取边框信息的复杂度很高。
不过后端解析有一个压倒性优势：性能可控，不占前端资源；而且拿到的文本是纯文本，方便后续做数据清洗和格式化。医疗数据通常还要过一遍敏感信息脱敏和单位统一，这些逻辑放后端更合理。
2.3 聪明人的选择：PDF转图片 + OCR/图像识别，或者直接转HTML中间格式
还有一条被很多人忽略的路线：先用渲染库把PDF页面转成高分辨率图片，再用OCR引擎识别表格结构。这条路对于"打印体清晰、版式规整"的检验单效果不错，识别出来的结果直接可以转成HTML表格。缺点是OCR对数字的识别会有误差，医疗数据里一个血小板计数错了，那是要出事的。所以OCR结果必须经过校验环节。
另外还有一种"取巧"做法：如果PDF本身是电子版（不是扫描件），可以用工具先转成HTML或Word的中间格式，再清洗成编辑器可用的HTML。比如LibreOffice headsell和Tika都有类似能力。但转换出来的HTML通常带一堆垃圾样式和冗余标签，清洗工作量不小。