工具集成 (CSL / arXiv / 管理器)

参考文献真正吃掉时间的地方，不是敲 .bib 条目，而是要在一篇学位论文、三次投稿和两位合作者之间，让同一个 .bib 始终保持一致。因此 LaTeX 的文献工具，大多与其说是为了加快录入，不如说是为了找出录入之后哪里坏了。本页顺着完整的路线走一遍：从 DOI 或 arXiv 取回记录、清洗脏条目、消灭重复、固定引用键再把文件交给合作者——既用 Zotero、JabRef 这类文献管理软件，也用 TeX Live 早已为你装好的命令行工具 bibcop、checkcites 和 biber --tool。

从 DOI 或 arXiv 取回 BibTeX

只要论文有 DOI，它的 .bib 条目一条命令就能拿到。原理是 content negotiation（内容协商）：用 HTTP 头告诉 doi.org 你要的是 BibTeX，登记该 DOI 的机构——学术论文多半是 Crossref——就会把元数据整理成 BibTeX 条目交给你。根本不必打开出版社页面：DOI 本身就是 API。

# fetch BibTeX for a DOI; -L follows the redirect to the registration agency
curl -LH "Accept: application/x-bibtex" \
  "https://doi.org/10.1145/3186893" >> refs.bib

去掉 -L 就什么也拿不到。doi.org 只是一个判断哪家机构持有该 DOI 元数据、然后把你重定向过去的柜台，不跟随重定向请求就落空。若嫌命令行麻烦，把 DOI 粘到 doi2bib.org 即可，它把同样的内容协商包进了网页（也接受 arXiv ID 和 PubMed ID）。arXiv 预印本在摘要页提供「Export BibTeX citation」，Google Scholar 则把同样的东西藏在每条结果的「Cite → BibTeX」里。无论走哪条路，需要手敲的字符几乎为零。

为什么导入的 BibTeX 几乎从不能直接用

因为导出方只是把自家数据库里的字符串原样吐出来，它并不了解 LaTeX 的需求。把同一篇论文分别从出版社网站、Crossref 和 Google Scholar 取回，会得到三份不同的 BibTeX。坏掉的地方每次都是同样四处，而且无一例外要等到排版时才浮出水面。

• 大写没有被保护 — 标题里若不用花括号包住 {DNA}、{Fourier}，plain 系列样式会把它们小写成「dna」「fourier」。具体机制在文献数据库那一页讲。
• 期刊名时缩写时不缩写 — 同一本刊物一次是 Comput. J.，一次是 The Computer Journal，参考文献表内部就自相矛盾。投稿规范几乎总要求二者取一。
• 条目类型不对 — 会议论文常被导出成 @article 或 @misc，而缺少 booktitle 的 @inproceedings 排出来就是一团乱码。
• 把 arXiv 版当成正式发表版 — 预印本的 BibTeX 往往既无 journal 也无 doi，于是论文早已见刊，你却还在引旧记录。

检查与规范 .bib — bibcop 与 biber --tool

与其用肉眼去找上面那四类问题，不如交给代码检查工具（linter）。TeX Live 里已经带了专为 .bib 写的检查器 bibcop，无需另行安装，直接 bibcop refs.bib 就能跑。它返回的不是一列行号，而是成句的意见——例如 Do not shorten the words in the journal, such as Comput.、All major words in the title must be capitalized、A mandatory doi tag for @article is missing。用能读懂的句子挨批评，就不会不知道该改哪里。

# lint a database in place
bibcop refs.bib

# reformat and sort every entry; also reports duplicate keys
biber --tool --output-align --output-fieldcase=lower \
  --output-file=clean.bib refs.bib

规范化本身由 biber --tool 负责。除了处理文档的普通模式，biber 还有一个 tool 模式，作为独立过滤器工作：输入 .bib，输出 .bib。它会把字段对齐重排、给条目排序，若两条目撞键则警告 Duplicate entry key: ... skipping 并丢掉其中一条。但这里有个陷阱。 tool 模式的输出默认会规范成 biblatex 的字段名，于是 year 变成 date，journal 变成 journaltitle。对 biblatex 文档来说这正合心意；可若把打算喂给原生 BibTeX 的 .bib 过一遍，参考文献表里的年份和刊名就会凭空消失。

找出重复条目与悬空的引用键

同一个键出现两次时，BibTeX 会说 Repeated entry---line 8 of file refs.bib 并丢掉后来的那条，biber 则警告 Duplicate entry key。更麻烦的是键不同而内容相同的重复，这种情况没人会提醒你。把两位合作者各自从 Zotero 导出的 .bib 合并，同一篇论文就会以 smith2020 和 Smith2020a 的身份并排出现两次——这类事故通常要等参考文献表里冒出两行一模一样的条目时才被发现。

按内容判定重复时，最可靠的线索是 DOI。作者名和标题会有写法差异，但两条 DOI 相同的条目一定是同一篇论文。bibtex-tidy 实现的正是这一点：用 --duplicates doi（或 key、abstract、citation）选择判定标准，再加 --merge 就能把其中一条并入另一条。相反的问题——引用了 .bib 里没有的键，正文因此印出 [?]——则交给 checkcites。--undefined 列出引用了却没定义的键，--unused 列出定义了却无人引用的条目。

# BibTeX projects read the .aux; biblatex projects read the .bcf
checkcites paper.aux
checkcites --backend biber paper.bcf

