DOI 去重实战：批量参考文献的文献去重与引文整理

写综述、整理课题组的参考文献库时，我最怕的不是找文献，而是合并几个人各自导出的引用清单。每个人用的工具不一样，导出格式也不一样，同一篇论文的 DOI 在三份文件里能长成三个样子。肉眼看着像不一样，实际上指向的是同一篇文章。这种重复如果带进正文，轻则参考文献列表里出现两条一模一样的引文，重则正文里的引用编号对不上。

为什么同一个 DOI 会写成好几种样子

DOI（数字对象唯一标识符）本身只是 10. 开头的那一串，比如 10.1038/s41586-020-2649-2。但在不同来源里，它会被包装成不同形式：

裸写的标识符：10.1038/s41586-020-2649-2
加了官方解析前缀：https://doi.org/10.1038/s41586-020-2649-2
老式 HTTP 前缀：http://dx.doi.org/10.1038/s41586-020-2649-2
大小写混排：10.1038/S41586-020-2649-2

这四种写法,指向的是同一篇论文。前缀只是告诉浏览器去哪里解析这个标识符,它不改变标识符本身。DOI 标准里也明确规定后缀部分大小写不敏感,所以 S41586 和 s41586 是同一个。问题在于,大多数文本去重只做逐字符比对：只要有一个字符不同,就当成两条不同的记录留下来。结果就是一份清单里躺着三条"不同"的引文，其实是同一篇。

去前缀、转小写，再比较去重

要把这些变体收成一条，核心思路是先规范化再比较。具体做法是：

去掉解析前缀，把 https://doi.org/、http://dx.doi.org/、doi: 这类开头统一剥掉，只留下 10. 开头的标识符。
把整个标识符转成小写，消除大小写差异。
用规范化之后的结果作为去重的比较键。

只有比较键完全一致的，才会被判定为重复并合并。原始那行不会丢，工具会保留首次出现的那条作为代表，并记下它重复了几次、第一次出现在哪一行。这一点对做综述很重要：你想知道这条引文到底是从哪份导出里冒出来的，行号和重复计数就是线索。

这套流程可以直接用 DOI去重工具跑，解析、规范化、去重全在浏览器本地完成，不用把文献清单传到任何服务器。

一个真实的去重例子

假设我把两个人的导出合到一起，输入是这样：

https://doi.org/10.1038/s41586-020-2649-2
10.1038/S41586-020-2649-2
10.1145/3292500.3330701
http://dx.doi.org/10.1038/s41586-020-2649-2

前三行和第四行里，第一、第二、第四行其实是同一篇（Nature 那篇 NumPy 论文），只是一个带 https://doi.org/、一个全大写、一个带老式 dx.doi.org 前缀。去重后输出：

10.1038/s41586-020-2649-2   （重复 3 次，首次出现于第 1 行）
10.1145/3292500.3330701     （唯一）

三个变体合成了一条，重复计数记成 3，原始证据没丢。这正是带前缀和不带前缀被当成同一条的直接体现。

整理引文列表，避免重复引文

去重只是第一步，真正交付时还要能用。我习惯先去重排序，再决定导出成什么格式：

要塞进文献管理软件或脚本，导出逐行纯文本就够。
要给同事复核，导出带行号的 CSV 或 Markdown，谁都能看懂哪条重复了。
要写进代码或查询，直接转 JSON、SQL IN 或 TypeScript union，省得手工补引号和逗号。

如果你的清单里混着别的东西，比如正文里夹杂的网址、邮箱，可以先用 URL 提取工具把链接单独拎出来，再回到 DOI 去重这一步，避免无关字符干扰比较键。

把无效项也带出来复核

不是每一行都是干净的 DOI。常见的脏数据是缺了 10. 前缀、或者尾巴上还挂着 URL 片段（比如 ?utm_source= 这种跟踪参数）。这类项不会被悄悄丢掉，而是带着原因留在输出里，让你合并清单之前先把引用修好。对要保留审计线索的场景，建议下载带行号的 CSV，而不是只复制最终列表，这样将来有人质疑某条引文从哪来，你随时能翻回原始行。

需要提醒的是，DOI 格式正确不等于这篇文献真实存在。去重和校验解决的是"列表里有没有重复、格式对不对"，至于这个标识符背后是不是真有一篇论文，还得去官方解析页面确认。

整理参考文献这件事，说到底就是把杂乱来源收成一份能交接、可复核的清单。把前缀和大小写的噪音去掉，重复引文自然就现形了。

Made by Toolora · Updated 2026-06-13