最近自己搞些小东西，需要用json文件存储些文件属性什么的，但是发现用json包里的/book/gywxw/","description":"大学刚毕业，她嫁给了林安森可是结婚三年，电视上常看到他出席各种场合携女相伴，她却再没再亲眼见过他。"}

随着高校信息化建设的高速发展, 越来越多的电子文档出现在日常的工作中, PDF作为电子文档归档的首选格式, 在文件格式的保存完整性方面和平台兼容性方面有显著的优势^[]. 本电子文档归档管理系统的研发主旨是将采购管理平台的文档管理与档案归档管理过程合并成一个整体, 解决电子文档流转过程中信息化管理缺失的情况, 同时提出一种对电子文档元数据自动提取来代替传统的手工提取元数据, 并且建立索引库, 为大数据分析奠定了基础, 同时为学校今后的工作决策提供依据.

国内对元数据提取的相关探索起步较晚, 主要研究方向也集中在基于正则表达式和基于规则的元数据提取的相关研究^[-]. 2001年贺亚锋首次将元数据提取的相关研究带入到中国^[], 主要对两种常用的基于网站的元数据的自动生成进行了介绍, 并对ROADS元数据编辑器和MeatWeb元数据生成器做的使用和原理进行了深入的阐释^{[, ]}.

2004年, 王守芳等提出了如何从HTML文件中提取元数据的方案. 该方案主要是基于规则模板, 通过对HTML文档进行分词, 配合使用归约算法实现元数据的自动提取^[]. 该方法虽然对元数据提取的准确性却并不太高, 但基本可以实现HTML文档元数据的自动提取.

2007年, 于江德等首次将条件随机场应用在中文论文的元数据提取上, 该方法主要通过利用论文中换行符、回车符等标志性符号对论文内容进行分割, 然后应用条件随机场对分割内容进行元数据抽取^{[, ]}. 该方法对于学术论文的论文头中的元数据的提取具有比较高的准确度, 可以高达90%, 但是该方法也局限于论文的头部进行元数据的提取操作.

2017年, 杜秋霞等为了地名文化遗产的保护将隐马尔可夫模型应用在提取文献中的地名元数据上^[]. 该方法主要通过对电子文档的地名关键词的标注, 然后对文本进行分割, 进而对元数据进行提取. 该方法可以对文献中的地名进行比较细粒度的抽取, 相比传统地名提取的准确度明显提升, 但该方法却无法对消失的地名准确的进行抽取.

通过阅读相关的文献, 研究对比目前流行提取PDF元数据的各种方式, 结合实际需求提出一种最适合本课题的提取方法. 通过对Flask框架的学习, 以模型驱动工程的思想设计实现一款基于Python的能够自动、高效、准确地提取PDF中元数据的电子文档归档管理系统.

目前线下归档流程仍旧是文档在各部门之间通过复印和填写文档属性表格资料的方式传递. 职能部门为执行科研项目建立文档库, 将其他各类格式的电子文档和实体文档转换或扫描成PDF格式保存, 同时在项目执行过程中不断更新该文档库, 项目完成后发起归档任务将数据迁移至档案部门审核, 然后根据项目分类存入对应的档案系统中^[-]. 期间需要经历很多繁琐的流程, 而且还有诸多弊端: (1)项目庞大, 涉及的供应商有多家, 文档的完整性无法保证; (2)项目执行过程只有职能部门参与其中, 对归档工作没有一个过程把控的机制, 档案部门只是在归档任务发起才参与进来; (3)归档任务通常集中在年末, 会积压大量的资料, 这就势必在文档流转审核过程中产生错误和审核不严格的情况.

因此, 需要将归档管理功能一并纳入一站式采购平台且做进一步的完善. (1)增加文档数据导入功能, 保证项目执行期间文档实时保存; (2)增加监督审核机制, 保证上传电子文档的准确性, 避免项目后期返工的情况; (3)增加电子文档元数据提取功能, 解决目前针对海量数据缺乏大数据分析的情况. 这样电子文档管理和归档管理就涵盖了整个文档生命周期, 如所示.

2 系统概要设计 2.1 系统基本思想

(1)系统以形成高校一体化的信息高度集成为基准, 设计标准数据接口防止信息“孤岛”的产生, 做到新系统与一站式采购管理平台的无缝结合^[-].

(2)出于对安全性的考虑, 系统对数据库管理要采取必要的定期自动数据备份、防灾预案和数据恢复等措施; 在数据传输方面要充分利用校园数据交互中心的标准接口, 确保系统数据的安全性、可靠性和一致性^[]; 对所有用户的权限必须要有有效的管控机制(如: 归档角色、审批权限).

