我们很高兴宣布 GroupDocs.Comparison for Java 26.11 已于 2026年11月 发布。首要特性是 基于 OCR 的图像比较:现在可以通过图像中识别的文本进行比较,而不是通过像素比较。电子表格比较进行了一次重大改造——行按内容匹配,比较大型工作表的速度从分钟提升到秒级。PDF 结果现在按照源页面布局,方式与 GroupDocs.Comparison for .NET 相同,并且一系列修复覆盖了文本、Word、演示文稿和 HTML 预览比较。
本次发布的新功能
| 关键 | 摘要 | 类别 |
|---|---|---|
| COMPARISONNET-4925, COMPARISONNET-4934 | 图像可以通过识别的文本(OCR)而不是像素进行比较 | 功能 |
| COMPARISONJAVA-1798, COMPARISONNET-4940, COMPARISONNET-4945 | 电子表格行按内容匹配:插入或删除的行不再导致后续所有行标记为更改 | 修复 |
| COMPARISONJAVA-1797, COMPARISONNET-4930 | 电子表格比较耗时从分钟降至秒;所有格式的文本差异更快 | 修复 |
| COMPARISONJAVA-1796, COMPARISONNET-4946 | XLSX 结果:没有自身高度的行保持适应其内容 | 修复 |
| COMPARISONNET-4947 | XLSX 结果:未更改的数字和日期保持其类型,而不是转为文本 | 修复 |
| COMPARISONNET-4944 | StyleSettings.setHighlightColor 为已更改的电子表格单元格填充背景颜色 |
修复 |
| COMPARISONNET-4927, COMPARISONNET-4928, COMPARISONNET-4923 | 文本:跨换行的单词不再被报告为删除后重新插入 | 修复 |
| COMPARISONNET-4403, COMPARISONNET-4891 | PDF 结果按源页面布局:组件保持在原位置,单元格在自身边缘换行 | 更新 |
| COMPARISONNET-4931 | 内联 PDF 结果完整显示被替换的短语:先是旧词,再是新词 | 修复 |
| COMPARISONNET-4896 | 内联 PDF 结果不再将因替换而略微变长的行换到下一行 | 修复 |
| COMPARISONNET-4763 | PDF 结果不再在表格自身边框上绘制黑色网格 | 修复 |
| — | 通过表单绘制的 PDF 页面(如电子表格保存为 PDF)不再被视为未更改 | 修复 |
| — | PDF:仅包含空格的行不再被报告为更改 | 修复 |
| — | PDF:目录的页码保持在其所在行 | 修复 |
| COMPARISONNET-4926 | Word:变为空的表格列或行保持原位,而不是被删除后重新插入 | 修复 |
| COMPARISONNET-4880 | 演示文稿:LoadOptions.setSkipExternalResources 和 setWhitelistedResources 现已生效 |
修复 |
| COMPARISONNET-4935 | HTML 预览:并发预览不再相互覆盖页面;请求的页面得到尊重 | 修复 |
| COMPARISONJAVA-1794, COMPARISONJAVA-1795 | Aspose 库已更新 | 更新 |
升级前需检查的行为更改
- 新依赖。 发布的 POM 声明了一个新依赖 Aspose.OCR for Java,仅在 OCR 比较时使用。它会带来带本地库的 ONNX Runtime。如果不使用 OCR,可以将其排除——其他所有比较功能均不受影响(参见如何获取更新)。
- 电子表格更改。 当插入或删除行时,电子表格比较报告的更改数量会不同——且通常大幅减少,因为行现在按内容匹配。
- PDF 布局。 PDF 结果的布局方式已改变:每个组件保持在源页面上的位置。
- 替换顺序。 在文本和内联 PDF 结果中,替换的单词或短语现在先显示旧内容,再显示新内容。
- 评估模式。 与 GroupDocs.Comparison for .NET 一致,评估模式下仅比较 PDF 的前 2 页。
新特性:通过识别文本(OCR)比较图像
现在可以通过 Aspose.OCR 读取的文本来比较图像,而不是通过像素比较。这是扫描件、照片和文档截图的理想选择,因为相同的文本在不同的扫描或质量下不会产生相同的像素——轻微位移或不同质量的重新扫描不再导致到处出现差异。
try (Comparer comparer = new Comparer("source.png")) {
comparer.add("target.png");
OcrOptions ocr = new OcrOptions();
ocr.setEnabled(true);
ocr.setDisplayMode(OcrDisplayMode.SIDE_BY_SIDE); // or TEXT
CompareOptions options = new CompareOptions();
options.setOcr(ocr);
comparer.compare("result.png", options);
for (ChangeInfo change : comparer.getChanges()) {
OcrChangeInfo ocrChange = (OcrChangeInfo) change;
System.out.println(change.getText() + ": confidence " + ocrChange.getConfidence()
+ ", " + ocrChange.getSourceBoxes().length + " box(es) on the source");
}
}
您可以控制的内容:
- 显示模式。
SIDE_BY_SIDE(默认)将两幅图像并排显示,并用框标出更改的单词。TEXT仅显示识别的文本,并在其中标记更改。 - 更改细节。 每个更改都是一个
OcrChangeInfo,包含在两幅图像上覆盖的框(getSourceBoxes()、getTargetBoxes())以及识别置信度(getConfidence())。在TEXT模式下这些框为空。 - 语言。
setLanguage(OcrLanguage)用于选择语言或脚本;默认是LATIN。其他语言需要在首次使用时下载相应的识别模型。setDisableResourceDownloads(true)和setResourcesPath(String)可限制仅使用磁盘已有的模型。
Aspose.OCR for Java 必须在类路径上。它是已发布 POM 的依赖项,而不是 jar 包的一部分。若缺少该库,OCR 比较会因找不到相应库而失败并提示相应信息。
电子表格比较
按内容匹配的行
之前,行会与另一工作簿中相同索引的行配对。当插入或删除行时,之后的每一行都会被报告为重写。例如,六行工作簿删除一行会产生 91 条更改;现在仅产生 8 条——被删除行的六个单元格标记在原位,摘要表上显示行数变化。
现在,行和列按单元格内容对齐。两文件中相同的行直接配对,仅在它们之间的内容进行对齐。此类文件报告的更改数量与早期版本不同。
秒级而非分钟
即使是完全相同的文件,电子表格比较也可能需要数分钟:两个 200 × 20 的相同工作表耗时 2.5 分钟。现在耗时不到一秒(首次比较在 JVM 启动后几秒),而 400 × 20 工作表删除一行大约需要 7 秒。
每次比较背后的词差算法已重新实现,返回的结果与之前相同,只是速度快得多——因此 Word、PDF 和文本比较也受益。相同的行列在配对时不计分数,所以两个完全相同的工作表根本不进行对齐。
行高、数字类型和高亮颜色
- 没有自身高度的行现在在结果中保持适应其内容,因此换行和大字号单元格不再被裁剪。具有显式高度的行保持原高度。
- 未更改的数字和日期保持其类型,而不是被写回为文本。公式单元格仍以计算值写入。
StyleSettings.setHighlightColor现在为已更改的单元格填充背景颜色:
StyleSettings deleted = new StyleSettings();
deleted.setHighlightColor(Color.PINK);
CompareOptions options = new CompareOptions();
options.setDeletedItemStyle(deleted);
PDF 结果
按源页面布局
PDF 引擎现在的布局方式与 GroupDocs.Comparison for .NET 相同:
- 结果的每个组件都保持在源页面上的位置;图像放置在其坐标处,页面的矢量图形也会被保留;
- 表格绘制其网格,且每个单元格的文本在单元格自身边缘换行,包括合并单元格;
- 通过基线之间的距离将线条分组为段落,页面边距来源于页面本身;
- 两文档中相同的页面可以出现在文档的任意位置,而不仅仅在开头,并且不会再次比较。
因此结果看起来与早期版本不同。已删除的内容会绘制在其在源页面上的位置;如果目标页面在同一位置有其他内容,两者可能会重叠。
小幅修复
- 替换短语。 多词替换原本逐对绘制,导致 “Richard McClintock” 变为 “Vasily Pupkin” 时显示为 “Vasily Richard Pupkin McClintock”。内联结果现在先显示旧短语,再显示新短语。
- 行略微变长。 在内联结果中,因替换导致行长度增加一个单词的情况不再将最后一个单词换到新行上。
- 表格网格。 颜色无法检测到的表格边框不再在源表格自身边框上绘制黑色。
- 通过表单绘制的页面。 通过表单绘制全部内容的页面(如电子表格保存为 PDF)不再被视为未更改。表单现在也会比较,从而报告其更改。
- 空白行。 仅包含空格的行不再被报告为更改。
- 目录。 目录中被更改的行其页码仍保持在原行。
其他修复
跨换行的文本
对文本文件的编辑如果导致行长变化,会把单词推到换行后。逐行比较时,这些单词会被报告为从一行删除并插入到下一行。现在在合并后进行一次性比较并在目标行上重新布局,从而产生更少的更改。替换先显示旧内容,再显示新内容,HTML 视图的文本比较也以同样方式应用接受和拒绝的更改。对一个文件与多个目标的比较仍然逐行进行。
Word:清空的表格列或行
当表格的列或行变为空时,之前会被报告为删除并插入一个空的列/行,导致后续单元格位置错位。现在该列/行保持原位,仅其内容被报告为删除。
演示文稿:外部资源
LoadOptions.setSkipExternalResources 和 setWhitelistedResources 在 26.10 中已加入,但对演示文稿没有效果。现在它们同样适用于演示文稿、Word 和 HTML 文档,结果演示文稿永远不会获取外部资源。未加载的图片会被视为空图片进行比较。
HTML 预览
HTML 文档的预览页面之前被渲染到临时目录的固定文件名,导致同时的两个预览相互覆盖页面,请求的页码也被忽略。现在页面在内存中渲染,仅返回请求的页面,并且在白色背景上渲染,而不是透明背景。
Aspose 库已更新
| 库 | 之前 | 现在 |
|---|---|---|
| Aspose.BarCode | 25.5 | 26.6 |
| Aspose.CAD | 24.6.1 | 26.8 |
| Aspose.Cells | 26.3 | 26.9 |
| Aspose.Diagram | 25.7 | 26.9 |
| Aspose.Email | 26.1 | 26.8 |
| Aspose.PDF | 26.2 | 26.8.1 |
| Aspose.PSD | 25.10 | 26.8 |
| Aspose.Slides | 26.2 | 26.9 |
| Aspose.Words | 26.3 | 26.8 |
这些库仍然像以前一样打包在 jar 中。Aspose.OCR 26.10.0 为新库,作为 POM 的依赖项出现。
如何获取更新
Maven
在 pom.xml 中添加 GroupDocs 仓库和依赖:
<repositories>
<repository>
<id>groupdocs-artifacts-repository</id>
<name>GroupDocs Artifacts Repository</name>
<url>https://releases.groupdocs.com/java/repo/</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>com.groupdocs</groupId>
<artifactId>groupdocs-comparison</artifactId>
<version>26.11</version>
</dependency>
</dependencies>
如果不使用 OCR 比较,可以排除 Aspose.OCR 及其本地库:
<dependency>
<groupId>com.groupdocs</groupId>
<artifactId>groupdocs-comparison</artifactId>
<version>26.11</version>
<exclusions>
<exclusion>
<groupId>com.aspose</groupId>
<artifactId>aspose-ocr</artifactId>
</exclusion>
</exclusions>
</dependency>
直接下载
从 GroupDocs.Comparison for Java 26.11 下载页面 下载 JAR。