文本对比工具

它会算出把一段文本变成另一段的最省力的方法。可用的操作只有删除一行和插入一行，所以一处“差异”其实是编辑脚本中的一条记录：这一行去掉了，这一行加进来了，其余保持不变。这个视角能解释 diff 大部分让人意外的行为。它没有“编辑一行”的概念（编辑只是恰好相邻的一次删除和一次插入），也没有“移动一段”的概念，只知道一段在这里消失、在那里出现。本页在此之上增加了第二轮比较：当一处删除和一处插入足够相似、像是同一行的两个版本时，会在它们内部再比较一次，向你展示真正改动的词。

因为根本不存在“那些”差异：只有关于一段文本如何变成另一段的种种解释，而且有无数种都与事实相符。你总可以把任何改动描述成“删除全部，再插入全部”，这没错，但毫无用处。有用的约束是最小化：选择编辑次数最少的那种解释，因为它让原文最多地保留在原位，因而最接近一个人实际做的事。Myers 在 1986 年提出的算法能找到这样的解释，耗时与输入规模乘以该脚本长度成正比，所以两个几乎相同的文件无论多长，都能在几毫秒内比较完毕。

不是，在和 diff 较真之前最好先知道这一点。把“a b c”和“a c b”比较：你可以删除 b 再把它插到 c 之后，也可以删除 c 再把它插到 b 之前。两种都是两次编辑，没有哪种更正确。每个 diff 工具都靠约定而不是洞察力来打破平局。本工具倾向于先报告删除再报告插入，并尽可能早地采用匹配。所以，当 diff 把一处改动算到你没碰过的行上时，它通常没有错，只是选了另一种同样简短的方式来描述同一处改动。Git 的 `--patience` 和 `--histogram` 算法正是为了让这种取舍在源代码上更符合人的直觉。

因为“移动”不是可用的操作之一。编辑脚本只有两个动词：删除和插入，所以挪动一个段落会被表述为它从旧位置移除、在新位置出现。一个感觉上只是一次操作的改动，因此出现了双倍的红色和绿色。有些工具会在事后加上移动检测，寻找与别处插入块相同的删除块，但这只是叠加在上面的启发式方法，并非算法本身的一部分，而且当移动的块同时被编辑过时就会出错。实用的办法是把移动和编辑分成不同的修订：先在一次修改中移动章节，下一次再改措辞，这样每次的 diff 都清晰可读。

因为每一行是作为一个完整字符串来比较的。重新缩进文件、把制表符换成空格，或者让编辑器在保存时去掉行尾空格，都会改变它碰到的每一行，所以在你让比较忽略空白之前，格式调整和真正的编辑是无法区分的。审阅文章或重新排版过的代码时，关闭空白比较是正确的做法。但凡空白属于语法的内容，这样做就是错的：Python 的缩进决定代码块结构，YAML 的缩进决定嵌套层级，Makefile 的规则命令行必须以真正的制表符开头，而不能是八个空格。在这些文件里，只改空白的改动并不是表面问题。它就是改动本身，把它隐藏起来就会隐藏一个真正的 bug。本页把这两种情况分开处理：“忽略行首行尾空白”放过行的两端，同时仍然报告缩进；“忽略所有空白”则全部放过。

几乎总是换行符的问题。Windows 用回车符加换行符来结束一行，Unix 和 macOS 只用换行符，而老式 Mac 软件只用回车符。这些字符是看不见的，所以一个经过 Windows 编辑器的文件，可能每一行都与原文件不同，在屏幕上却完全一样。本页会按这三种结束符拆分，并比较每行的内容，所以 CRLF 与 LF 不会造成一大片虚假的改动。不过它仍会告诉你两边使用了不同的换行符，因为这个差异是真实存在的，会影响 git、shell 脚本的 shebang 行，以及任何逐字节读取文件的程序。其他看不见的元凶还有从网页粘贴来的不换行空格，以及文件最开头的字节顺序标记。

它是块头，告诉补丁程序后面这一块应该放在哪里。`@@ -12,7 +12,9 @@` 的意思是：从原文件第 12 行开始，这里描述了七行；从新文件第 12 行开始，这里描述了九行。减号范围总是指原文件，加号范围指修订版，而且计数包括两侧显示的未改动上下文行，不只是改动的行。计数为 1 时省略逗号，空范围则相对于它所跟随的那一行来写，所以在第 4 行之后的纯插入会显示为 `-4,0`。块头下方，行首为空格表示未改动，减号表示删除，加号表示新增。正是上下文让补丁能够应用到略有变化的文件上：两侧各有三行上下文时，即使上方有无关的编辑，补丁程序仍能找到正确的位置。

因为把一行删除内容和一行插入内容配对是一种猜测，而错误的猜测比不猜更糟。如果两行确实是彼此的不同版本，在内部比较它们正是你想要的。如果它们只是恰好相邻，内部比较就会找出它们共有的几个短词和零散标点，结果碎成一地：散落的红绿碎片，比“这一行去掉了，这一行加进来了”更难读。阈值是一个比率：两行共有的字符数（两边都计入）除以两行的总长度。1 表示完全相同，0 表示毫无共同之处。高于你选择的设置时，这对行会被细化并逐词显示；低于设置时，两行会被报告为直接替换。比较大幅改写的文章时可以放宽，当 diff 开始看起来像一堆彩带时就收紧。

每一边最多 200,000 个字符或 10,000 行，大约相当于一部 40,000 词的书稿。在此范围内还有两个较宽松的限制。当编辑脚本将超过 12,000 次编辑，或搜索超出其计算预算时，行比较就会停止搜索，因为比较两段毫无共同之处的文本是平方级的工作量，否则会卡死标签页；超过这一点后，受影响的区域会被报告为一整块被另一块替换，并有提示说明。另外，超过 4,000 个词或字符的单行只会按相同的开头和结尾进行细化，而不是完整细化，这同样会被标注出来，不会隐藏。这些限制都会给出正确的结果，只是比平时更粗略。

不能，任何 diff 工具都做不到。它比较的是文本，不是含义。一致地重命名一个变量、调换两个互不相关的函数定义的顺序、把单引号换成双引号，或者把参数列表重新排成三行，都会产生很大的 diff，行为却毫无变化。反过来，`>` 变成 `>=` 只差一个字符，却可能正是整个 bug 所在。diff 记录的是输入了什么，而不是会发生什么，这正是代码审查要先看 diff 再跑测试的原因。如果你想要理解结构而不是字符的比较，就需要一个能解析该语言的工具，而在这里有用的第一步，是在比较之前统一两边的格式，让 diff 反映内容而不是排版。