(3)设计阶段充分考虑后期需求的变化, 系统后台配置应具备灵活性, 例如需要增加新的文档属性项时只要通过系统后台配置即可, 无需修改系统程序和数据结构.

根据需求分析和设计思路可以得到系统的用例图, 如所示, 将本系统分为项目文档整理、检索与统计、移交接收管理和系统管理4个功能区.

(1) “项目文档整理”包含6项子功能: 文档导入(自动导入、人工录入、本地导入), 文档补充, 项目信息补录, 删除文档, 文档格式转换, 文档元数据提取.

(2) “检索与统计”包含4项子功能: 归档任务进度查询, 电子文档查询, 数据统计, 报表管理(包含模板管理).

(3) “移交接收管理”包含3项子功能: 预审, 资料移交审核, 归档内容审核.

(4) “系统管理”包含3项子功能: 用户和权限配置, 文件扩展属性管理, 各类标准接口配置.

在大数据背景下, 要求应用系统具有高性能、弱事务的特性, 因此数据结构需要以横向扩展的方式进行分布式存储, 数据模式多元化, 数据相对独立存在. 通过功能业务分析电子文档归档系统并非事务性系统, 为了使本系统在扩展性、并发处理和读/写方面更有优势, 而且需要考虑到系统后期的升级与功能扩展, 摒弃使用传统关系数据库, 采用MongoDB半结构化的非关系型数据库, 它有着分布式的存储架构, 这样数据之间分散存储更容易扩展, 数据库不需要事先定义数据字段, 可以随时自定义写入数据的格式. NoSQL来处理大量多元化数据存储运算与高并发访问有更显著的效果^[-]. 数据库采用1主节点+1副节点+1仲裁节点的基本架构, 以减轻数据服务器的访问压力, 同时提升容灾能力, 如所示.

3 系统对象模型的建立 3.1 业务逻辑分析

通过对实际业务进行系统建模更有利于把握系统的整体格局, 在更高的抽象水平上考虑系统的设计, 而不是程序编码, 这样可以降低前期出错率, 缩短系统实现的周期^{[, ]}. 由于篇幅有限仅以文档迁移导入为例, 其包括的主要功能: 文档锁定, 项目移交接收, 文档信息补充, 本地导入, 具体业务逻辑如所示.

3.2 类定义与类间关系

根据模型驱动工程的思想方法, 首先建立系统的对象模型, 接着通过对象模型建立系统类集, 并对每个类都定义属性和操作方法, 如所示.

(1) ModelManager属于EJB类, 封装的组件为前台与服务端的交互提供数据访问接口.

(2)公共类(ConDefiner), 它主要封装了基本查询、第三方插件调用和翻页等方法, 前台只需要实例化这个类就能继承并使用.

(3)对象抽象类: 将实体类AmObject类作为系统Model类的基类, Model类就是把数据库的字段映射为各类中各个对象的属性, 为模型操作类提供数据来源.

(4)数据操作抽象类: 将AmObjectDAO类作为数据操作类的基类, 除了从父类AmObject继承的一些通用对象数据操作, 还自定义特殊的数据对象操作方法. 如所示.

3.3 数据操作类的逻辑实现

利用UML序列图能描述对象间的交互和消息传递顺序的特性, 完成系统核心功能模块对象间的输入输出. 以文档迁移导入、文档数据补充、本地导入和移交接收的逻辑实现为例.

文档迁移导入设计思路: 根据前台应用操作通过EJB类调用文件模型操作类的具体方法, 数据库返回对应的项目列表. 对项目列表内的项目文件进行锁定操作, 调取文件模型操作类的Lock()方法. 前台应用根据界面操作选择锁定后的项目, 调取文件模型操作类的Move()迁移方法, 对项目列表内的对象迁移至归档任务库, 如果迁移未成功的文件仍保存在项目资料库, 文档迁移导入模块序列图如所示.

数据补录的设计思想: 前台应用通过EJB层调取文件模型操作类的ReInput()方法, 同时利用对象模型类显示对应的操作界面, 并写入到数据库. 本地导入的设计思想: 前台应用通过EJB层调取文件模型操作类的LocalImport()方法, 本地导入数据直接写入归档任务库. 移交接收的设计思想: 前台应用通过EJB层验证用户身份权限, 同时调取归档任务操作类的Check()方法, 如果操作成功则返回审批意见信息并写入归档任务库, 等待后续的归档完成操作, 否则返回驳回信息并告知原因.

最后通过使用UML建模工具IBM Rational Architect绘制系统主要功能模块的时序图和类图, 有助于完成后续系统框架设计和编码工作.

4 系统核心功能实现 4.1 系统框架设计

