用Rebiber自动将arXiv预印本引用转换为正式发表版BibTeX

1. 为什么论文都接收了，参考文献里还躺着arXiv版本

1.1 一直被忽略的“引用版本”问题

最近帮几个师弟师妹改Camera Ready版本的论文，发现一个特别普遍的现象：论文都已经过审、被会议或期刊接收了，但参考文献列表里还挂着一大堆arXiv预印本的BibTeX条目。最典型的场景是，研究过程中读了很多相关工作，顺手在Paperpile、Zotero或者Mendeley里一存，就直接把@article{...}条目粘进了LaTeX。等到论文录用，大家忙着改审稿意见、调格式、补实验，压根不会回头检查参考文献到底引的是正式发表版还是预印本。

这个现象在计算机视觉、自然语言处理、机器学习这些领域尤其常见。因为这些方向论文更新极快，很多工作刚挂arXiv就被广泛关注，大家做研究的时候往往直接引用arXiv版本。可问题在于，arXiv上的版本和后来正式发表在ICML、NeurIPS、ACL、TPAMI等会议或期刊上的版本，通常不是同一个版本。有的论文在同行评审后又改了一版，有的补了附录，有的连标题和作者顺序都调整过。这时候你依然挂着arXiv引用，审稿人如果仔细看，就会觉得你连文献信息都没更新，工作态度不够严谨。

而且这里还有一个隐性风险：学术评价和文献检索系统在统计引用时，通常会优先认正式出版版本。你要是只在参考文献里写了arXiv:2301.01234，读者顺着链接点进去看到的可能是预印本，不是最终版。加上很多期刊现在对参考文献格式有硬性要求，明确要求正式录用的论文必须引用出版版本，这种情况在投稿阶段就可能被编辑打回来。

1.2 直接引用arXiv带来的实际隐患

我遇到过好几个比较棘手的场景，都是因为引用版本没更新导致的。

第一种场景是页码和DOI丢失。正式发表的论文一般都有页码、文章编号或者DOI，而arXiv预印本只有一个arXiv ID。如果你把整篇论文的参考文献都交给出版社排版，出版社在核对元数据时就会发现大量条目缺少DOI，需要你逐条补充。一篇十几页的论文，参考文献少说也有三四十条，人工核对一遍少说耗掉一两个小时，还容易漏。

第二种场景是版本差异导致的引用内容不一致。我曾经处理过一篇论文，正式版其实比arXiv版多了几节内容，但作者引的是arXiv版，审稿人恰好按照出版版去找相关内容，结果怎么都找不到，直接给了一个“参考文献引用不准确”的意见。这其实挺冤枉的，因为问题本身很好解决，只是没有在早期注意到。

第三种场景是合作者之间的“信息差”。多人协作写论文时，有人习惯用Mendeley，有人用Zotero，还有人直接在Overleaf上手工管理.bib文件。不同工具从不同渠道抓取BibTeX信息，同一个引用在不同人的本地库里可能字段都不一样。合并文件时经常冒出重复条目，或者同一篇论文出现了两种引用样式，非常难看。

这时候如果有一个工具，能够自动把手里的arXiv引用批量转换成正式出版版本，就能省下大量时间。我之前是在一个开源项目的README里发现Rebiber这个工具的，后面用了相当长一段时间，也踩了不少坑，今天专门把这个工具和整个操作流程整理出来。

2. Rebiber到底是什么，凭什么能解决这个问题

2.1 一句话定位：给BibTeX做一次“版本升级”

Rebiber是Yichuan Gao等人开发的一个开源工具，项目地址在GitHub上。它的核心功能非常简单：输入一个包含arXiv引用信息的.bib文件，自动识别其中已经正式发表的论文，然后把对应的BibTeX条目替换成正式发表版的信息。

你可以把它理解成是参考文献版本的“升级器”。它维护了一份比较大的论文映射数据库，里面记录着很多论文的arXiv ID、DOI、正式发表出处、官方BibTeX等对应关系。当你运行Rebiber时，它会把你的.bib文件里的每个条目解析出来，提取arXiv ID，然后在映射数据中查找匹配项。匹配成功的话，就替换成更完整、更规范的正式版本信息。

