这是一个创建于 671 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2023-01-18 15:27:07 +08:00
前端有没有现成的插件
 |
1
murmur 2023-01-18 14:33:23 +08:00
首先你得实现 office 文档的前端浏览，这已经巨牛逼了
然后他居然支持 pdf 、扫描件、word 的交叉比对，虽然原理不清楚，但是测试一定没少做 |
|
2
murmur 2023-01-18 14:38:55 +08:00
当然你可以选择两边都是 pdf 浏览器，不过 pdf 浏览器面对国内奇葩的格式也得跪下，现在好用的 office 转 pdf 都是商用方案
|
 |
3
xiangyuecn 2023-01-18 14:46:06 +08:00
网页只不过是个 UI 而已，仅此而已。重量级的在后端
|
 |
4
johnnyNg 2023-01-18 14:48:12 +08:00
看一下接口，工作量主要在后端，后台已经标好了所有 diff 的位置，内容
|
 |
5
az031120103 OP @murmur 看了下，文件是用 canvas 渲染的
|
|
6
az031120103 OP @johnnyNg 估计是前端计算每一页改动点的色块位置，宽高，svg 高亮一下
|
|
7
az031120103 OP @xiangyuecn 后端也就多了一个查词对比，前端 ui 也没那么容易画的
|
 |
8
bojackhorseman 2023-01-18 15:56:39 +08:00
去这个家公司入职，就知道了😆
|
 |
9
stevenhan 2023-01-18 16:08:04 +08:00
感觉普通写个更新文档什么的还挺好用，但是案例是个债券发行公告，感觉是对文字要求非常严谨甚至苛刻的领域。
先不说 diff 怎么做的，PDF 识别用了 OCR ，那就存在识别出错的可能。 很好奇，这种产品如果出错导致 diff 漏了，造成客户损失，会赔付吗，如果不赔付，需要客户进行二次检验人工 diff ，那貌似产品的意义也不存在了。 |
 |
10
hhjswf 2023-01-18 16:19:02 +08:00 via Android
工作量明显前端大。。
|
|
11
hhjswf 2023-01-18 16:26:58 +08:00 via Android
不可能有现成的，这肯定人家手撸出来的
|
 |
12
xiadd 2023-01-18 17:06:11 +08:00
我看了一下 pdf 的渲染是用的 pdfjs ，至于 diff 肯定是后端做的，之前做过类似的东西，前端工作量也不小
|
 |
13
WasteNya 2023-01-18 17:56:57 +08:00
涉及到这块领域的，很多都是商业机密，虽然不知道那个网站的具体思路，我说一下如果我要实现 pdf 、word 的交叉对比的话（手动狗头）
1. 最终所有文件的格式均已 pdf 展示（确保高保真），至于 word 高保转 pdf ，嘿嘿，机密！ 2. pdfjs 预览的结果会有两层，一层是展示层，一层是文字层（不展示，但包含了位置信息以及文字的 html 标签） 3. 将文字层进行对比，这个前端后端都可以实现，如果嫌 html 对比麻烦，可以转换下使用 ast 或其他格式等等 4. 将对比的结果整理下根据条件来使其变换下背景颜色，就能实现 OP 提到的效果了 |
 |
14
dobelee 2023-01-18 18:03:31 +08:00
现成的都是纯文本对比。
对比算法本身就有不小复杂度，尤其冲突的时候，知名的 beyond compare 和 smartgit 都很多奇葩 bug ，这个 PDF 对比估计下了不少功夫，躺赚就完了。 |
 |
15
toma77 2023-01-18 21:53:56 +08:00 via iPhone
明显前端工作量更大，而且大得多
|
 |
16
noahhhh 2023-01-19 03:42:35 +08:00 via Android
找点特例去试 bug ，就能大概猜到点东西
|
 |
17
missz 2023-01-19 13:23:14 +08:00
庖丁科技好像专注于各种文档类型的解析、提取、转换，之前要解析财报的时候评估过他们家，确实很牛皮
|
Select Language