周一早上，同事把文件甩过来：「合同我又改了一版，你帮我看看哪里改了。」

你打开两个 Word，把它们并排放好，左边一屏、右边一屏。

第一屏还行，你还能认真看。看到第二屏的时候，你发现两边的滚动位置对不上了——左边第 47 行，对应右边是第几行？你开始数。

数到第三屏，你已经放弃逐行比对了，改成「先用眼睛扫一遍，看着眼熟就跳过」。

然后你在群里回一句：「好像就改了几个数字，问题不大。」

「好像」和「问题不大」这两个词，就是这样来的。

比这更要命的是另外三个场面。

第一个是制度文件更新。 一份《考勤管理制度》改了 8 版，领导问「跟去年那版比，加删了哪些内容」。你手上只有最新版，去年那版在某个文件夹里，文件名还叫「制度（最终）(2).docx」。

第二个是论文查重的前置工作。 学生的论文和网上那篇「参考文章」重复在哪几段？在线查重平台上传一次要钱，而且论文还没定稿，传上去心里不踏实。

第三个是两份名单对账。 财务给的员工名单和人事给的那份，谁多了、谁少了、谁部门改了？两份 Excel 各两百行，你没法一眼看出来。

这三件事，我们做成了一个工具。

需求是从群里攒出来的，问的都差不多。下面这几个问题，就是把那些问法归拢之后剩下的——先把它们答了，因为答案直接决定了这个工具长什么样。

第一个问题：不是「看」不出来，是没有对的方法。 人眼比对两屏文本，本质上是在做一件人脑极不擅长的事——找细微差异。你的眼睛会自动跳过「看起来差不多」的地方，这在一百行里可能漏掉三五处，在合同里这三五处就是责任。

第二个问题：市面上的选择都不合适。 系统自带的没有；Beyond Compare 好用但要收费，公司不给报销；在线的倒是有，但你把合同传上去的那一刻，它就不在你手上了。合同、工资表、名单——这些东西不该上传到任何地方。

第三个问题：名单也能比。 而且比文本更好办——名单本质就是文本。

所以这个工具就三件事：比文本 / 认格式 / 出报告。

「按段落句子」不是花架子。 如果有人把一段话拆成两行、或者把两段合成一段（Word 里手一抖就会这样），整行对比会报出一大堆莫名其妙的差异。换成按句子，差异立刻干净很多。

忽略大小写 / 忽略首尾空白 / 忽略所有空白 / 忽略空行 / 忽略中文标点 vs 英文标点 / 全角半角归一化 / 忽略 CRLF vs LF。

默认只勾了 CRLF/LF 这一项，其余全关。为什么默认这么保守？因为对比工具不该偷偷改你的数据——你没说能忽略的东西，它就该报出来。

这里有个坑值得单说：全角半角归一化不能用 NFKC。

很多人的第一反应是用 unicodedata.normalize("NFKC") 做归一化。千万别。 NFKC 会把 ① 变成 1、㈠ 变成 (一)、Ⅻ 变成 XII。合同里的「第一条」「①附件」一旦被这么改写，对比就变味了——原文明明写的是「①」，工具报给你的是「1」，这已经不是对比，是篡改。

这个工具只做一件事：全角 ASCII 区（Ａ-Ｚ ０-９ 和全角标点）加全角空格 → 半角。圈号、罗马数字、带圈汉字，一律不动。自检里有两条断言专门盯着这件事。

编码全自动识别：UTF-8 / UTF-8-BOM / GBK / UTF-16 都能认。同一份内容存成这四种编码，工具比出来0 处差异（自检里断言了）。

docx 的抽取顺序是个容易忽略的细节。 老写法是先抽完所有段落、再抽所有表格——结果一份「文字 → 表格 → 文字」的制度文件，抽出来变成「文字、文字、表格」堆在一起，顺序跟人看到的完全不一样，对比结果会误导你去核对错误的位置。这个工具按文档里的真实顺序抽。

这条要单独说，因为它是最危险的静默失败。

扫描件（整页就是一张图）没有文字层。如果工具这时候静默返回一个空字符串，你会看到「两份 PDF 一模一样」——这比报错危险得多，因为你会拿着这个结论去做判断。

所以这个工具遇到没有文字层的 PDF，会直接给你一句人话：

不许静默返回空，这条在自检里是一条硬断言：它会造一份纯图片 PDF，断言工具必须抛错，而且错误里必须出现「没有文字层」和「OCR」两个词。

左边 A 侧、右边 B 侧，行号对齐，增行绿底、删行红底、改行黄底，行内深色字就是具体改动的字（删掉的字带删除线）。