这样做最直接的好处是，你不用再一篇一篇地手工去Google Scholar上搜索正式版，再复制粘贴BibTeX条目。尤其当你有几十篇参考文献需要处理时，Rebiber基本上可以在几秒钟之内完成。

2.2 工具的工作方式与内置数据

从原理层面看，Rebiber的运行流程大致可以分为这么几步。

第一步，解析.bib文件。工具使用Python的bibtexparser库，把.bib文件里的每个条目拆解成字段结构，比如author、title、journal、year、eprint等。这个解析过程本身比较成熟，大部分标准的BibTeX条目都能正常识别。

第二步，提取arXiv ID。Rebiber会从条目的eprint字段、archivePrefix字段，以及note、journal等字段中尝试定位arXiv ID信息。常见的写法，比如eprint = {2301.01234}，或者journal = {arXiv preprint arXiv:2301.01234}，它都能识别。如果条目里确实没有arXiv信息，工具也不会报错，而是会跳过或者做简单的修正。

第三步，查找映射数据库。Rebiber的源码仓库里内置了一份data/rebiber.json，里面是大量论文的映射记录。每一条记录一般包含这些字段：

• arxiv_id：arXiv预印本的ID
• doi：正式版的DOI
• url：正式版的链接
• bibtex：一份完整的、已经整理好的BibTeX条目
• published：是否已经正式发表

Rebiber拿你条目里的arXiv ID去匹配这份数据，一旦命中，就直接采用数据库里预先整理好的BibTeX条目，覆盖掉你原来的旧条目。

第四步，输出新的.bib文件。处理完毕之后，工具会把所有更新过的条目写入你指定的输出文件，同时会在终端打印出哪些条目被更新了。

这里需要注意一点：Rebiber内置的映射数据虽然已经比较丰富，但并不是全量的。很多近期的论文、或者比较冷门的论文可能还没有被收录。不过项目作者提供了一些自定义扩展的方式，后面我会专门讲。

2.3 安装前的环境准备

Rebiber是用Python写的，所以安装之前需要确保你的机器上有Python环境。根据项目说明，建议使用Python 3.8以上版本。我自己的环境下是Python 3.10，运行起来没什么问题。

安装方法非常简单，直接在终端执行：

pip install rebiber

装完之后，你可以通过下面的命令确认是否安装成功：

rebiber --help

如果一切正常，终端会显示这个工具的命令行参数说明。常见的参数包括：

• -i：指定输入BibTeX文件路径
• -o：指定输出文件路径
• -a：指定额外的映射JSON文件路径
• -d：指定完整的数据文件路径
• -s：指定保存日志信息的目录
• -v：显示工具版本号

如果你习惯使用最新开发版本，也可以直接从GitHub克隆仓库后在本地运行：

git clone https://github.com/yuchenlin/rebiber.git cd rebiber pip install -r requirements.txt

不过一般情况下，直接pip install就够了，没必要手动克隆源码。只有在你想修改内置数据或者二次开发的时候，才需要拉源码下来看。

3. 实操：用Rebiber快速转换引用

3.1 最基础的一条命令

安装完成之后，最核心的使用方式就是一条命令。假设你现在有一个references.bib文件，想要转换成更新后的版本，可以这样执行：

rebiber -i references.bib -o references_updated.bib

这里的含义是：读取references.bib，处理完所有能匹配的引用，把结果写入references_updated.bib。原始文件不会被改动，输出文件是单独生成的，这样比较安全，处理完再人工检查差异就行。

我习惯在每次执行前先备份一下原文件，虽然Rebiber本来就不会覆盖输入文件，但多备份一层更保险。尤其是当你的.bib文件是从不同协作者手里合并过来的，格式可能比较混乱，工具解析时偶尔会出现意外情况。

执行完命令后，终端会输出类似这样的信息，告诉你有多少条目被处理、多少条目被更新：

Reading bib file... 3 of 10 entries are updated. Done! Updated bib file saved to references_updated.bib

这时候你可以打开输出文件，和原文件对比一下，看看变化的条目是否符合预期。我用一个很常见的场景举例。假设原文件里有一条论文引用是这样的：

