Werkzeug-Integration (CSL / arXiv / Verwaltungsprogramme)

Zeit frisst in einer Bibliographie nicht das Tippen von .bib-Einträgen. Zeit frisst es, eine einzige .bib konsistent zu halten – über eine Abschlussarbeit, drei Einreichungen und zwei Koautoren hinweg. Deshalb sind die meisten LaTeX-Literaturwerkzeuge weniger darauf ausgelegt, die Eingabe zu beschleunigen, als darauf, nach der Eingabe das Kaputte zu finden. Diese Seite geht den ganzen Weg ab: Datensätze aus DOI oder arXiv holen, verschmutzte Einträge säubern, Dubletten beseitigen und Zitierschlüssel festzurren, bevor die Datei an Koautoren geht – mit Literaturverwaltungen wie Zotero und JabRef ebenso wie mit den Kommandozeilenhelfern bibcop, checkcites und biber --tool, die TeX Live längst mitinstalliert hat.

BibTeX aus einem DOI oder einer arXiv-ID holen

Trägt ein Aufsatz einen DOI, ist sein .bib-Eintrag nur einen Befehl entfernt. Der Mechanismus heißt Content Negotiation: Man teilt doi.org per HTTP-Header mit, dass BibTeX zurückkommen soll, und die Agentur, die den DOI registriert hat – bei wissenschaftlichen Aufsätzen meist Crossref –, formt ihre Metadaten zu einem BibTeX-Eintrag und liefert ihn aus. Die Verlagsseite muss dafür nie geöffnet werden: Der DOI selbst ist die Schnittstelle.

# 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

Ohne -L kommt nichts zurück. doi.org ist nur ein Schalter, der ermittelt, welche Agentur die Metadaten hält, und dorthin weiterleitet; wer der Weiterleitung nicht folgt, läuft ins Leere. Ist die Kommandozeile lästig, genügt es, den DOI in doi2bib.org einzufügen, das dieselbe Content Negotiation in eine Webseite verpackt (arXiv- und PubMed-IDs werden ebenfalls akzeptiert). Ein arXiv-Preprint bietet auf der Abstract-Seite „Export BibTeX citation“, und Google Scholar versteckt dasselbe hinter „Cite → BibTeX“ bei jedem Treffer. Welcher Weg auch gewählt wird: getippt wird fast nichts.

Warum importiertes BibTeX fast nie unverändert brauchbar ist

Weil ein Exporter schlicht die Zeichenketten ausgibt, die in seiner eigenen Datenbank liegen; von LaTeX’ Bedürfnissen weiß er nichts. Holt man denselben Aufsatz von der Verlagsseite, von Crossref und von Google Scholar, erhält man drei verschiedene BibTeX-Einträge. Kaputt gehen jedes Mal dieselben vier Dinge – und jedes davon zeigt sich erst, wenn das Literaturverzeichnis gesetzt wird.

• Großbuchstaben sind ungeschützt. Ohne geschweifte Klammern im Titel – {DNA}, {Fourier} – schreiben Stile der plain-Familie sie zu „dna“ und „fourier“ klein. Die Mechanik behandelt die Seite zur Literaturdatenbank.
• Zeitschriftennamen sind mal abgekürzt, mal nicht. Dieselbe Zeitschrift kommt einmal als Comput. J. und einmal als The Computer Journal an, und das Literaturverzeichnis widerspricht sich selbst. Einreichungsrichtlinien verlangen fast immer das eine oder das andere.
• Der Eintragstyp stimmt nicht. Konferenzbeiträge werden häufig als @article oder @misc exportiert, und ein @inproceedings ohne booktitle ergibt im Satz Unsinn.
• Die arXiv-Fassung wird für die veröffentlichte gehalten. Das BibTeX eines Preprints hat meist weder journal noch doi, also wird der alte Datensatz noch lange zitiert, nachdem der Aufsatz begutachtet erschienen ist.

Eine .bib prüfen und normalisieren: bibcop und biber --tool

Statt diese vier Punkte mit dem Auge zu suchen, übernimmt das besser ein Linter. TeX Live bringt bibcop bereits mit, einen Linter für .bib-Dateien: keine Zusatzinstallation, einfach bibcop refs.bib. Zurück kommt keine Spalte von Zeilennummern, sondern Beanstandungen in ganzen Sätzen – etwa 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. Wer in lesbaren Sätzen gerügt wird, weiß genau, was zu ändern ist.

# 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

