文件变了，不一定适合只看整行增删。OmniDiff 把差异比较按内容类型拆开处理： ① 代码看结构，未知文本退回逐行 根据扩展名选择语言，用 tree-si… · @BaiBtw · TwKit

@BaiBtw

文件变了，不一定适合只看整行增删。OmniDiff 把差异比较按内容类型拆开处理： ① 代码看结构，未知文本退回逐行 根据扩展名选择语言，用 tree-sitter 解析 25 种语言并做结构比较。Python 示例把循环改为 sum、len 等调用时，突出变化的表达式，而不只是整行标红标绿。SQL、Markdown 等虽然能识别扩展名，目前仍按纯文本比较；未知扩展名也走逐行比较。 ② 二进制按内容识别，不只看文件名 图片逐像素、动画逐帧；压缩包逐成员，还能递归到内部压缩包；字体比较字形、名称和度量；翻译目录逐消息；PDF 逐页渲染比较。示例中，PDF 只改了一个框的名称，也能指出变化区域。无法展示的其他二进制文件则给出“文件不同”的简短提示。 ③ 交互查看与脚本输出分开 直接运行两个文件的比较可进入终端界面；--headless/--batch 输出文本，stdout 不是终端时也会自动进入该模式。默认保留变化两侧各 3 行上下文，并补充附近函数、类或结构的定位信息。Git 中 git difftool 可开交互界面，git diff 与 git log -p 则输出文本；JSON 模式另有结构化结果。 ④ “跑完、跑快、标得准”是三组指标 项目报告：在约 44.25 万组代码前后版本上，以每进程 120 秒、6GB 内存为限制，99.95% 完成比较。这不等于 99.95% 准确。 另一组 2,302 个测试样本，在 i7-1370P、32GB 笔记本上测得中位 4.2ms、p99 177ms；不同内容和机器不能直接套用这些数字，压缩包测试的 p99 约 1.94 秒。 ⑤ 准确率还没达到项目自己的目标 1,419 个带人工逐字节标注的代码样本中，minimal 高亮模式约 69.6% 的样本字节标注完全匹配人工答案；91.5% 的样本中，错标字节占比不超过 1%。全语料总体字节误差只有 0.07%，却不能替代逐样本指标：大量未变化内容会稀释错误。PDF 的“100%”判断结果也只来自 4 个样本。 这些是项目文档公布的实现与测试口径，不是独立复测；内容识别、性能和高亮准确性需要分别理解。

曝光 112 · 评论 1 · 点赞 2 · 书签 0