@article{vaswani2017attention, title={Attention Is All You Need}, author={Vaswani, Ashish and Shazeer, Noam and Parmar, Niki and Uszkoreit, Jakob and Jones, Llion and Gomez, Aidan N. and Kaiser, Lukasz and Polosukhin, Illia}, journal={arXiv preprint arXiv:1706.03762}, year={2017} }

如果这篇论文的正式版信息存在于Rebiber的数据库里，它就可能被转换成类似这样：

@inproceedings{vaswani2017attention, title={Attention Is All You Need}, author={Vaswani, Ashish and Shazeer, Noam and Parmar, Niki and Uszkoreit, Jakob and Jones, Llion and Gomez, Aidan N. and Kaiser, Lukasz and Polosukhin, Illia}, booktitle={Advances in Neural Information Processing Systems}, pages={5998--6008}, year={2017}, publisher={Curran Associates, Inc.}, doi={10.48550/arXiv.1706.03762} }

一眼就能看出，转换之后条目类型从@article变成了@inproceedings，多了booktitle、pages、publisher这些正式发表信息。这样的条目放进论文里，参考文献列表会专业很多。

3.2 输入输出示例对比

为了让效果更直观，我再整理一个表格，把转换前后常见的字段差异列出来。

这里要特别提醒一下，转换前后的year可能不一样。不要想当然地觉得年份不会变，实际上很多论文从挂出预印本到正式发表，中间隔着一年甚至更久。如果正式发表版本改了年份，Rebiber会以数据库里的信息为准。

另外，author、title这些字段有时也会有细微变化。我遇到过一些论文，正式版提交前修改了标题大小写，或者调整了作者顺序。这些都是正常的，只需确认更新后的信息没问题就行。

3.3 自定义映射与批量处理

Rebiber内置的数据库并不能覆盖所有论文，尤其是新近发表的论文、以及arXiv上被正式接收但刚刚出版的论文，很可能会遗漏。这时候就需要用到自定义映射功能。

工具支持通过-a参数传入一个额外的JSON文件，这个文件的作用是补充自定义的映射数据。我举个例子。假设你发现Rebiber没有自动更新某篇引用，而且你从Google Scholar或出版社官网上找到了这篇论文的正式BibTeX信息，可以创建一个my_mapping.json文件，内容大致长这样：

{ "2301.12345": { "arxiv_id": "2301.12345", "doi": "10.xxxx/xxxxx", "url": "https://doi.org/10.xxxx/xxxxx", "bibtex": "@inproceedings{example2023, title={Your Paper Title}, author={Doe, John and Smith, Jane}, booktitle={Proceedings of the ...}, pages={100--110}, year={2023}, publisher={...}, doi={10.xxxx/xxxxx}}" } }

然后在运行Rebiber时指定这个文件：

rebiber -i references.bib -o references_updated.bib -a my_mapping.json

这样Rebiber在查找内置数据库之外，还会去你提供的JSON里再找一遍，之前没匹配上的条目就能被转换了。

如果你想处理多个.bib文件，也不用担心。可以写一个小小的循环命令，批量处理目录下所有文件。我在Linux环境下一般这样写：

for f in *.bib; do rebiber -i "$f" -o "${f%.bib}_updated.bib" done

这条命令会把当前目录下所有.bib文件都处理一遍，生成对应的_updated.bib文件。之后你可以用diff或者直接在文本编辑器里对比，确认结果没问题之后再统一替换。

3.4 转换后的自查要点

自动转换不是万能的，输出结果还是需要人工过一遍。我建议每次跑完Rebiber之后，不要直接就把文件提交到Overleaf或者打包发给出版社，先花几分钟做这几件事。

第一，检查条目类型是否正确。有些论文在arXiv上显示为@article，但正式发表时是会议论文，条目类型会从@article变成@inproceedings。如果转换后类型没变，但是booktitle又出现了，说明可能有问题。

第二，检查year字段。我前面提到过，正式发表年份和arXiv预印本年份经常不一致。如果你发现转换后的year很奇怪，比如论文看上去应该是2023年发表的，结果数据库里写的是2024年，那就有可能是某种映射错误，需要人工核对。

