在医院信息化行业摸爬滚打这些年我被人问得最多的一句话就是医生那边拿过来的Word到底怎么才能干净地弄进咱们系统里。问这话的有信息科刚入职的年轻人也有集成商里天天被项目追着跑的实施工程师。这句话往深了挖就是在问医院信息系统到底需要哪种Word导入组件以及这套组件在HIS、LIS、电子病历、病案归档这些真实场景里能不能扛得住医疗文书这种特殊文档的折腾。今天这篇文章不打算给你绕概念就按我实际做过的项目和排查过的故障来聊。从医院真实的Word导入场景出发把组件选型、技术路线、Java集成实操、常见踩坑一次性讲透。准备接手医院信息化项目或者正在被Word导入问题折磨的朋友读完应该能少走不少弯路。1. 医院信息系统中的Word导入到底在导什么1.1 看似是上传实际是一条完整管线很多刚接触医院项目的人把Word导入想象成“用户选个文件点上传完事”。真在医院环境里干过就知道事情远没这么简单。一份来自科室的Word文书从点击“导入”按钮那一刻起后面往往还跟着一串动作内容要解析出来做结构化存储格式要转成PDF版本用于预览和归档敏感信息要做脱敏处理操作记录要写进审计日志有些场景还要自动提取标题、患者姓名、住院号存到数据库里。也就是说Word导入组件不是“上传组件”而是“文件接收—内容解析—结构映射—存储归档—预览回显”这条完整管线里的核心环节。管线里的每个环节又互相牵连。解析做得不干净结构化存储就是空壳格式还原不到位归档PDF就没法看如果解析组件还会改字体、改段落那后面病历质控、科研检索全都跟着遭殃。所以选组件之前先要把这条管线画出来确定你真正要的是哪一个环节的“导入”。1.2 医院Word文档的“乱”乱到什么程度我在实施现场见过五花八门的医疗Word文档可以这么说文档兼容性测试不做个几百份真实样本你根本想象不到它能乱成什么样。首先是格式层面.doc和.docx并存。老一点的科室还在用Word 2003甚至WPS早期版本另存出来的文件后缀是.doc内部结构却是另一种写法。其次是内容层面有的文书直接从第三方病历软件导出来页眉页脚带着医院logo、科室名称有的病程记录里有MathType公式、域代码、批注、修订痕迹有的会诊单表格套表格三层嵌套下来行列宽全乱。更要命的是同一台电脑上装了Office和WPS用WPS改过的Word再拿Office打开标题样式就变。还有医生为了排版方便用大量空格和回车撑版面你看着排版是对的但程序读出来全是空段落和空白字符。准备选组件前建议先去医院信息科要一批真实脱敏文档当测试集谁能在测试集上稳得住谁才配进短名单。1.3 导入后的数据要流向哪里搞清文档去向才能决定导入组件的侧重点。常见的流向有这么几种电子病历系统要求内容完整、样式还原因为病历是法律文书格式不能乱。病案归档系统更看重转PDF的清晰度和页数一致性要能按页归档。第三方集成平台通常是异构系统之间传文档要求解析出的文本干净方便做数据交换。全文检索库比如科研检索、病历检索需要把Word里的文字提取成可检索的纯文本。临床数据中心CDR要从Word里抓关键字段比如诊断、主诉、过敏史这要求组件支持按段落或表格定位提取。不同流向对组件的要求差异很大。如果你只是想做全文检索一个Apache POI够用如果要做高保真预览和病历归档那很可能得配Aspose.Words或者PageOffice这类商业组件。所以选型前先回到数据流向上画个图比什么都管用。2. 选组件前先用四个问题把需求问清楚2.1 四个问题确认你的真实需求每次在医院项目里做技术选型我都会逼着需求方先回答四个问题回答完选型方向基本就出来了。第一个问题你要的是“内容”还是“版式”要内容就选轻量解析组件把文字、表格、图片提取出来即可要版式就要选能保留页眉页脚、字体字号、页面边框的高保真组件。第二个问题Word文件是用户手动上传还是服务端自动批量处理手动上传可以接受客户端插件模式比如PageOffice服务端批量处理就必须用纯服务端方案POI、Aspose、Spire都行但PageOffice这种依赖桌面Word环境的就不适合。第三个问题是否需要和Office/WPS桌面端联动有些场景是医生在浏览器里点“编辑”直接调起本地Word改文书改完保存回服务器。这种需求基本只能选PageOffice这类客户端插件方案纯服务端组件做不到。第四个问题医院现有系统是什么技术栈Java系用POI/poi-tl/Aspose很顺手.NET系用Spire.Doc的.Net版本更舒服如果前端又涉及在线预览可能还要叠加一个转换服务。技术栈不匹配再强的组件也白搭。2.2 医院项目里容易被忽略的硬性要求除了功能需求医院环境还有几条硬杠杠是普通项目里很少遇到的。第一是审计留痕。医疗文书涉及患者隐私导入组件的操作日志必须能记录到“谁在什么时间导入了哪个文件”而且日志不能被普通管理员随便改。选组件时要看它是否提供文件操作事件回调或者能否在Spring Boot服务层接入审计框架。第二是数据安全合规。医院系统基本都要过等保测评Word导入环节常见要求包括上传过程加密传输、文件内容脱敏、临时文件不落地或落地即清理。一些在线Word转换网站虽然方便但涉及患者数据的文档绝不能传到外部服务这个红线必须划死。第三是国产化适配。现在是越来越多的医院在推进国产化终端和国产数据库。如果医院信创要求明确组件的选型范围就要向能跑在统信UOS、麒麟系统上的方案倾斜纯桌面插件类方案可能直接出局。第四是终端环境差异。同一个医院里可能同时存在Windows 7、Windows 10、Windows 11Office 2010到Office 2021什么版本都有还有一堆人用WPS。客户端插件方案受终端环境影响极大实施时要有心理准备。2.3 服务端解析与客户端插件的路线之争Word导入组件本质上有两条技术路线服务端解析和客户端插件它们之间的取舍贯穿整个选型过程。服务端解析典型代表是Apache POI、Aspose.Words、Spire.Doc。优点是部署集中、无需在医生电脑上装插件、批量处理能力强、容易做审计和脱敏。缺点是对复杂排版和桌面端交互的支持偏弱比如你想在浏览器里像操作本地Word那样改表格服务端解析方案做不到。客户端插件典型代表是PageOffice。优点是版式还原度极高可以调用本地Word/WPS的完整编辑能力适合“在线编辑、留痕、套红”这类办公场景。缺点也明显每台终端都要装插件Office和WPS版本差异会带来大量兼容性工单一旦医院统一推送了新的Office补丁线上文书编辑功能时不时就会出幺蛾子。一线项目的经验是混合方案最稳页面预览和归档用服务端转换复杂文书的在线编辑用客户端插件。两个方案中间用一个抽象接口隔开后面对接不同组件时改造量能小很多。3. 主流Word导入组件横向对比与选型建议3.1 Apache POI / poi-tlJava项目里的免费主力Apache POI是目前Java生态里最常用的免费Word解析库支持读写.doc和.docx能提取段落、表格、图片、页眉页脚。优点是不依赖任何商业授权社区活跃踩坑资料多缺点是API偏底层开发量很大直接拿它做复杂文档导入光是处理表格嵌套和样式还原就够写一阵子。poi-tl是基于POI封装的一个Word模板引擎专门解决“按模板生成Word”和“把数据回填到签章处”这类需求。它比裸POI好用得多标签语法简单还支持循环表格、图片、列表等。医院里常见的知情同意书模板套打、体检报告生成等场景用poi-tl开发性价比很高。需要提醒的是POI对复杂版式的还原能力有限。页眉页脚里带图片、文本域复杂、带宏的.doc文件解析结果和Word里看到的经常对不上。所以在选型阶段别拿简单模板测试POI一定要拿真实病历文书测。3.2 PageOffice浏览器里像操作本地WordPageOffice不是服务端解析组件它是一个浏览器端的Office编辑集成方案核心服务通常是部署在你自己的服务器上终端浏览器打开文档时会加载一个很小的插件然后调起本地Word/WPS进行编辑。它对版式的还原能力是所有方案里最接近“原始Office环境”的因为本质上就是本地Office在渲染。医院里做公文流转、会议纪要、协议签署这类需要保留红头和印章效果的业务PageOffice是常见选择。同时它还提供文件并发编辑控制、痕迹保留、手写签批这些很“办公化”的功能。代价也明确。终端要装插件浏览器要对插件放行Office小了会很卡顿Office版本升级后相关功能要重新适配。如果你只是想把Word导入后转成PDF完全没必要上PageOffice。3.3 Aspose.Words跨平台的版式还原标杆Aspose.Words是商业组件支持Java和.NET最大的特点是“无Office环境也能高保真操作Word”。服务端Linux环境下就能把Word转PDF、提取文本、生成复杂报告文档渲染效果在同类库里是第一梯队。医院里很多“难啃”的环节我都是拿Aspose解决的。比如把MathType公式所在的Word转成PDFPOI做出来经常公式位置错乱Aspose处理后就正常得多。又比如把带域代码和批注的Word清理干净再归档Aspose提供了专门API。它的缺点是商业授权费用不低而且商用项目必须按授权规则来别图省事用破解版医疗环境下授权不合规是要出大事的。3.4 Spire.Doc与其他国产组件Spire.Doc也是一个商业组件也有免费版但免费版会限制文档大小或页数医院正式环境建议购买商业授权。它的优点是API对.NET和Java都比较友好使用方式接近Aspose价格通常比Aspose低。国产组件里还有一部分是集成商自己封装的读写模块或者基于LibreOffice做的转换服务。这类方案免费、可控但是高风险也在可控性上LibreOffice对复杂Word排版的渲染和微软Office有差异可能出现“同一个文件Office打开正常LibreOffice转出来的PDF多了半页空白”的情况。如果要用LibreOffice建议提前拿真实样本做批量比对测试。3.5 一张表看清主流组件怎么选组件技术路线部署方式版式还原成本典型场景Apache POI服务端解析嵌入业务系统中等免费文本提取、简单表单解析poi-tl服务端模板渲染嵌入业务系统中等免费模板套打、结构化文书生成PageOffice客户端插件独立服务终端插件高依赖Office商业在线编辑、红头文件、会签留痕Aspose.Words服务端解析嵌入业务系统高商业Word转PDF、复杂版式解析、批量归档Spire.Doc服务端解析嵌入业务系统高商业内容提取、格式转换、报告生成LibreOffice headless服务端转换独立服务中高免费批量转PDF、跨平台转换选型逻辑其实很简单预算敏感、只要文本资料用POI要做模板套打用poi-tl要在线编辑而且接受终端插件选PageOffice要稳定转PDF和还原版式直接上Aspose想控制预算但又有商业组件需求Spire是折中项。最怕的就是用一个免费组件硬扛所有场景开发成本最后往往会超过商业授权的费用。3.6 辅助转换工具PDF转Word、公式图片转Word、批量盖章医院里的Word导入往往不是一个组件单打独斗周围还要配一堆辅助工具。PDF转Word就很典型。外院带来的纸质报告往往是扫描成PDF再传过来的系统想把它转成可编辑的Word就需要OCR识别版式还原。这个环节建议单独做服务别在主流程里同步阻塞。公式图片转Word也是常客很多医生发过来的Word里公式其实是图片这种条件下想再做公式计算或者转LaTeX就必须先识别。Word公式转LaTeX的场景主要用于科研论文整理目前主流的做法是解析MathType公式或OMML公式再用转换工具映射成LaTeX。还有批量盖章。很多医院有PDF、Word批量盖章的需求判断依据是正经商业软件或者自己用POI写不推荐拿内部患者数据去用来路不明的破解工具。盖章本质上是图片叠加自己写的话用POI在文档指定位置插入公章图片即可但要注意签章的法律效力和审计要求。4. Java实战搭一个能用的Word导入解析服务4.1 环境准备与依赖下面以Java生态为例演示一个可落地的Word导入解析服务怎么搭。我这边用的是Spring Boot 2.7JDK 8Maven管理依赖集成POI和poi-tl。实际依赖如下dependency groupIdorg.apache.poi/groupId artifactIdpoi/artifactId version5.2.5/version /dependency dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version5.2.5/version /dependency dependency groupIdcom.deepoove/groupId artifactIdpoi-tl/artifactId version1.12.2/version /dependency需要注意POI版本别乱升某些高版本对JDK有要求医院系统如果还跑在JDK 7上就老老实实选POI 3.x或4.x。还要提醒一件事poi-tl和POI版本不能冲突最好直接参考poi-tl文档里推荐的POI版本组合省得踩类冲突的坑。4.2 读取Word内容段落与表格一次性讲清第一步是解析Word正文内容让系统先能拿到文字。import org.apache.poi.xwpf.usermodel.*; import java.io.FileInputStream; import java.util.ArrayList; import java.util.List; public class WordContentReader { public static void main(String[] args) throws Exception { try (FileInputStream fis new FileInputStream(C:/test/病程记录.docx); XWPFDocument doc new XWPFDocument(fis)) { // 读取段落 ListString paragraphs new ArrayList(); for (XWPFParagraph para : doc.getParagraphs()) { paragraphs.add(para.getText()); } System.out.println(段落数 paragraphs.size()); // 读取表格 ListString tableRows new ArrayList(); for (XWPFTable table : doc.getTables()) { for (XWPFTableRow row : table.getRows()) { ListString rowCells new ArrayList(); for (XWPFTableCell cell : row.getTableCells()) { rowCells.add(cell.getText()); } tableRows.add(String.join(|, rowCells)); } } System.out.println(表格行数 tableRows.size()); } } }这段逻辑不复杂但有一个坑doc.getParagraphs()只能拿到文档主体的段落不在表格里的段落才是它返回的内容而doc.getTables()返回的是文档中所有表格但表格里的文字和表格外的段落是分开的两套对象。如果你想按文档顺序读取“段落表格”混合的真实内容需要用XWPFDocument的getBodyElements()方法遍历。import org.apache.poi.xwpf.usermodel.*; public class WordBodyReader { public static void main(String[] args) throws Exception { try (XWPFDocument doc new XWPFDocument( new java.io.FileInputStream(C:/test/混合文档.docx))) { for (IBodyElement element : doc.getBodyElements()) { if (element instanceof XWPFParagraph) { System.out.println([段落] ((XWPFParagraph) element).getText()); } else if (element instanceof XWPFTable) { System.out.println([表格] element.getClass().getSimpleName()); } } } } }这段可以确保你按实际排版顺序拿到内容处理回执单、检查报告这类图文混排文档时非常有用。4.3 表格列宽问题poi设置Word表格单元格宽度医院文书里表格特别多检验报告单、手术记录单、知情同意书都有大量表格。解析后如果还要在系统里重新生成表格列宽设置是绕不开的坑。直接用POI设置单元格宽度时很多人是把宽度值直接放进去结果打开Word发现列宽完全没反应。原因是Word的表格宽度单位和POI里的单位不一致。打个比方POI里的宽度通常以Twips为单位1厘米约等于567 Twips1英寸等于1440 Twips。如果你用像素值直接塞进去Word根本认不出来。正确做法是先把目标宽度换算成Twips再设置到每个单元格上并且最好每个单元格都设置光设表格对象不设单元格渲染时照样会变。下面是我自测过可用的设置方法import org.apache.poi.xwpf.usermodel.*; public class TableWidthFixer { // widthCm: 期望的列宽单位厘米 public static void setCellWidth(XWPFTableCell cell, double widthCm) { // 1厘米 567 Twips int widthTwips (int) (widthCm * 567); cell.setWidth(String.valueOf(widthTwips)); // 设置表格布局为固定宽度避免Word自动调整 CTTblWidth tblWidth cell.getCTTc().addNewTcPr().addNewTcW(); tblWidth.setW(java.math.BigInteger.valueOf(widthTwips)); tblWidth.setType(STTblWidth.DXA); } }经验之谈设置单元格宽度时最好把这个单元格所在列的所有单元格都设置一遍否则Word打开后仍可能因为“自动调整列宽”而重新分布列宽这也是热词里“word 表格列宽无法拖动”很常见的触发点。4.4 模板自动套打poi-tl从列表到结构化文书很多医院场景并不需要真正的“导入Word”再解析而是要把数据库里的数据套进Word模板里生成文书。比如住院病案首页、知情同意书、体检报告。这种时候用poi-tl最省事。poi-tl模板里可以用{{var}}这种占位符还支持用表格循环渲染数据。下面这个例子演示了如何把一份“患者列表”渲染进文书模板里的表格import com.deepoove.poi.XWPFTemplate; import com.deepoove.poi.data.*; import java.io.FileOutputStream; import java.util.*; public class WordTemplateFiller { public static void main(String[] args) throws Exception { MapString, Object data new HashMap(); // 普通变量 data.put(patientName, 张三); data.put(hospitalName, 某某市人民医院); // 循环表格数据 ListMapString, Object reportItems new ArrayList(); MapString, Object item1 new HashMap(); item1.put(itemName, 血常规); item1.put(result, 正常); item1.put(doctor, 李医生); reportItems.add(item1); MapString, Object item2 new HashMap(); item2.put(itemName, 肝功能); item2.put(result, 轻度异常); item2.put(doctor, 王医生); reportItems.add(item2); data.put(reportList, reportItems); XWPFTemplate template XWPFTemplate.compile(C:/模板/报告模板.docx); template.render(data); template.writeAndClose(new FileOutputStream(C:/输出/生成报告.docx)); } }模板文件里表格那行要写成类似{{reportList}}这样的标签poi-tl一旦识别到data里放的是List数据就会自动按列表行数复制表格行。这个功能在生成病情告知书、团队会诊记录这类“列表型”文书时特别有用。4.5 Word转PDF预览与字体处理Word导入后通常还要生成PDF预览版方便临床科室在线查看又不必让每台电脑都装Office。医院服务端多数是Linux这时用Aspose.Words最省心。核心代码只有几行import com.aspose.words.Document; import com.aspose.words.SaveFormat; public class WordToPdfConverter { public static void main(String[] args) throws Exception { Document doc new Document(C:/temp/原文件.docx); doc.save(C:/temp/预览文件.pdf, SaveFormat.PDF); } }看着简单但坑都在背后。第一个坑是字体。Linux服务器上没有Windows的宋体、仿宋、黑体等字体转出来的PDF经常出现“豆腐块”或者字体错位。解决方法是把医院常用的中文字体包传到服务器上安装到/usr/share/fonts目录并执行fc-cache刷新字体缓存。第二个坑是转换性能一个几百页的Word文档同步转换可能让接口变慢务必加队列或者异步线程池避免拖垮业务线程。如果你不想引入商业组件还可以用LibreOffice的headless模式做转换libreoffice --headless --convert-to pdf --outdir /tmp/output input.docxLibreOffice方案免费但渲染效果和Aspose差距客观存在尤其是复杂表格、页眉页脚、公式排版上建议用真实档案测试后决定。4.6 与Spring Boot整合的关键细节上面这些工具方法最后要用一个Spring Boot接口串起来。我的建议是不要把全部逻辑塞在Controller里至少分三层RestController RequestMapping(/api/word) public class WordImportController { private final WordImportService wordImportService; public WordImportController(WordImportService wordImportService) { this.wordImportService wordImportService; } PostMapping(/import) public Result importWord(RequestParam(file) MultipartFile file) { // 1. 文件基础校验 if (file.isEmpty()) { return Result.error(文件不能为空); } String originalFilename file.getOriginalFilename(); if (originalFilename null) { return Result.error(文件名不能为空); } // 2. 扩展名白名单校验 if (!originalFilename.endsWith(.doc) !originalFilename.endsWith(.docx)) { return Result.error(仅支持Word格式文件); } // 3. 文件大小限制建议单文件不超过50M if (file.getSize() 50 * 1024 * 1024) { return Result.error(文件大小超出限制); } // 4. 调用业务层处理 WordImportResult result wordImportService.doImport(file); return Result.success(result); } }Service层里要做的工作包括病毒扫描、文件名清洗、解析内容、生成PDF预览、落库最后把文件的MD5哈希值一并存下来方便审计。上传文件路径切勿用前端传来的文件名拼接防止路径穿越攻击。建议统一改成UUID命名原始文件名单独存字段。5. 医院环境下的常见问题与排查经验5.1 文件打开慢、关闭卡顿、内存不足医院终端电脑配置参差不齐有的老电脑跑个大型Word文档本身就卡连带着“导入”操作也一起变慢。这里有一个常见误区把客户端的卡顿归咎于导入组件其实是终端Office的问题。排查思路是先区分是“打开导入器卡”还是“导入器打开Word后卡”。如果是服务端转换卡多数是内存或转换队列的问题。一次导入几百页Word并转PDFJVM堆内存可能直接被撑爆报错就是热词里那个“内存或磁盘空间不足Word无法显示所请求字体”。应对方法是限制单文件大小、用异步队列削峰、给转换服务单独分配更高内存、及时释放临时文件还可以为Word转PDF单独部署一个独立服务避免影响主业务系统。如果是终端Word关闭时卡顿常见原因是加载项太多比如EndNote、MathType这些插件全挂在Word里。可以在终端上做一次加载项清理或者把这些第三方加载项改为按需加载。这个操作虽然不直接属于导入组件但在医院办公环境里排查频率极高。5.2 样式还原双栏空白、表格列宽拖不动、换字体变样医院文书很多是双栏排版曾在转换时发现一个状况Word里看起来正常的双栏文档导入后转PDF右栏下面多出一大片空白。这个问题的根源通常是文档末尾回车符太多或分节符设置异常。排查时可以先用Aspose.Words或LibreOffice重新打开原文件另存为一份干净副本再转如果问题依旧再检查分节符和分栏设置。表格列宽在导入后或模板生成后“拖不动”也很常见原因是表格属性被写成了“固定列宽”或者单元格宽度设置不一致。处理办法是统一用我前面提的Twips单位设置单元格宽度并且不要只设表头不设数据行。还有很多医生说“一换字体就变别的字体”这在导入解析里同样会出现根源是字体回退机制。比如原文档用“方正仿宋GBK”服务器上没有这个字体渲染时就会自动回退到系统默认字体。解决方法就是前面说的把医院在用字体全装到转换服务所在的服务器上。5.3 公式与特殊字符MathType、公式图片、LaTeX临床科研文档里大量使用公式但医院的Word文档里公式往往有几种形态MathType公式、Word自带公式OMML、图片型公式。MathType生成的公式在很多解析组件里读不到可编辑的公式代码只能读到图片或OLE对象。如果后续要转LaTeX用于论文排版建议先把MathType公式批量转成Word原生公式再用转换工具转LaTeX。Word自带公式可以直接用公式转换工具把OMML转成LaTeX语法准确率通常高于对MathType的识别。图片型公式就麻烦一些。如果真的只是图片那只能靠OCR公式识别市面上主流公式OCR方案基本都能识别印刷体公式但手写公式的识别率会明显下降。这种情况要提前和科室说清楚原始文档里的公式是图片的自动提取成可编辑公式后需要人工复核。还有一个偏门的坑Word公式后面输入内容靠上不跟公式底对齐。这个现象在Word里调整公式对象的位置和对齐方式就行但如果通过导入组件去操作公式很多组件不支持只能提示用户在Word端手动调整系统端不做强处理。5.4 宏安全、域代码与批注医院环境对宏安全格外敏感。来路不明的Word文件如果带了宏导入系统后如果还允许宏执行轻则污染文档重则感染终端。所以导入组件在设计上就要默认对宏做处理.docx文件能通过代码剥离宏.doc文件用POI处理宏的能力有限建议在上传网关层直接拦截或隔离。热词里总提“word宏安全问题”实际在医院也发生过用宏来骗取点击的情况。我的建议是三管齐下入口处杀毒内容解析时禁止执行宏终端策略默认禁用宏。再在导入流程加一个“宏安全检查”标识凡检测到宏的文档系统自动加标记让归档人员人工确认。域代码也是坑。病案首页、知情同意书里经常有TOC目录域、页码域、患者姓名交叉引用域。如果用POI直接getText()拿到的可能是域代码而不是域结果。解决办法是解析时用底层API读取“域结果”或者用Aspose之类的组件先updateFields再提取避免入库内容是空壳。批注和修订痕迹在导入时同样要处理。按规范归档前应接受修订删除批注防止历史批注泄露讨论信息。用Aspose.Words清理批注和修订是常规操作POI对批注的支持较弱所以涉及归档场景时我一般倾向选择商业组件。5.5 字体缺失与自由字体乱码“word安装字体还是不行”这种问题在系统集成场景里经常不是因为终端没装字体而是因为服务端没装字体。一个典型场景是医生在Windows上用方正仿宋GBK写好文书上传到Linux转换服务转PDF结果PDF里显示成宋体。原因是Linux服务器没有方正仿宋GBK字体回退机制自动选了替代品。解决步骤很简单把医院常用字体文件拷贝到服务器放至/usr/share/fonts/目录执行fc-cache -fv再重启转换服务。这里有个坑方正仿宋GBK这类字体有授权限制医院环境要确保字体授权合规不能随便从网上下个ttf就用。Mac环境也有类似问题。不少医生用Mac处理Word系统自带字体和Windows差异很大于是“mac word如何下载方正仿宋gbk”之类的问题层出不穷。这属于终端维护问题最有效的办法是统一字体清单由信息科统一下发不能指望每个医生自己解决。5.6 医院Word导入问题速查表症状可能原因处理建议导入后文字丢失Word含有域代码或嵌入了OLE对象用高层组件读取域结果OLE对象单独提取转换PDF后多空白页分节符异常、末尾回车过多用组件清洗文档后转换或调整分节逻辑表格列宽拖不动固定表格宽度被错误写入检查并统一Twips宽度设置字体变成默认体服务端缺字体安装医院字体并刷新字体缓存打开或关闭Word特别慢第三方加载项过多清理Word加载项按需加载文件导入报内存不足文档过大或JVM内存不足限制文件大小、使用异步队列、加大内存公式显示成图片原文件就是图片公式公式OCR识别人工复核文档有宏来源不可信入口杀毒解析时禁用宏归档标记批注和修订被入库未清理修订痕迹归档前统一删除批注、接受修订6. 关于选型我想再多说两句组件的选型问题说到底是在“成本、体验、可维护性”之间找平衡。我见过不少项目在Word导入组件上为了省一点授权费结果开发人力搭进去几倍成本或者上线后被医生天天抱怨文书排版不对最后被迫返工。也有项目一上来就买最贵的商业组件结果发现根本不需要那么高的版式还原能力白花冤枉钱。我个人现在的习惯是先收集100份以上真实医疗文档做一个两天的对比测试把每个候选组件在这批文档上的解析成功率、转换耗时、排版还原度列成一张表再开会拍板。测试集里一定要包含带公式、带表格、带页眉页脚、带批注修订、带宏的老旧.doc文件这些东西才是医院系统真正会遇到的“硬骨头”。多说一句关于文档处理的小技巧导入组件解析之前先把原始Word文件备份一份并计算MD5存库。后面万一解析有问题至少还能回溯到原始文件不至于把唯一一份法律文书改坏了。在医疗行业做事“留底”这个习惯永远不吃亏。