# keys cited but missing from the database
checkcites --undefined paper.aux

文献管理软件怎么选 — Zotero / JabRef / BibDesk

几十条以内还能手工编辑 .bib，到了几百条就得靠管理软件。分岔点在于把 .bib 看作原本，还是看作导出结果。JabRef 和 BibDesk 直接打开并保存 .bib 本身，因此与在文本编辑器里直接改文件并行不悖。Zotero 则以自家的资料库为原本，.bib 只是由它生成的派生物。

• Zotero — 免费、开源的默认之选。浏览器插件可从论文页面一键抓取，保存 PDF，还支持共享的群组库。若要写 LaTeX，可以把 Better BibTeX 扩展视为必装。
• Better BibTeX（Zotero 扩展） — 按模式生成引用键，并提供 auto-export，把库中的每一次改动直接推进你的 .bib。这正是它的全部意义：.bib 从此成为始终最新的生成物。
• JabRef — 原生处理 .bib 的开源管理软件。没有单独的内部格式，可从 DOI、arXiv ID 或 ISBN 抓取条目，还能对选中条目做批量清理。支持 Windows、macOS 和 Linux。
• BibDesk（macOS） — Mac 上的 BibTeX 前端，随 MacTeX 一同发行（/Applications/TeX/BibDesk.app）。可直接编辑 .bib，并支持 PDF 自动归档与外部数据库检索。
• Mendeley — 旧版 Mendeley Desktop 已于 2022 年 9 月 1 日停止发放，自动同步 .bib 的功能也随之消失。后继的 Mendeley Reference Manager 仍可导出 BibTeX，但只能手动操作。
• Paperpile — 付费服务，擅长 Google Docs 集成，同样支持导出 BibTeX。

Zotero 这一侧在 2026 年发生了大变动。Zotero 8 把 citation key 变成了 Zotero 自带的字段，取代了原先由 Better BibTeX 掌管的键位。如今键一律固定（pinned）并在设备之间同步，过去逐条右键「Pin BibTeX Key」的仪式已成历史。但 Zotero 本身并不生成键——按规则造键、并通过 auto-export 持续吐出 .bib，仍然是 Better BibTeX 的职责。另外 Better BibTeX 已结束对 Zotero 7 的支持，所以要用这套组合就得把 Zotero 一并升级。

固定引用键，与合作者共享 .bib

引用键是稿件与文献数据库之间的 API，所以唯独键绝不能变动。若导出设置成每次重新推导键，正文里所有 \cite{...} 会同时失效，PDF 里满是 [?]。命名规则本身无所谓，但用「作者姓 + 年份 + 标题缩写」（形如 knuth1984literate）不易冲突，还附赠一个好处：光看键就知道是哪篇论文。

要与合作者共享，最不容易出事的做法是把 .bib 放进和稿件同一个 Git 仓库。它是纯文本，因此差异可读，谁加了哪一条都留在历史里。不过放着不管就会频繁冲突，解法是固定输出顺序：让所有人提交前先跑一遍 biber --tool，或者把 Better BibTeX 的 auto-export 目标定在一个约定好的路径——无论哪种，只要行序稳定，合并冲突就会断崖式减少。绝对不能做的是互相用邮件发送各自本地的 .bib。两周之后你会有四个不同的 .bib。

# ship only the entries this paper actually cites
pdflatex paper.tex
bibexport -o submission.bib paper.aux

临投稿时流程恰好反过来：你需要把 .bib 切出来。多数期刊要求提交完整源文件，而你不能把一个 800 条的个人数据库一并奉上。bibexport 会读取 .aux，只把真正被 \cite 的条目写进一个新的 .bib，正好对上这个需求（bibtool 也能解析 .aux 做同样的事）。出于同样的理由，日常保留一个大的 master .bib、按稿件切片使用，往往更好打理。

交给不用 LaTeX 的人 — CSL 与 pandoc

就算合作者用 Word 写作，也不必丢掉 .bib。CSL（Citation Style Language） 是一种描述引用与参考文献表外观的 XML 格式，其决定性特点是不依赖排版引擎。BibTeX 的 .bst 只服务 BibTeX，biblatex 的样式只在 LaTeX 内有效，而 .csl 不绑定任何体系。真正的格式化由 citeproc 处理器完成，Zotero、Word 插件和各类转换工具各用自己的 citeproc 实现来解释同一个 .csl。Zotero 的样式仓库里有数千种期刊样式，可自由取用。

pandoc paper.md --citeproc \
  --bibliography=refs.bib \
  --csl=ieee.csl \
  -o paper.pdf

把 CSL 用得最透的工具是 pandoc。用 --citeproc 转换 Markdown 稿件，正文里 [@knuth1984] 之类的引用键就会变成格式化引用，末尾还会生成参考文献表。--bibliography 可以直接接受你的 .bib（可重复指定以合并多个），省略 --csl 时退回到 Chicago author-date。一句话：同一个 .bib 就能从 Markdown 直接产出 PDF、Word 或 HTML，路径上完全不经过 LaTeX。

归根结底，本页所有工具都站在同一个前提上：资产是 .bib 本身，而不是输出路径。只要有一个数据库——从 DOI 取回、被 bibcop 训过、经 biber --tool 整过、键已固定、放在 Git 里——那么此后用 biblatex 出 PDF，还是用 pandoc 给合作者一份 Word，都只是出口的选择而已。把数据库保持为一个，远比不断增加工具有效。