Das Normalisieren selbst übernimmt biber --tool. Neben dem gewöhnlichen Modus, der ein Dokument verarbeitet, kennt biber einen Tool-Modus, der als eigenständiger Filter arbeitet: .bib hinein, .bib heraus. Er setzt die Felder in ausgerichteten Spalten neu, sortiert die Einträge und warnt bei doppelten Schlüsseln mit Duplicate entry key: ... skipping, wobei einer entfällt. Eine Falle steckt allerdings darin. Die Ausgabe des Tool-Modus wird standardmäßig auf biblatex-Feldnamen normalisiert, year wird also zu date und journal zu journaltitle. Für ein biblatex-Dokument ist genau das erwünscht; schickt man dagegen eine für reines BibTeX gedachte .bib hindurch, verschwinden Jahr und Zeitschriftenname aus dem Literaturverzeichnis.

Doppelte Einträge und verwaiste Zitierschlüssel finden

Taucht derselbe Schlüssel zweimal auf, meldet BibTeX Repeated entry---line 8 of file refs.bib und verwirft den späteren Eintrag; biber warnt mit Duplicate entry key. Heikler ist die Dublette mit verschiedenen Schlüsseln, aber identischem Inhalt, vor der niemand warnt. Werden die Zotero-Exporte zweier Koautoren zusammengeführt, steht derselbe Aufsatz zweimal da, als smith2020 und als Smith2020a – ein Missgeschick, das meist erst auffällt, wenn im gesetzten Literaturverzeichnis dieselbe Zeile zweimal erscheint.

Für den inhaltlichen Abgleich ist der DOI der verlässlichste Anhaltspunkt. Autorennamen und Titel schwanken, doch zwei Einträge mit demselben DOI sind derselbe Aufsatz, Punkt. Genau das setzt bibtex-tidy um: Das Kriterium wählt --duplicates doi (oder key, abstract, citation), und --merge führt den einen in den anderen über. Für das umgekehrte Problem – ein Schlüssel wird zitiert, den die .bib nicht enthält, sodass im Text [?] erscheint – ist checkcites da. --undefined listet zitierte, aber nie definierte Schlüssel; --unused listet definierte Einträge, die niemand zitiert.

# 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

Welche Literaturverwaltung wählen: Zotero, JabRef, BibDesk

Bis zu ein paar Dutzend Einträgen lässt sich die .bib von Hand pflegen; bei einigen Hundert braucht es eine Verwaltung. Die Weggabelung lautet: Ist die .bib das Original oder ein Export? JabRef und BibDesk öffnen und speichern die .bib selbst und vertragen sich daher mit dem direkten Bearbeiten im Texteditor. Zotero behandelt die eigene Bibliothek als Original; die .bib ist dann ein daraus erzeugtes Nebenprodukt.

• Zotero — der kostenlose Open-Source-Standard. Ein Browser-Connector erfasst einen Aufsatz mit einem Klick, legt das PDF ab und unterstützt gemeinsame Gruppenbibliotheken. Wer LaTeX schreibt, sollte die Erweiterung Better BibTeX als praktisch verpflichtend ansehen.
• Better BibTeX (Zotero-Erweiterung) — erzeugt Zitierschlüssel aus einem Muster und bietet Auto-Export, der jede Änderung der Bibliothek direkt in die .bib schreibt. Genau darum geht es: Die .bib wird zu einem stets aktuellen Build-Artefakt.
• JabRef — eine quelloffene Verwaltung, die nativ mit .bib arbeitet. Sie hat kein eigenes internes Format, holt Einträge über DOI, arXiv-ID oder ISBN und bietet einen Sammel-Cleanup über ausgewählte Einträge. Läuft unter Windows, macOS und Linux.
• BibDesk (macOS) — ein BibTeX-Frontend für den Mac, das MacTeX beiliegt (/Applications/TeX/BibDesk.app). Es bearbeitet die .bib direkt und beherrscht automatisches Ablegen von PDFs sowie Suchen in externen Datenbanken.
• Mendeley — das alte Mendeley Desktop wurde am 1. September 2022 eingestellt, und damit entfiel auch das automatische Synchronisieren einer .bib. Der Nachfolger Mendeley Reference Manager kann weiterhin BibTeX exportieren, allerdings nur als manuellen Schritt.
• Paperpile — ein kostenpflichtiger Dienst mit starker Google-Docs-Anbindung, der ebenfalls BibTeX exportiert.

Auf Zoteros Seite hat sich 2026 einiges bewegt. Zotero 8 hat den Zitierschlüssel zu einem nativen Zotero-Feld gemacht und damit das Schlüsselfeld abgelöst, das zuvor Better BibTeX gehörte. Schlüssel sind nun immer festgesetzt (pinned) und synchronisieren zwischen Geräten; das frühere Ritual, jeden Eintrag einzeln über „Pin BibTeX Key“ festzuzurren, entfällt. Allerdings erzeugt Zotero selbst keine Schlüssel – sie aus einem Muster zu bilden und die .bib per Auto-Export aktuell zu halten, bleibt Aufgabe von Better BibTeX. Zu beachten: Better BibTeX unterstützt Zotero 7 nicht mehr, dieses Gespann verlangt also auch ein aktuelles Zotero.