目前基于Python的Web开发的框架有很多, 例如: Flask、Django和Web2Py等. Django如同Java的EJB (Enterprise+JavaBeans+JavaEE服务器端组件模型)多被用于大型网站的开发, 而且所有资源每次都要全部加载, 造成一定资源的浪费. 对于大多数的小型网站的开发, Web2Py的管理接口没有权限, 没有内建的单元测试, 不方便系统的调试. Flask的优点是保持代码简洁且具有很强的扩展性和兼容性, 通过框架后台的自由配置, 可以使归档管理系统支持表单验证、权限判断、数据库操作等基本功能, 更符合本系统的实际需求^[,].

本系统项目归档操作, 元数据提取和审核管理作为核心功能模块, 数据传输/转换接口则作为与一站式采购管理平台及其他信息系统间联系的桥梁, 如所示. 利用Flask框架的核心库Werkzeug的Cookies和Session组件解决多个用户快速响应客户端推送过来的访问请求, 提高用户访问速度. 同时, 系统构建HTML页面和数据绑定模式, 使用knockout.js (一个基于MVVM模式的JavaScript库), 通过将UI和基础JavaScript模型绑定, 做到模型和UI同步更新. 通过调用Jinja2提高系统安全, 将变量名中含HTML自动转义, 但如果是安全的变量名则利用safe过滤器标记为安全, 这样能够很好控制外部的脚本攻击, 而且也避免全部转义所带来的资源占用.

4.2 元数据提取模块设计实现

对PDF文档进行数据提取的方法有很多, 比如使用OCR文字识别软件对PDF文档中的关键信息进行提取^[], 利用Adobe Acrobat所提供的接口编写Plug-in程序实现对PDF元数据提取^[], 或者Adobe Acrobat X Pro自带的工具对页面文本进行识别提取^[]. 但这些方法对PDF文档的操作太过于繁琐, 后续还要人工对所提取的元数据做进一步处理, 故只适用于处理少量文档的情况, 对于体量庞大的归档文件元数据提取则不合适. 目前比较流行的做法是采取调用已有的PDF类库对大量文档进行批量操作, 基于Java类库比较常用的两种操作是iText和PDFBox.

有部分版本升级后还需要更改中文包的名称和存放路径才能正常使用.

LucencePDFDocument.getDocument()方法将指定PDF文档, 提取其内容(包含作者信息和关键词等元数据)并创建一个Lucence文档对象, 这样添加到Lucence索引中的这些元数据方便进行跟踪, 但由于Lucence创建的索引只支持文本索引, 而且创建全文索引也消耗大量资源.

PyPDF2是基于Python开发的函数库, 它提供对PDF进行提取元数据和图片、拆分或合并等基本操作, 同时还能编写脚本完成对PDF文档的批量操作, PyPDF2包可在任何Python平台上运行, 而且不依赖于其他外部库的配合. 它可以完全在StringIO对象而不是文件流上工作, 允许在内存中进行PDF操作提高执行效率, 而且新版本PyPDF4功能更趋于完善, 相对比较前两种PDF元数据提取的方式, 此方法更符合本系统的要求, 综上所述, 因此决定使用基于 Python的PyPDF2来解决PDF元数据提取的功能.

利用PdfFileReader对象的getDocumentInfo()方法得到PDF文件元数据, 接着利用for语句遍历字典的键值对. 此时docInfo的实例包含了大部分信息, 可以使用这些属性从文档中获取所需的其余元数据, 将这些数据存放至数据库以备将来使用. 尝试导入单个PDF文档验证程序的可行性和元数据提取准确度, 结果如所示. 最后, 添加OptionParser方法使脚本只解析我指定的文件元数据, 同时完善代码将提取到的元数据按一定的格式显示, 部分代码如下所示:

本应用通过校园身份统一认证系统验证才可登录如所示, 登录后根据用户权限显示不同的首页界面, 如所示为具有文档审核权限的用户.

针对目前学校电子文档管理和归档管理的现状, 以及整个电子文件生命周期的深入分析, 提出了对现有一站式采购管理平台进一步完善的设计方案. 本系统遵循模型驱动工程的研发过程, 从需求分析、系统设计、系统建模和核心功能逻辑设计本文做了详细介绍. 此方案为全校提供了一个功能完整, 数据安全, 高效, 顺畅的一体化归档平台, 为解决学校归档业务全部流程信息化的最终目的打下了基础.

下一阶段研究方向, 对系统的几个方面进行改进: (1)提高PDF元数据提取技术的精准度, 目前的元数据的提取不够全面, 不利于资源搜索的效率, 需要进一步优化相关算法. (2)文档转换要增加OFD格式, OFD标准是我国2016年自主研发的版式文件格式, 现在还在大力推广中, 今后很有可能替代PDF成为我国电子文档归档标准格式. (3)进一步提升本系统响应时间、吞吐率、并发用户数等方面的性能.