第三，检查标题的大小写。很多BibTeX条目为了在LaTeX里正确显示标题，会使用花括号把专有名词保护起来，比如{T}ransformer或者{BERT}。Rebiber内置的BibTeX数据通常已经处理好了这些问题，但你自己补充的自定义映射不一定。所以转换完成后，要特别注意标题字段里专有名词的大小写。

第四，检查重复条目。.bib文件大了以后，经常会出现重复条目。Rebiber一般不会帮你合并重复项，它只会逐个处理。所以遇到输出文件里出现两条相似条目时，记得手动清理一下。

4. 实际使用中会踩到的坑和排查思路

4.1 转换失败或没有命中

使用Rebiber时最常见的现象就是：跑完命令，终端提示没有条目被更新。这种情况通常有两种原因。

一种原因是你的.bib文件里压根没有arXiv相关的引用。如果条目里的eprint字段缺失，并且journal字段也不是arXiv preprint的格式，工具就无从识别。另一种原因则是，论文确实在Rebiber的映射数据库之外，它找不到对应记录。

遇到这种情况，你先打开.bib文件，确认引用的具体写法。比如：

@article{example2022, title={Example Title}, author={Doe, John}, journal={arXiv preprint arXiv:2201.00001}, year={2022} }

这种写法肯定能被识别为arXiv引用。但如果你的条目写作：

@misc{example2022, title={Example Title}, author={Doe, John}, year={2022}, eprint={2201.00001}, archivePrefix={arXiv}, primaryClass={cs.CL} }

这种格式在.bib文件中同样常见，Rebiber也能处理。真正没法识别的是那些连文献信息都不完整的条目，比如标题写错、作者缺失等。

如果确认引用格式没问题，但还是没转换成功，那基本就是映射数据未收录。解决办法就是我前面说的，用-a参数传入自己整理的JSON映射。你也可以考虑去Rebiber的GitHub仓库提一个Issue，建议作者把相关论文补充进内置数据库。根据我的观察，项目维护者对于补充新论文的Issue回应还是比较积极的。

4.2 API请求导致的限流或超时

有一些Rebiber的旧版本或者相关脚本会尝试调用Semantic Scholar的API来补全论文信息。这类外部接口通常有访问频率限制，当你一次性处理大量条目时，很容易触发限流，表现为程序运行到一半卡住，或者终端输出一堆Timeout、Rate limited之类的错误。

如果你遇到这种情况，最简单的方法就是给命令加上网络重试机制，或者分批处理.bib文件，减少单次请求量。另外一个更稳妥的做法是，把关注重点放在本地映射数据上，避免依赖在线API。毕竟内置数据库已经能覆盖大部分主流论文，在线API只是辅助。

我在实际使用中发现，直接用最新版本的Rebiber配合本地映射数据，绝大多数情况下是不需要访问外部API的。只有在处理比较新的论文时，才可能需要在线补充信息。如果你的网络环境本身就不稳定，建议优先考虑本地处理，减少出错的概率。

4.3 处理非标准BibTeX字段

团队协作时，.bib文件里经常会出现一些非标准字段。比如有人喜欢加file字段，记录PDF附件的路径；有人喜欢加annote字段，写自己的阅读备注；还有人因为使用Zotero导出，会多出keywords、abstract等字段。

Rebiber在处理这些字段时一般不会直接删除，而是会保留在条目的其他位置。我在对比输出文件时发现，自定义字段通常会原样保留下来，只有被替换的核心字段才会变化。这个设计本身是好的，但也带来一个副作用：如果你的旧条目里有很多过时的字段，转换后它们不会被清理掉，输出文件可能变得比较杂乱。

最省心的做法是，在运行Rebiber之前先对.bib文件做一次预处理，用文本编辑器或者脚本把不需要的字段删掉。这样转换出来的文件更干净，也更利于在LaTeX中正常编译。

4.4 老文献和冷门论文怎么处理

Rebiber对近几年的热门论文支持度最高，但对一些年代比较久远、或者本身引用量不高的论文，覆盖情况就不那么乐观了。我遇到过一篇1990年代发表的论文，它根本没有arXiv版本，自然也没有对应的映射记录。这种论文其实不需要转换，直接保留原来的期刊引用就行。