Zitierschlüssel festzurren und die .bib mit Koautoren teilen

Ein Zitierschlüssel ist die Schnittstelle zwischen Manuskript und Literaturdatenbank – deshalb ist er das Einzige, das sich niemals ändern darf. Ist der Export so eingestellt, dass Schlüssel jedes Mal neu abgeleitet werden, lösen sich alle \cite{...} im Text auf einen Schlag nicht mehr auf, und das PDF füllt sich mit [?]. Die Konvention selbst ist zweitrangig, doch Nachname + Jahr + Kurztitel – etwa knuth1984literate – kollidiert selten und hat den Nebeneffekt, dass der Schlüssel allein schon verrät, um welchen Aufsatz es geht.

Für die gemeinsame Arbeit ist es am wenigsten fehleranfällig, die .bib in dasselbe Git-Repository wie das Manuskript zu legen. Sie ist reiner Text, Diffs sind also lesbar, und die Historie hält fest, wer welchen Eintrag ergänzt hat. Sich selbst überlassen erzeugt sie allerdings ständig Konflikte; das Gegenmittel ist eine festgelegte Ausgabereihenfolge. Entweder lassen alle vor dem Commit biber --tool laufen, oder der Auto-Export von Better BibTeX zeigt auf einen vereinbarten Pfad – so oder so brechen Merge-Konflikte drastisch ein, sobald die Zeilenreihenfolge stabil ist. Was man keinesfalls tun sollte: sich gegenseitig die lokalen .bib-Dateien mailen. Zwei Wochen später existieren vier verschiedene .bib-Dateien.

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

Kurz vor der Einreichung dreht sich der Ablauf um: Nun muss eine .bib herausgeschnitten werden. Die meisten Zeitschriften verlangen den vollständigen Manuskriptquelltext, und die persönliche Datenbank mit 800 Einträgen kann nicht mitgeliefert werden. bibexport liest die .aux und schreibt nur die tatsächlich mit \cite verwendeten Einträge in eine neue .bib – genau der Zuschnitt dieses Problems (bibtool kann die .aux ebenso auswerten). Aus demselben Grund ist es im Alltag meist bequemer, eine große Master-.bib zu pflegen und pro Manuskript ein Stück herauszuschneiden.

Dieselbe .bib an Nicht-LaTeX-Nutzer weitergeben: CSL und pandoc

Auch wenn Koautoren in Word schreiben, muss die .bib nicht aufgegeben werden. CSL (Citation Style Language) ist ein XML-Format zur Beschreibung des Aussehens von Zitaten und Literaturverzeichnissen, und sein entscheidendes Merkmal ist die Unabhängigkeit vom Satzsystem. Eine BibTeX-.bst funktioniert nur mit BibTeX, ein biblatex-Stil nur innerhalb von LaTeX; eine .csl ist an nichts gebunden. Die Formatierung übernimmt ein citeproc-Prozessor, und Zotero, Word-Plugins sowie diverse Konverter lesen dieselbe .csl jeweils über ihre eigene citeproc-Implementierung. Zoteros Stil-Repository hält Tausende Zeitschriftenstile bereit, frei nutzbar.

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

Am stärksten stützt sich pandoc auf CSL. Wird ein Markdown-Manuskript mit --citeproc umgewandelt, werden Zitierschlüssel im Text wie [@knuth1984] zu formatierten Zitaten, und am Ende entsteht ein Literaturverzeichnis. --bibliography nimmt die .bib unverändert entgegen (und lässt sich mehrfach angeben, um mehrere zusammenzuführen); ohne --csl greift Chicago author-date. Kurz: Dieselbe .bib speist die Ausgabe direkt von Markdown nach PDF, Word oder HTML, ganz ohne LaTeX auf dem Weg.

Am Ende ruhen alle Werkzeuge dieser Seite auf derselben Voraussetzung: Der Bestand ist die .bib, nicht der Ausgabeweg. Existiert erst eine Datenbank – über DOIs eingesammelt, von bibcop gerügt, mit biber --tool geglättet, mit festgezurrten Schlüsseln, abgelegt in Git –, dann ist ein PDF über biblatex oder eine Word-Datei für Koautoren über pandoc bloß die Wahl des Ausgangs. Die Datenbank bei einer einzigen zu belassen bringt weit mehr, als weitere Werkzeuge hinzuzufügen.