配上「上一条差异 / 下一条差异」，中间显示 3/12 处差异。连续差异算一处——连着改了 5 行，导航上算 1 处，按一下滚动过去一次看全，不用按五次。

选两个文件夹（A 旧、B 新），按相对路径两两配对：同名文件一一对比，只在 A 有的、只在 B 有的都会单独列出来，出一份总报告。

我们造了三版合同（v1 → v2 → v3，其中 v3 还故意存成 GBK 编码）、一份制度 docx 和它的修订版、两份员工名单 xlsx、两份产品说明 PDF，还有一份纯图片的扫描件 PDF。

拿工具跑：

自检全程在临时目录里造数据，跑完删干净，不碰你的任何文件。

265 条断言，0 失败才算过。而且它验的是真东西：

第一，相似度不能只按行算。
difflib.SequenceMatcher.ratio() 的公式是 2M/T，但如果一份稿子只有一行，「你好世界」改成「你好世」按行算就是「0 个相同行」→ 相似度 0%，用户看着莫名其妙，实际上只掉了一个字。所以这个工具把「匹配」的定义放宽一层：改了的行按行内字符相似度给分，再折算回总相似度。公式还是那个公式，数字才对得起眼睛。

第二，必须先削掉共同的头和尾。 改过一版的合同 95% 的行是一模一样的。直接把整份丢给 SequenceMatcher，遇到「大量重复短行」（几百行都是「同上」的表）会退化成 O(n²)；而如果因此打开 autojunk=True，又会把重复行当垃圾忽略掉——一份 8000 行同内容的稿子会被算成「改了 8000 行」（实测）。所以先削共同头尾（diff 的标准做法），剩下的中间通常很小。8000 行里改 1 行，实测 0.114 秒，精确报出 1 处修改。

第三，行内高亮用 Levenshtein，不用 SequenceMatcher 的 opcode。 对「今天天气很好」→「今天天气不太好」，SequenceMatcher 会切成「删『很』+ 插『不太好』」，编辑距离 3；而「只插一个『不』」编辑距离只有 2——后者更短，也更符合直觉。所以行内对齐用 Levenshtein（替换代价 = 1），它天然偏向保留相同的字。代价是 O(n·m)，所以只在两行都不长时才用；超长行直接跳过行内高亮，并在备注里明确写出来，不许假装比过。

说句老实话：上面这个例子，工具实际切出来是「删『很』+ 插『不太』」——因为两种切法编辑距离都是 2，打平，程序选了改动字数一样的那一种。这不是 bug，是「最短编辑」原则的必然结果，自检里把这个行为钉死了。

这台机器上装了奇安信。实测「体积小的未签名单文件 EXE」会被它短时间隔离，表现是抛假的 PermissionError，重试、等待都救不回来（实测等 65 秒仍然全拒）；更狠的是它会直接把 EXE 删掉。

到底多小算小？我们量过两轮，结论没能收敛：第一轮 8.4 MB / 13.3 MB 失败、21.1 MB / 31.4 MB 成功；后来换一份探针再量，8.4 MB 稳定失败，10.5 MB 和 14.7 MB 却都成功了。所以「20 MB 是临界线」这句话我们不写死，只写「包做大就没事」。

所以：产物 42.9 MB（≥30 MB 是硬规矩），而且打包和自检挤在同一个进程里完成，中间不给它留删除的窗口。

上面说的那些场面——合同的「好像改了」、制度文件的 8 个版本、论文查重前的忐忑、两份名单的对账——没有一个是「你不够努力」造成的。它们只是缺乏一个趁手的工具。

这个工具离线运行，不联网，不上传任何内容。合同也好、工资表也好、名单也好，全程只在你自己电脑的内存里比。这一点对我们来说不是「特色功能」，是底线。

工具在群里，关注公众号回复「进群」直接领。42.9 MB，双击就跑，不用装 Python，不用注册，没有试用期，不弹广告。

源码就一个文件，全中文注释，连踩过的坑都写在注释里。想改成你要的样子，自己动手就行。

文本对比工具，双击就跑。两份文稿往里一放，逐行 / 逐字 / 逐段比差异，增绿删红改黄，导出自带样式的 HTML 报告发人就能看。

docx、xlsx、pdf 都能比，编码自动识别，扫描件没文字层会明确告诉你。两个文件夹还能批量比，谁多了谁少了一次说清。

完全离线，不上传。 

链接：https://pan.baidu.com/s/1UAcmVqOx76F75hlJGrShhg?pwd=u4cy​ 提取码：u4cy

阅读原文：点击这里