简介《技术人员劳动合同》是一份依据《中华人民共和国劳动合同法》编写的企业用工法律文书范本面向企业HR、法务人员及中小企业管理者用于规范技术类岗位聘用关系解决合同条款不完整、派遣用工约定模糊等常见问题。压缩包内共1个文件为19KB的doc格式文档共6页包含固定期限合同、试用期约定、计件/计时工资计算、工时要求、社会保险缴纳、劳动保护与职业危害防护、规章制度约束、合同变更解除终止流程以及劳务派遣协议告知等完整条款。全文预留了单位名称、劳动者信息、合同起止日期、派遣期限及工资标准等填空位便于根据实际情况直接修改使用。已有55人浏览学习。该合同还明确了双方签字盖章及一式三份的存档要求能为企业规范用工、防范劳动争议提供直接参考。1. 技术人员劳动合同.doc一份被反复打开却从未被读取的合同文件在技术团队的共享目录里总有一份文件从建队第一天躺到现在名字叫“技术人员劳动合同.doc”。入职时它被双击、打印、签字然后回到文件夹等到统计合同到期、核对岗位职级、给 HR 系统同步数据时所有人只能逐份打开、肉眼查找、手工录入。这个文档后缀暴露了它和现代 .docx 的本质差异.doc 是 97-2003 时代的 OLE 二进制容器里面装着文本、表格、样式甚至签名图片却不能用 python-docx 直接打开。文章后面会用 catdoc、LibreOffice、Git LFS 和一段校验脚本把“技术人员劳动合同.doc”从人肉查件变成结构化数据适合正在做合同自动化、文档清洗和 HR 系统对接的研发、运维与 ITBP 读者。2. 技术人员劳动合同.doc 的格式底细一个 OLE 容器装着文本和表格2.1 为什么 python-docx 打不开这份 .doc很多第一次处理合同的人会直接写Document(技术人员劳动合同.doc)然后被报错砸懵。原因是 .doc 和 .docx 内部结构完全不同。.doc 是微软老式 OLE2 复合文档它像一个小型文件系统里面按目录存放 WordDocument、SummaryInformation 等流而 .docx 本质是 ZIP 压缩包用 Python 标准库 zipfile 就能读出 document.xml。python-docx 从名字到实现都只认后一种所以遇到 .doc 会抛出 ValueError 或包结构错误。这个区别不是版本号那么简单OLE 流里混着字体、样式、修订记录和图片直接按字符串读取无法稳定拿到正文。我会先跑file确认文件真实格式file 技术人员劳动合同.doc正常输出会包含Composite Document File V2。如果显示Microsoft Word 2007或Zip archive说明镜头是 .doc实际是另存的 .docx处理方式完全不同。还有一种常见伪装某些办公软件会把文件另存为 Word XML 或 RTF但扩展名不改file这时候能一眼识破。2.2 先用命令行把文本提取出来catdoc 与 antiword在没有 LibreOffice 转换之前最快路径是抓老格式文本的命令行工具。我常用 catdoc 和 antiword。它们体积小适合在脚本里快速抓词但侧重点不同。装包和提取命令sudo apt install catdoc antiword catdoc -d utf-8 技术人员劳动合同.doc contract.txt antiword -m UTF-8.txt 技术人员劳动合同.doc contract_anti.txt-d utf-8指定输出字符集为 UTF-8-m UTF-8.txt是 antiword 的字符映射文件不指定时中文大概率变成下划线或方块。catdoc 对表格文字比较友好会按单元格顺序拼出文本antiword 保留段落的换行相对准确但对中文编码的支持依赖映射文件版本。如果源文件是 GBK 内部保存输出 UTF-8 里可能看到正常中文如果出现å¯è®¢这种乱码多半是内部编码与工具默认编码不一致先尝试-d gbk或者检查源文件是否被 WPS 多次另存过。提取结果只是纯文本不会有下划线和排列但足够做关键词匹配。输出往往长这样甲方北京某某科技有限公司 乙方张三 岗位Java 高级工程师 合同期限2024-01-01 至 2026-12-31这些工具不会区分“甲方信息”和“乙方签字附件”所以只适合文档量少、字段明确的场景。2.3 纯文本提取的边界表格和版式会丢在哪里工具是否保留表格结构中文支持适合场景catdoc不保留按顺序输出需指定 -d抓取纯文本关键词antiword不保留换行较好需映射文件保留段落阅读顺序LibreOffice 转换保留好后续自动化解析python-docx保留到 docx好读取段落和表格对象纯文本工具能回答“合同里有没有赔偿条款”但回答不了“第三条和第四条在哪个单元格里”。如果需要定位、回填纯文本路径会在正则阶段失控因为合同模板往往在表格里嵌段落单元格的边界一旦丢失提取的结果会对不上原文。我在做批量处理时2.2 的提取只用于快速预览真正的结构化解析会交给第 3 章的转换方案。catdoc 与 antiword 对“技术人员劳动合同.doc”这种中文文件名处理没问题但用 shell 通配符时要注意避免文件名字节不一致导致的误展开。3. 用 LibreOffice 中转让技术人员劳动合同.doc 变成更容易处理的文档3.1 最可靠的不是解析而是转换不偏执于直接解析二进制是因为即使请出 olefile 也只能拿到 WordDocument 流还得再解码而且表格、格式、页眉页脚分散在不同流里维护成本远超收益。常见做法是先用 LibreOffice headless 模式把 .doc 转成 .docx再由 python-docx 读取。这个方案跨平台Linux 服务器上也能跑对中文支持较好也不会改动原文件。转换命令libreoffice --headless --convert-to docx --outdir ./converted 技术人员劳动合同.doc--headless表示不开图形界面--convert-to docx是目标格式LibreOffice 会根据扩展名推断 filter 名如果想指定更严格的 OOXML可以写成docx:MS Word 2007 XML--outdir ./converted指定输出目录不加则输出到当前目录。转换完成后同目录下会生成“技术人员劳动合同.docx”原 .doc 不会被改动。如果输出文件没出现先看进程是否被杀以及是否第一次运行时初始化过 profile 目录。LibreOffice 一次只能跑一个实例批量调用时要串行或者用--convert-to传入多个输入文件并等待前面进程退出。3.2 Python 解析转换后的 docx表格与段落双管齐下转换完成后处理就简单了。python-docx 把文档内容分成paragraphs和tables两条线合同模板里既有无边框段落又有表格所以两边都要遍历from docx import Document doc Document(converted/技术人员劳动合同.docx) lines [p.text.strip() for p in doc.paragraphs if p.text.strip()] for line in lines: print(line) for table in doc.tables: for row in table.rows: cells [c.text.strip() for c in row.cells] print(cells)doc.paragraphs返回顶层段落不会包含表格里的段落doc.tables只返回顶层表格表格嵌套时cell.tables才能继续下沉。如果你发现 cells 的长度与列数不一致先检查 row.cells 是否包含了合并单元格的重复引用这是合并单元格的常见坑不能直接用 row.cells 的数量当作真实列数。有了这些文本后可以用正则抽取最常用的合同要素。例如import re pat re.compile(r(?:甲方|乙方)[:]\s*(.)) for line in lines: m pat.search(line) if m: print(m.group(1)) pat_date re.compile(r(\d{4})[年\-/](\d{1,2})[月\-/](\d{1,2})日?)(?:甲方|乙方)是分组但不捕获[:]兼容全角冒号和半角冒号\s*吃掉空格最后(.)捕获整行内容作为单位名称。日期正则把年、-、/都当分隔符注意“2024年1月5日”和“2024-1-5”都能匹配。这两个 pattern 只是起点真正遇到合同条款里写“甲方的联系电话”时会误匹配后来到第 5 章做校验。常见字段配正则可以按这种粒度做字段示例正则说明合同编号(?:编号|No\.?)[:]\s*([A-Z0-9\-])兼容大小写和点岗位名称(?:岗位|职位|拟担任)[:]\s*(.)可能出现在表格薪资标准(?:月薪|薪资)[:]\s*([0-9,.])先提取数字串合同到期(?:至|到)\s*(\d{4})年(\d{1,2})月(\d{1,2})日注意“至/到”用字这些正则不是万能字段值可能被换行拆开也可能表格里的文字被拆分到多个段落所以要在提取前把表格 cell.text 与段落文本一起拼成一个有序文本块。把 lines 列表用\njoin 成一个字符串配合re.MULTILINE模式及^锚点能减少跨行误判。3.3 如果不想多一步转换直接读 OLE 流的边界如果环境不允许装 LibreOffice也可以在 Windows 上用 pywin32 调用 Word COM 接口import win32com.client word win32com.client.Dispatch(Word.Application) doc word.Documents.Open(path) doc.SaveAs(new_path, FileFormat16) doc.Close() word.Quit()FileFormat16对应 wdFormatDocumentDefault也就是 docx。这条命令不依赖 .doc 版本但要求机器安装过 Microsoft Word不适合生产服务器。更底层的做法是用olefile打开 .doc 后读取WordDocument流再手工按偏移量找文本的 UTF-16 区间这需要对 WordBinaryDocument 格式有较深了解。我在实际项目里只用过一次因为表格结构在二进制流里重建成本太高而且源文件经 WPS 另存后偏移量会变化。转换一步能节省后面十步。4. 批量处理团队里的技术人员劳动合同.doc版本控制与到期提醒4.1 从单个文件到批量先统一编码和命名实际团队里不会只有一份合同目录下可能同时存在不同年份、不同模板版本的“技术人员劳动合同(2023).doc”、“技术人员劳动合同(2024).doc”。盲扫之前我先把所有文件名做一次归一化去掉多余空格、统一年份为四位、补上部门前缀否则转换结果会乱还会覆盖同名文件。这里用 bash 循环做增量转换mkdir -p converted shopt -s nullglob for doc in *.doc; do docxconverted/${doc%.doc}.docx if [[ -f $docx ]]; then echo skip $doc continue fi libreoffice --headless --convert-to docx --outdir converted $doc || echo fail $doc doneshopt -s nullglob让*.doc没有匹配时不返回字面量${doc%.doc}去掉后缀再加.docx作为输出名|| echo fail $doc捕获转换失败的场景。这个循环每跑一次只会处理新增的 .doc避免重复劳动。注意文件名含空格时上面的引号是必须的否则 shell 会拆词文件名为纯中文也没问题只要系统 locale 是 UTF-8。如果converted目录里已有同名 .docx-f判断会跳过但源 .doc 内容变了而converted里还留着旧版就会被漏掉所以生产环境一般会把转换结果记录一个 Hash 表源文件变则强制重新转换。4.2 用 Git 管理二进制合同doc 文件的差异化难在哪合同文件通常要走版本审批。doc 是二进制格式直接扔进 Git 会立刻发现.git diff出来的是一堆二进制差异无法看到哪一行改了薪资。常见做法是让 Git 忽略原 .doc只存 .docx 和每份合同抽取的纯文本但这又没法保留盖章签名扫描件。所以我一般这样安排.doc 原始文件纳入 Git LFS作为不可篡改的证据每次转换出的 .docx 同样纳入 LFS另外用脚本生成合同编号.contract.txt这个文本文件才进普通 Git供 diff 查看。配置命令git lfs track *.doc git lfs track *.docx git add .gitattributes git lfs install.gitattributes里会写入filterlfs和difflfs。LFS 会把文件的指针放进 Git 仓库真正的二进制块存到远端所以克隆后必须git lfs pull才能拿到实体文件否则只有几行指针文件。这个机制对合同管理尤其重要本地磁盘坏了还能从远端恢复原文档的哈希不能作为签名但 LFS 指针本身有 OID 可做完整性校验。文件类型存储位置用途.docGit LFS保留原始签字版.docxGit LFS方便 python-docx 读取.contract.txt普通 Git提供可读 diff4.3 合同到期提醒把解析后的字段喂给业务系统有了批量转换和 LFS 存档最后一步是把合同关键日期抽出来做提醒。常见做法是只写一个脚本遍历converted目录下的 .docx提取合同终止日期并按剩余天数排序。示例from datetime import datetime from pathlib import Path import re from docx import Document def termination_date(path: Path): doc Document(path) chunks [p.text for p in doc.paragraphs] for table in doc.tables: for row in table.rows: for cell in row.cells: chunks.append(cell.text) text \n.join(chunks) m re.search(r合同(?:期限|截止)[:至到]\s*(\d{4})年(\d{1,2})月(\d{1,2})日, text) if not m: return None return datetime(int(m.group(1)), int(m.group(2)), int(m.group(3))) for docx in Path(converted).glob(*.docx): end termination_date(docx) if end: print(f{docx.name}: 剩余 { (end - datetime.now()).days } 天)termination_date把段落和表格的文本都汇入chunks用\njoin 后正则匹配“合同期限至……”或“合同截止……”两种写法。[:至到]字符集同时兼容“至”和“到”。返回值如果是 None说明这份合同可能签的是无固定期限也可能模板没写清最好单独输出到待人工检查清单。这里有一个小坑datetime.now()在输出时别忘了时区部署到多时区服务器时建议用datetime.now(timezone.utc)统一基准时间否则跨地区同事看到“剩余 0 天”会误判。5. 验证提取结果几个让技术人员劳动合同.doc 处理流程少出错的小技巧5.1 用断言函数把脏数据挡在门外批量处理中最怕的就是“字段有值但值错了”。比如上一个脚本能把“合同期限2024-13-01”截成数字组然后datetime直接抛ValueError也可能把“2024-06-31”这种不该存在的日期放入提醒系统。所以我每次解析后都会跑一遍统一的校验函数把结构性问题记录下来再转人工。def validate_record(rec): problems [] if not rec.get(party_b): problems.append(缺少乙方姓名) if rec.get(salary): if not re.fullmatch(r\d(\.\d{2})?, rec[salary]): problems.append(薪资字段异常) if rec.get(start) and rec.get(end): if rec[end] rec[start]: problems.append(结束日期早于开始日期) if rec.get(probation_days, 0) 0: if (rec[end] - rec[start]).days rec[probation_days]: problems.append(试用期与合同总时长不匹配) return problemsrec是一个字典其中start、end是已经转成datetime的对象。salary用fullmatch限制成整数或两位小数防止读到“面议”和“15K”这种文本日期比较直接比较对象probation_days如果有还要看它是否小于合同总时长这是很常见但容易被忽略的无效数据。5.2 给每个源文件留一张解析回执还有一个收尾技巧转换和解析不直接改原文件而是把每个合同的解析结果写成一个同名的.json和源 .doc 放在一起。文件名规则定为合同编号.parsed.json内容至少包含source、extracted_at、fields、warnings。这样人工复核时能对着问题清单看原文不需要再次运行脚本。落地代码很小import json, hashlib from pathlib import Path with open(converted/技术人员劳动合同.docx, rb) as f: sha hashlib.sha256(f.read()).hexdigest() res { source: converted/技术人员劳动合同.docx, sha256: sha, fields: {party_b: 张三}, warnings: [试用期与合同总时长不匹配] } Path(张三.parsed.json).write_text(json.dumps(res, ensure_asciiFalse, indent2), encodingutf-8)sha256是为了校验解析时读取的 docx 和当前文件是否一致如果同事后来又改了合同解析结果不会假装有效。ensure_asciiFalse保证中文在 JSON 里可读indent2方便人工 Diff。把上面的validate_record接到第 4.1 的循环入口输出结果只给“通过”的合同进提醒系统剩下的交给人工。本文还有配套的精品资源点击获取