上个月我在一个医疗信息化技术社群里又看到有人提问“医院电子病历怎样把PDF中的医学公式导入XHEDITOR”底下回复五花八门有说直接复制粘贴的有说转成图片的还有说干脆手打的。我特别理解这种困惑因为我当初在某医院电子病历功能改造项目中为了把检验手册里那批PDF公式弄进XHEDITOR整整折腾了一周。今天就把这条路的完整走法、踩过的坑、以及最终落地的方案一次性写清楚。先说结论PDF里的公式从来不是“一个公式”它有文本流、图片、矢量路径三种完全不同的存在形态每种形态对应的导入方式天差地别。而XHEDITOR作为常见的Web富文本编辑器原生能识别的数学公式格式也有限。只有把“PDF端公式形态”和“编辑器端公式格式”两头摸清中间的转换流水线才能搭建得起来。这篇东西适合谁看给医疗信息化项目的开发人员、集成商技术实施、以及需要批量整理医学文档公式的运维和支持人员。看完你至少能搞清楚PDF医学公式为什么难导入、该选哪条技术路线、代码怎么组织、实际数据里最常出现的失真问题怎么处理。1. 先拆解PDF公式的存在形态这决定了你的导入策略很多人在这一步就踩了大坑。拿到一份PDF看到屏幕上有模有样的公式就想着“我用工具提取文本或者直接复制粘贴到XHEDITOR”。结果一粘过去全是乱码或者上下标全丢了或者干脆粘出来是个空白。这不是粘贴姿势不对而是你没有先搞清楚这个公式在PDF文件内部到底是以什么形式存在的。PDF不像Word那样有结构化的“公式对象”概念它本质上是一份“版式描述文档”。我总结下来医学PDF里的公式无外乎三种存在形态第一种文本流形态。公式里的字母、数字、运算符号以文本字符的形式真实存在于PDF内容流中。这种公式可以“被复制出文字”但是顺序和排版往往乱掉最典型的表现就是“Na”复制出来变成“Na”上标“”像人间蒸发一样或者“eGFR”这种缩写没问题但公式里真正的分数线和根号就无能为力了。第二种图片形态。整个公式被导出方做成了位图嵌入PDFPDF内部只有一张图片没有任何文本信息。这种情况你复制不了只能识别图片。在老旧的检验手册PDF里这类公式占比相当高因为很多文档是从Word转PDF时用了“粘贴为图片”的方式。第三种矢量路径形态。公式被描述为一系列贝塞尔曲线路径字形和排版信息完全消失只剩下“看起来像字”的轮廓。这种最麻烦提取文本不可能图片识别也没法直接喂进去因为它是矢量不是像素。快速判断一个公式属于哪种形态有个很朴素的操作用PDF阅读器选择公式区域如果能选中文字那是文本流如果只能选中整张图那是图片如果既选不中文字、放大无数倍仍然清晰锐利同时用工具查看对象属性发现全是path那就是矢量路径。形态判断直接决定了后面技术路线的选择所以我建议你在做任何工具选型和写代码之前先抽样打开10到20页PDF手工确认每个公式块的形态。这个抽样的工作量不大但能帮你避免把方案设计成“空中楼阁”。2. XHEDITOR端到底认什么公式格式先把目标格式定下来搞清楚PDF端的形态现在反过来看编辑器端。我们在讨论“导入”之前必须回答一个问题XHEDITOR的公式存储和渲染机制支持什么格式只有知道了目标格式才知道要把PDF里的公式“翻译”成什么。以我接触过的XHEDITOR版本来看它是基于Web的富文本编辑器要在页面里显示一个带分数、根号、上下标的医学公式底层基本是靠HTML CSS 部分字体渲染能力来实现的。对于真正的数学排版一般依赖两类机制一类是直接渲染MathML也就是通过math标签体系描述公式结构。MathML是一种XML应用能表达分数mfrac、根式msqrt、上下标msub、msup等所有数学结构。浏览器和编辑器内核如果支持MathML就能直接把这个XML节点渲染成漂亮的排版公式。这也是XHEDITOR这类注重结构化文档的编辑器比较亲睐的方式。另一类是保存LaTeX源代码在显示时调用渲染引擎如MathJax或KaTeX将它转换成HTML和CSS。这种方式的优势是源代码阅读性强但缺点是渲染依赖外部的JavaScript库而且有些编辑器对LaTeX的支持只停留在“把整段公式代码包在专用标记里”的层面和文档其他内容的交互性弱。我把几种常见公式格式放在一起对比你可以直观地看到它们的差异和适用场景候选格式结构表达能力编辑器兼容难度是否适合批量转换医学业务场景表现LaTeX源码强通用数学排版标准依赖渲染插件非常合适OCR识别结果天然是LaTeX源码难读需要统一封装MathML强W3C标准结构语义完整较好XHEDITOR对MathML有基础能力需按版本确认较合适可从LaTeX转换结构清晰适合病历结构化存储OMML强Office数学标记语言一般需转换不推荐直接作为中间格式主要服务Word双向兼容场景图片PNG/SVG等同于图形无结构语义最容易兜底方案美观但不能检索和编辑基于这个对比我在实际项目中定位的标准方案是以MathML作为XHEDITOR的最终导入格式以LaTeX作为传输交换格式。具体链条就是“PDF公式 → 识别/提取 → LaTeX → MathML → 插入XHEDITOR”。为什么这么定因为识别引擎商业API和开源模型输出LaTeX是行业默认能力而XHEDITOR要真正把公式作为可编辑结构化对象保存在病历里MathML是比LaTeX源码更稳的载体。你在做具体集成之前务必让团队成员用你们当前的XHEDITOR版本实测一次“插入一段MathML字符串看能渲染成什么”确认版本能力再走下一步。还有一个容易被忽略的医学公式特点病历里的公式大多是检验指标计算、药物剂量换算、肾小球滤过率估算这类比如eGFR简化MDRD公式、Cockcroft-Gault肌酐清除率公式、Henderson-Hasselbalch酸碱平衡公式。它们的共同点是变量多、上下标多、分子分母结构频繁而且含有“⁺”“⁻”“±”“×”这类特殊符号。这意味着在转换链路里特殊字符的编码和映射表必须做得非常细。3. 分形态转换流水线文本提取、公式识别与归一化目标格式定好以后我对不同形态的PDF公式分别建立了处理分支。这三个分支合起来就是一条完整的转换流水线。下面按实际情况逐一说明代码都是我在项目里验证过的思路你可以直接参考改造。3.1 文本流形态用PDF解析库按位置提取并重组上下标对于文本流形态的公式核心思路不是“光学识别”而是“位置解析”。PDF页面上的每个字符都带有一个坐标框bounding box上下标和普通字符的字体大小不同、位置基准线不同。我们可以通过解析字体的字号和基线偏移把“Na”后面的小号“”识别为上标再重组成字符串“Na⁺”。我用的解析工具是PyMuPDFfitz库它在提取文本时能连带输出每个字符的bbox、字体名和字号。核心代码如下import fitz doc fitz.open(medical_formulas.pdf) page doc[0] # 以dict模式提取文本能拿到每个字符的坐标和字号 blocks page.get_text(dict, flagsfitz.TEXT_PRESERVE_WHITESPACE) for block in blocks[blocks]: if lines not in block: continue for line in block[lines]: for span in line[spans]: text span[text] size round(span[size], 1) bbox span[bbox] # 判断是不是上标/下标捕获字体大小明显小于同段落基准字号的片段 # 记录坐标y值用于后续重排 print(f{text} | font_size{size} | bbox{bbox})拿到每个span之后下一步就是按照同一行内的坐标顺序把同一公式的文本片段串联起来同时判断哪些字符是上下标。判断规则我总结为三条一是字号明显小于同组基准字符二是bbox的垂直位置高于或低于行基线三是字符本身是“”“-”“数字”等候选上下标内容。三条规则叠加命中就把它当上下标处理。这套办法在实测中的效果很不错特别是对于“Na⁺”“Cl⁻”“K⁺”这类离子符号准确率能达到九成以上。前提是原始PDF的字体信息没有被导出方“压扁”。如果PDF是从扫描版转出来的OCR层那字体信息反而不可靠就要转到图片识别分支去处理。3.2 图片形态调用公式识别引擎输出LaTeX再转MathML图片形态的公式是项目中数量最多的情况。处理思路也很直接按坐标把公式区域裁剪成图片送进公式识别服务拿到LaTeX源码再转换成MathML。关于公式识别引擎市面有两类选择。一类是商业化的公式识别服务API它们对印刷体数学公式的识别准确率高返回结果里既包含LaTeX也包含MathML并且对分式、根号、矩阵这些复杂结构的支持度都很强。集成方式就是普通的HTTP请求上传图片、拿JSON结果。另一类是开源模型比如专门做LaTeX识别任务的pix2tex系模型可以本地部署推理适合对数据隐私要求非常严格的医院环境但准确率和复杂结构支持度通常会弱一些。我当时的选型逻辑是先拿50张代表性医学公式图片去实测覆盖离子符号、分式、根式、希腊字母这四类高频结构。如果商业API在分式和根式上明显超出开源模型而医院对出网又不敏感就直接用商业服务。如果医院要求所有文档处理必须在内网完成那就只能本地部署开源模型同时接受它偶尔在根式边界识别上的小毛病。识别拿到的LaTeX还不能直接进XHEDITOR需要做一次格式归一化——把LaTeX转成MathML。这一步可以用MathJax提供的tex2mathml工具做转换也可以用其他支持LaTeX到MathML的开源库。转换后的MathML会带上完整的math根节点结构这就是我们最终要插入编辑器的内容。3.3 矢量路径形态不要恋战直接走图片快照兜底矢量路径形态的公式我给出的建议可能让一些技术洁癖的人不舒服除非公式数量极少且极其重要否则不要试图从矢量路径还原出可编辑公式。在PDF中把文字转曲curves之后字符的语义信息就彻底丢失了任何反推都只是近似猜测而且准确性没有保障。面对这种形态我采用的处理方式是通过PDF渲染引擎将公式区域高清截图为PNG或SVG然后把这个快照作为图片对象直接插入到XHEDITOR的同文档位置。虽然在可检索性和可编辑性上打了折扣但至少版面是完整的。如果你不满足于图片兜底还有一个折中方案把矢量公式渲染成大图后再走一遍图片识别分支。识别成功的部分用MathML插入识别失败的部分保留原图并做人工标记。这样既保证了绝大部分内容的结构化也不至于让个别复杂公式阻塞整条流水线。4. 从PDF到XHEDITOR的实战接入流程前面都是原理和分支策略到了这一步我直接给出一个可落地的接入方案。整个流程用自然语言描述就是第一步PDF按页解析按公式区域切块给每个公式块打上“形态标签”区分文本流、图片和矢量路径。第二步按标签走不同处理分支得到统一的LaTeX字符串或者得到一个图片快照路径。第三步把LaTeX统一转换为MathML字符串。第四步在前端调用XHEDITOR提供的扩展接口把MathML结构插入编辑器当前光标位置。我在服务端用的组合是Java Spring Boot PyMuPDF脚本。为什么掺着用因为PyMuPDF做PDF解析最顺手但医院项目的业务主栈是Java所以让Python脚本做PDF解析和公式裁剪Java服务端负责调度和调用识别API最后把转换结果返回给前端页面。如果你们团队全栈都是Java也可以用Apache PDFBox做文本提取但坐标级别的字符信息获取确实比PyMuPDF啰嗦不少。前端插入MathML的关键代码我用的是类似这样的思路// 假设后端已返回MathML字符串 const mathml response.data.mathml; // 例如 math xmlns...mfrac.../mfrac/math // 调用XHEDITOR的编辑器实例插入HTML内容 if (window.xhEditorInstance) { editor.execCommand(insertHTML, mathml); } // 部分版本需要先转换为HTML节点再插入 const template document.createElement(template); template.innerHTML mathml.trim(); const mathNode template.content.firstChild; editor.selection.insertNode(mathNode);具体调用的是XHEDITOR的哪个接口取决于你们项目使用的版本和封装方式。我这边只是给出一个通用模式实际集成时打开XHEDITOR的API文档找到“插入HTML”或“insertContent”一类的入口即可。流程跑通以后最容易被大家忽视的是验证环节。我做了这样一份检查清单每次导入完成后逐项核对检查项验证方法通过标准上下标完整性抽查Na⁺、Cl⁻、eGFR等常见项上标/下标位置正确符号无丢失分式结构查看eGFR、CrCl公式渲染效果分数线位置正确分子分母不串行根式边界查看含根号公式根号覆盖范围与实际公式一致希腊字母抽查α、β、γ等变量字符无乱码或替换特殊符号检查±、×、≤、≥语义无歧义验证工作我强烈建议不要全自动化保留人工抽检环节。医学公式的错误不像普通文本那样容易发现一旦某个上下标弄错用在临床计算上就是大事故。哪怕自动化处理了1000条公式人工抽检100条的成本也远远低于出事故后的代价。5. 真实病历PDF里的高发问题我的踩坑记录和对策理论流程看着顺畅但真实数据永远比示例复杂。我把这次改造中遇到的高发问题列出来每一条都是真实吃过亏的地方希望对你有实际帮助。5.1 嵌入字体的CID编码导致“复制出来全是乱码”第一个大坑出现在文本流形态的公式上。有些PDF使用了嵌入子集的字体字符在内容流里对应的不是Unicode而是一个内部CID编号。你从PDF阅读器里用选择工具看文字显示正常但复制出来全是“乱码”提取出来的字符串和屏幕上长得完全不一样。当时我把某个药剂浓度公式提取出来后看到一堆不明字符一度以为是编码解析有问题。后来判断是CID字体映射缺失解决方案是在PyMuPDF提取时优先使用字符的Unicode映射如果发现映射缺失就退回到基于字形相似度和上下文语义的替换。更省事的方法则是直接把这块区域渲染成图片转入图片识别分支处理绕开字体映射的坑。5.2 上下标被拆成多个文本段普通提取直接丢符号PDF的文本流并不遵循“一个公式一个文本段”的规律。导出工具完全可能把一个上标的“”放在一个独立的span里甚至和前面的“Na”隔了很远的坐标距离。如果你按普通文本顺序拼接上标符号就会跑到公式末尾或者直接被当作乱码丢掉。这种问题的本质是“文本顺序不等于视觉顺序”。解决思路还是回到3.1节的方法按坐标位置重新排序用字号和基线偏移判断上下标。但要注意一个细节同一个公式内不同片段之间的坐标间距可能很不均匀单纯按x坐标排序也会出错。我的做法是先把同一视觉行的span按y坐标聚合再在行内做x坐标排序效果好了很多。5.3 OCR把“Cl⁻”识别成“Cl7”特殊符号后处理字典必须做图片公式走OCR识别时离子符号是重灾区。我实测下来“Cl⁻”里的上标“⁻”经常被识别成数字“7”或字母“t”“Na⁺”的“⁺”会变成“”或直接丢弃。原因不难理解上标符号本身像素信息少和基线字符分离识别模型在缺乏上下文时容易误判。对策是建立一套医学符号后处理字典。比如识别出“Cl7”时结合医学公式常见模式氯离子必然是Cl⁻自动修正为“Cl^{-}”“Na”修正为“Na^{}”。这个字典不需要覆盖所有情况只要针对检验报告和药物手册里最高频的几十个离子和化学式即可。我在项目里用了一个小的规则引擎先做正则替换再做人工抽检把识别准确率从八成的样子拉到了九十五左右。5.4 表格内的公式被整页识别结果一团糟医学PDF里大量公式是嵌在表格里的比如“参考范围”列、“计算公式”列。最初我把整页图片丢给识别服务结果模型把表格线和公式混在一起输出了一堆大括号和莫名其妙的矩阵结构。后来改成先做表格结构解析把每个表格单元格裁剪成独立图片再逐格识别效果立刻好了起来。如果你用的PDF解析库不支持表格解析也可以根据坐标网格线来切分单元格其实原理一样先找横线和竖线确定单元格边界再裁剪内容。这一步不要省直接决定表格内公式的识别质量。5.5 分式的分子分母被识别成一行分式结构在医学公式里太常见了比如eGFR公式里就有长分式。识别模型偶尔会把分子、分数线、分母压成一行变成“186 × SCr-1.154 × age-0.203 × …”这种毫无结构的文本。这种情况我一般是通过“分数线检测”来纠正在图片上检测横贯分子区域的长横线以横线为界分上下两个区域重新组织LaTeX结构。这个操作在OpenCV里实现很简单但对OCR结果的改善非常明显。6. 自动识别不靠谱时的兜底机制别让流程卡死在边界公式上任何自动化流水线都会遇到边界案例。比如有些扫描版PDF的公式区域分辨率过低字体严重扭曲有些公式包含复杂的矩阵符号、花体字母、特殊医学符号识别模型完全没有训练数据。遇到这种情况强制自动化只会产出错误结果而错误结果用在医学文档里比“没有结果”还要危险。所以我在设计这套方案的同时就规划了三层兜底机制。第一层兜底是“人工复核小工具”。我做了个极简网页后端把每个公式块的识别结果和原图并排显示操作员可以勾选“通过”或“需要修改”修改后的LaTeX直接回填到数据库。这个工具本身不复杂但切中了医疗文档对准确性的核心要求。第二层兜底是XHEDITOR内的LaTeX手输面板。对于那些识别了几次都不对、人工也没耐心改的公式我在编辑器工具栏加了一个入口弹出LaTeX编辑器输入源码立即预览渲染效果确认后以MathML插入。对熟悉LaTeX的人来说手敲一个eGFR公式比在一堆识别结果里修修补补更快。第三层兜底是图片快照。如果以上两层都搞不定就把原公式区域渲染成高分辨率PNG/SVG直接作为图片插入XHEDITOR对应位置同时在文档的隐藏属性里记录状态为“待人工替换”。这样科室拿到手时至少所有公式的位置和外观是正确的只是个别公式暂时不可编辑。后续如果识别能力升级或有人工空闲再替换成结构化公式。说到底医疗信息化项目里导入PDF公式这件事本质不是某个单一工具的调用而是一条需要结合PDF解析、OCR识别、格式转换、编辑器扩展的完整链路。我在把这个方案交付给科室后实际统计数据是约75%的公式能全自动完成结构化导入另有20%经过人工复核修正后导入只有5%左右走了图片快照兜底。这个比例对真实业务场景来说已经是科室愿意接受、临床人员愿意用的状态了。如果一开始就不做形态拆解试图用一个工具通吃全部PDF大概率会在文本乱码和图片识别之间反复横跳最后项目收不了尾。最后再分享一个我个人的运维经验这套流水线不要做成一次性的批处理脚本就完事最好把它封装成一个可接收PDF、输出结构化公式的服务接口后面再有新的检验手册、药物手册传入时直接调接口就行。医院里这类PDF文档只会越来越多把链路固化成服务才能在一轮轮新需求中省下重复开发的时间和心力。