还有一种情况是，论文确实在arXiv上挂了预印本，但一直没有正式发表，或者正式发表到了一个小众平台，Rebiber数据库暂时没收录。这时候我建议你先到Google Scholar、DBLP或者出版社官网上手动搜索一下，如果找到了正式引用信息，就自己整理成BibTeX，然后用自定义JSON的方式交给Rebiber处理。如果实在找不到，那也说明这篇论文没有正式版，继续引用arXiv版本是在规则之内的。

这里还需要注意一个细节：有些论文虽然正式发表了，但出版社的引用格式要求比较特殊，比如某些期刊要求论文题名的每个单词首字母大写。Rebiber内置数据大多遵循常用格式，但如果你投的期刊有特殊规范，最好还是按照期刊模板手动微调一下最终的BibTeX条目。

5. 一些能够提升效率的小技巧

5.1 在提交Camera Ready前跑一遍

我个人的习惯是，论文一接到录用通知，就先在Overleaf或者本地的TeX源码里把references.bib用Rebiber过一遍，而不是等到修改Camera Ready版本的最后时刻才临时检查。原因很简单，录用后你可能还要调整论文内容、增加附录、修改图表，每次改动都可能导致之前的引用信息出现变化。早一点把参考文献的版本更新齐，后面就能少操一份心。

具体操作上，我会在修改正文之前先做引用转换，然后把生成的references_updated.bib重命名为原始文件名，再继续编辑其他部分。这样后面无论怎么改，参考文献版本已经是最新的了。

5.2 把映射文件纳入项目版本管理

如果你需要在团队里协作，或者需要在不同电脑之间同步工作，我建议把自定义的JSON映射文件纳入Git版本管理，和.bib文件一起提交。这样每个协作者在编译时都能使用同一份映射数据，不会出现你本机转换成功了、队友那边却还是旧版的情况。

我在实际操作中会建一个类似bib_update/的目录，里面放着my_mapping.json、references.bib和转换脚本。每次更新参考文献时，跑一条命令就能完成所有处理：

rebiber -i references.bib -o references.bib -a bib_update/my_mapping.json

这里我把输出文件直接覆盖回原文件了，因为这个操作我已经执行过很多次，对结果比较放心。如果你第一次使用，还是建议先把输出写到单独的文件里，人工检查之后再做覆盖。

5.3 结合其他工具使用

Rebiber并不是唯一需要用的文献工具。我觉得它和Zotero、JabRef这些参考文献管理软件搭配起来，效果更好。具体来说，你可以先用Zotero或JabRef统一管理所有文献，需要提交论文时导出.bib文件，然后交给Rebiber做版本升级，最后再把处理后的.bib文件放回Zotero或者直接用于LaTeX编译。

这样安排的好处是，日常阅读和文献整理还是在自己熟悉的图形界面里进行，Rebiber只负责批量转换这一个环节，各司其职。有同事问我“Rebiber能不能直接整理文献”，我都会解释说，它不适合做文献管理，它最适合做的是投稿前的最后一步——把引用版本更新到正式发表状态。

另外，如果你经常投稿到不同的会议或期刊，可以考虑写一个简单的Shell脚本，把Rebiber命令和不同期刊的参考文献格式检查脚本串起来。每次投稿前一键执行，先更新引用版本，再检查格式是否符合期刊要求，能省不少时间。

写在最后的一点经验

用了Rebiber这么长时间，我最直观的感受是，这种工具解决的不是一个“能不能做”的问题，而是一个“值得花多少时间做”的问题。手工更新几十条参考文献的BibTeX信息，看似不难，但特别耗神，还容易出错。Rebiber把大部分无意义的机械劳动省掉了，留下的人工工作只有检查和微调，这种投入产出比是非常划算的。

还有个小提示，不要完全依赖工具的默认数据库。如果你发现自己经常处理某个方向的论文，建议把相关论文的正式版信息自己整理成JSON映射文件，维护起来花不了多少时间，但以后每次转换都能稳稳命中。我自己维护了一个大概两百条左右的映射文件，基本把我研究方向里被漏掉的重要论文都补齐了，现在跑Rebiber的命中率很高，几乎不用再手工改条目。

工具本身只是一个起点，真正让整个流程变得顺滑的，是你不断积累的那份映射数据和检查习惯。希望这个分享能帮你少走一些弯路。